MTA-STS, TLS-RPT ve BIMI Kurulum Rehberi

E‑posta güvenliğinde yeni katman

Alan adınızla gönderdiğiniz e‑postaların gerçekten alıcıya güvenli şekilde ulaşıp ulaşmadığını, yol üzerinde şifrelemenin zorlanıp zorlanmadığını veya markanızın gelen kutusunda nasıl göründüğünü çoğu zaman web projesinin planlama toplantısında fazla konuşmayız. SPF, DKIM ve DMARC kayıtlarını kurar, bir kere test eder ve konu kapandı zannederiz. MTA‑STS, TLS‑RPT ve BIMI ise bu temel kayıtların yerini almadan, taşıma güvenliği, TLS sorunlarının raporlanması ve marka görünürlüğü gibi farklı ihtiyaçlara odaklanır.

Transactional (şifre sıfırlama, sipariş bildirimleri) ve pazarlama e‑postaları için gönderici doğrulaması, taşıma güvenliği ve marka görünürlüğü ayrı ayrı değerlendirilmelidir. Bu makalede, bu üç bileşenin ne yaptığını, nasıl çalıştığını ve alan adınızda hangi DNS kayıtlarını eklemeniz gerektiğini örneklerle anlatacağız. Ayrıca farklı ölçeklerde işletmeler için pratik kurulum stratejilerini ve seçtiğiniz altyapıda dikkat etmeniz gereken noktaları ele alacağız.

Temel zemin: SPF, DKIM, DMARC ve TLS’i doğru kurmadan ilerlemeyin

MTA‑STS ve TLS‑RPT taşıma güvenliğine ve bunun izlenmesine, BIMI ise marka görünürlüğüne odaklanır. Bu özellikleri değerlendirirken temel e‑posta ayarlarını da doğru kurmalısınız:

• SPF: SMTP zarf göndericisi (MAIL FROM) veya HELO alan adı için hangi sunucuların gönderime yetkili olduğunu tanımlar; görünen From adresini doğrudan doğrulamaz.
• DKIM: İmzalanan ileti bölümlerinin bütünlüğünü ve imzalayan alan adıyla ilişkisini kriptografik imzayla doğrular; bu alan adı görünen gönderici alan adıyla aynı olmak zorunda değildir.
• DMARC: Görünen From alan adıyla hizalanmış bir SPF veya DKIM başarısını arar; bu koşul sağlanmadığında alıcının uygulamasını istediğiniz politikayı belirtir.
• TLS: SMTP üzerinden e‑posta aktarılırken sunucular arası trafiğin şifrelenmesini sağlar.

Bu temele aşina değilseniz, önce SPF, DKIM ve DMARC doğrulamasını sıfırdan kurmayı anlattığımız rehbere göz atmanızı öneririz. Ayrıca PTR (reverse DNS), IP itibarı ve spam klasörüne düşmeme tarafını da PTR (Reverse DNS) kaydı ve e‑postalar neden spam klasörüne düşüyor makalelerimizle birlikte okursanız, bu yazıdaki ileri seviye konular çok daha anlamlı hale gelir.

MTA-STS nedir? Gelen e-posta için TLS politikası

MTA-STS (Mail Transfer Agent Strict Transport Security), alan adınıza gelen SMTP teslimatında kullanılabilecek MX adlarını ve TLS doğrulama koşullarını yayımlar. Geçerli, süresi dolmamış bir enforce politikası uygulayan uyumlu gönderici, koşulları sağlamayan MX’e teslimat yapmaz. Alan adınızda bu kaydı yayımlamak, tüm göndericileri veya sizin dışarı gönderdiğiniz bütün postaları otomatik olarak korumaz. Amaç şu riskleri azaltmaktır:

• TLS downgrade saldırıları: Saldırgan, iki sunucu arasındaki STARTTLS müzakeresini bozup iletişimi şifresiz hale getirmeye çalışabilir.
• MX spoofing / ortadaki adam: DNS’te MX cevabını manipüle edip e‑postaları sahte bir sunucuya akıtmaya çalışabilir.

MTA‑STS, iki parçadan oluşur:

1. DNS tarafında bir _mta-sts.example.com TXT kaydı,
2. HTTPS üzerinden yayınlanan bir politika dosyası (https://mta-sts.example.com/.well-known/mta-sts.txt).

MTA‑STS neyi çözer, SPF/DMARC’tan farkı nedir?

SPF, DKIM ve DMARC gönderici kimliği, imzalanmış içerik ve görünen From alan adının yetkili kullanımını ele alır. MTA-STS ise alıcı alan adına giden SMTP bağlantısına uygulanır. Politikayı değerlendiren ve uygunsuz MX’e teslimatı durduran taraf gönderen MTA’dır; alıcının DNS kaydı tek başına bütün MX sunucularında TLS’i zorunlu kılmaz.

SPF doğrulamasından geçen ve DKIM ile imzalanmış bir ileti de taşıma sırasında şifreleme ve sunucu kimliği denetimine ihtiyaç duyabilir. MTA-STS uçtan uca ileti şifrelemesi değildir. İlk politika keşfi engellenebildiğinden, önceden güvenle alınmış politikanın önbellekte bulunması saldırıya karşı korumada önemlidir.

MTA‑STS politika dosyasının yapısı

Örnekteki adları gerçek MX adlarınızla değiştirin. Bu başlangıç politikası, hatalı koşullarda MTA-STS nedeniyle teslimatı engellemeyen testing modundadır; uygulanacak koşullar ayrıca sınanmalıdır:

version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400

• version: STSv1 protokol sürümüdür.
• mode: none, testing veya enforce değerini alır.
• mx: Her izin verilen MX deseni ayrı satırdadır. *.example.com, mail.example.com adını kapsar; example.com veya foo.bar.example.com adını kapsamaz. Uluslararası adlar ASCII/Punycode olarak yazılır.
• max_age: Politikanın son başarılı alınışından itibaren saniye cinsinden önbellek ömrüdür; DNS TTL’si değildir. Örnekte 86400 bir gündür. Geçerli aralık 0–31557600’dür; oturmuş yapılandırmada daha uzun süre ilk keşif ve yenileme engellemelerine karşı yararlıdır.

MTA‑STS DNS kaydı nasıl görünür?

DNS tarafında genellikle şu şekilde bir TXT kaydı oluşturursunuz:

_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=2025010101"

• v=STSv1: Kayıt bu sürüm alanıyla başlar; alan adında tek geçerli MTA-STS TXT kaydı bulunmalıdır.
• id: Her farklı politika sürümünü ayırt eden 1–32 ASCII harf veya rakamdır; tarih veya sıralı sayı olması gerekmez. Önce HTTPS dosyasını, sonra bu değeri güncelleyin. Yeni id, kontrol eden göndericiye güncellemeyi bildirir; tüm önbellekleri anında temizlemez.

Gönderici geçerli önbelleğini kullanabilir. DNS veya HTTPS erişimi bozulsa bile süresi dolmamış önbellekteki politika uygulanır; geçerli önbellek ve alınabilen politika yoksa MTA-STS varmış gibi davranılamaz. Bu nedenle TXT kaydını silmek acil geri alma yöntemi değildir.

MTA‑STS modları: none, testing, enforce

Modlar aynı güvenlik düzeyini sağlamaz:

• none: Etkin MTA-STS politikası yokmuş gibi davranılmasını bildirir. Test başlangıcından çok kontrollü devreden çıkarma içindir.
• testing: MTA-STS doğrulama hatası teslimatı engellemez. İki taraf da TLS-RPT kullanıyorsa uyumlu gönderici hata raporlayabilir; bu, her mesajın teslim edileceği anlamına gelmez.
• enforce: Uyumlu gönderici, MX deseni, STARTTLS veya sertifika doğrulamasını geçemeyen hedefe teslimat yapmamalıdır. Sıradaki kullanılabilir MX denenebilir; hata genellikle geçici kabul edilip yeniden denenir. Kalıcı başarısızlıktan önce güncel politika kontrol edilmelidir.

Aşamalı bir geçiş için şu sırayı izleyebilirsiniz:

1. Tüm birincil ve yedek MX’lerin STARTTLS, sertifika zinciri ve gerçek MX adıyla eşleşen SAN DNS-ID alanlarını doğrulayın.
2. mode: testing ve yönetilebilir bir max_age ile başlayın; TLS-RPT’yi ve SMTP günlüklerini değerlendirin. Süreyi takvimden çok trafik ve yedek yolların test kapsamına göre belirleyin.
3. Hatalar giderildiğinde önce dosyayı mode: enforce yapın, sonra TXT id’sini değiştirin. Rapor gelmemesi tek başına başarı kanıtı değildir.

MX değiştirirken yeni adı önce eski adlarla birlikte politikaya ekleyin, HTTPS’i ve ardından id’yi güncelleyin. Önceden sunulmuş politikaların son sunum zamanı ve max_age değerlerini, ayrıca DNS TTL’lerini hesaba katın; eski MX/TLS yollarını çalışır tutup yeni yolun kabulünü doğrulamadan geçişi tamamlamayın. Yeni, daha kısa max_age eski önbelleklerin süresini kısaltmaz. MTA-STS’yi kaldırmak için önce mode: none ve yeni id yayımlayın; önceki tüm politika ömürleri dolmadan TXT ve HTTPS uçlarını kaldırmayın.

MTA‑STS politikası nerede barınmalı?

Politika, tam https://mta-sts.example.com/.well-known/mta-sts.txt adresinden doğrudan 200 OK ile sunulmalıdır; istemci 3xx yönlendirmelerini izlemez. text/plain içerik türünü kullanın. HTTPS sertifikası politika hostunun SAN DNS-ID adıyla eşleşmeli, süresi geçmemiş ve güvenilen bir CA zincirine bağlı olmalıdır. Bu sertifika, MX’in SMTP sertifikasından ayrı doğrulanır. Dosyayı şu ortamlarda barındırabilirsiniz:

• Paylaşımlı hosting: Seçtiğiniz plan alt alan adı oluşturmayı, bu ad için geçerli bir TLS sertifikası kullanmayı ve ilgili yolda dosya yayımlamayı destekliyorsa, mta-sts.example.com için bir alt alan oluşturup /.well-known/mta-sts.txt dosyasını web dizinine koyabilirsiniz.
• VPS/dedicated: Kendi Nginx/Apache yapılandırmanız varsa, basit bir sanal host ile sadece bu dosyayı servis eden hafif bir site kurabilirsiniz. SSL/TLS sertifikanızı Let’s Encrypt otomasyonu ile otomatik yenileyecek şekilde tasarlamanızı tavsiye ederiz.

TLS‑RPT nedir? TLS sorunları için geri bildirim kanalı

TLS-RPT (SMTP TLS Reporting), katılan göndericilerin alan adınıza yönelik TLS bağlantılarının başarılı ve başarısız sonuçlarını topluca raporlamasını sağlar. JSON raporunun tam bir UTC gününü kapsaması önerilir; gönderim daha sonra gecikmeli olabilir. Katılım ve teslim sıklığı sağlayıcıya bağlıdır, her göndericiden her gün rapor beklenmez.

MTA-STS ile birlikte kullanıldığında, uygulanan politikanın ve bağlantı koşullarının gözlemlenmesine yardımcı olur. Başarılı TLS oturumu sayısı, iletinin gelen kutusuna yerleştirildiğini veya kullanıcı tarafından okunduğunu kanıtlamaz.

TLS‑RPT DNS kaydı nasıl tanımlanır?

Alan adınız için şu şekilde bir TXT kaydı oluşturursunuz:

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-report@example.com"

• v=TLSRPTv1: Sürüm alanı kayıt başında yer alır; tek geçerli TLS-RPT TXT kaydı yayımlayın.
• rua: Rapor uçlarını belirtir. mailto: adresleri veya https: POST uçları kullanılabilir; birden fazla URI virgülle ayrılır. Her raporun bütün adreslere gönderileceğini varsaymayın.

Bu adresi yalnız rapor toplamak için ayrılmış, izlenen bir posta kutusuna yönlendirin. Otomatik işleyici, e-postayla gelen raporda raporlayan alan adına ait geçerli bir DKIM imzasını doğrulamalıdır. Bu imza, imzalanan gövde uzunluğunu sınırlayan l= etiketini içermemelidir; bu koşulları karşılamayan raporları işleme almayın. Bozuk ya da aşırı büyük ekleri denetimli işleyin. Rapor dosyasındaki sayıları SMTP günlükleriyle birlikte değerlendirin.

TLS‑RPT raporlarında hangi bilgileri görürsünüz?

Standart rapor şemasındaki temel alanlar şunlardır:

• Raporlayan kuruluş, rapor kimliği, iletişim bilgisi ve zaman aralığı.
• Uygulanan politika türü ve alan adı; MTA-STS için politika metni ve MX desenleri.
• Toplam başarılı ve başarısız TLS oturumu sayıları.
• Hata türü ve ilgili başarısız oturum sayısı; hata ayrıntısı mevcut olduğunda gönderen IP, alıcı MX adı/IP’si ve isteğe bağlı ek açıklamalar.

TLS sürümü ve şifre paketi, standart TLS-RPT JSON şemasının ayrı alanları değildir. Ayrıntılardaki hata sayıları örtüşebilir; bunları toplayıp benzersiz ileti sayısı olarak sunmayın.

Bu veriler, aşağıdaki olası sorunları araştırmak için ipucu sağlayabilir; tek başına kesin teşhis yerine geçmez:

• certificate-expired ve certificate-host-mismatch sonuçları, sertifika süresi veya isim eşleşmesini araştırmaya yönlendirir.
• sts-policy-fetch-error veya sts-webpki-invalid, politika uç noktası ve HTTPS doğrulaması için ipucu sağlar.
• Bir MX/IP veya göndericide yoğunlaşan hataları DNS yanıtları, SMTP günlükleri ve kontrollü bağlantı testleriyle karşılaştırın. Toplu rapor tek başına yanlış DNS kaydını, bir ülkeyi veya bozuk ağ geçidini kesinleştirmez; geçici ağ hatalarının raporlanması da zorunlu değildir.

İlgili teknik konular için, blogumuzdaki postmaster araçları ve itibar yönetimi ile birlikte, MTA‑STS ve TLS‑RPT ile teslim edilebilirliği artırmayı anlattığımız yazıyı okumanızı tavsiye ederiz.

BIMI nedir? Marka logonuzu gelen kutusuna taşıyan DNS standardı

BIMI (Brand Indicators for Message Identification), uygun iletilerde marka logosunun destekleyen posta sağlayıcıları tarafından gösterilebilmesi için DNS üzerinden bilgi yayımlar. Tek başına kimlik doğrulama, spam engelleme veya logo gösterim garantisi sağlamaz.

BIMI’nin ön koşulları: Neden DMARC’sız BIMI olmaz?

BIMI uygunluğu alıcı sağlayıcının kurallarına bağlıdır. BIMI Group uygulama kılavuzu ile hedef sağlayıcının güncel koşullarını birlikte inceleyin:

• Organizasyon alan adı ve ilgili alt alanlarda DMARC politikası tam uygulamada olmalıdır: p=quarantine veya p=reject; alt alan politikası bunu etkisizleştirmemelidir.
• İleti, görünen From alan adıyla hizalanmış başarılı SPF veya DKIM sonucu sayesinde DMARC’ı geçmelidir. Sağlayıcı ayrıca hem SPF hem DKIM isteyebilir.
• İtibar, şikâyet oranı ve logo uygunluğu sağlayıcının ek koşullarına tabidir.
• Logo sıradan bir SVG değil, SVG Tiny PS biçiminde olmalıdır; gereken logo ve sertifika dosyaları HTTPS üzerinden sunulur.
• Gmail, bir CA tarafından verilen VMC veya CMC ve logoyu içeren PEM dosyası ister. Sertifikasız SVG kaydının desteği sınırlıdır.

BIMI sağlayıcı yönergeleri, eski DMARC örneklerindeki pct yüzdesi için de tam uygulama ister; pct<100 uygun değildir. Güncel RFC 9989 bu etiketi tarihsel olarak sınıflandırdığından, onu bütün DMARC kurulumlarının zorunlu yeni alanı gibi düşünmeyin.

DMARC’ı hâlâ p=none modunda çalıştırıyorsanız, BIMI ile ilerlemeden önce Gelişmiş DMARC ve BIMI rehberimizde anlattığımız gibi raporlara bakarak DMARC politikanızı sıkılaştırmanız çok kritik.

BIMI DNS kaydı nasıl yazılır?

Örnek bir BIMI kaydı şu şekilde görünür:

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://static.example.com/brand/logo-bimi.svg; a=https://static.example.com/brand/example-vmc.pem"

• v=BIMI1: Sürüm alanıdır.
• l=: Uygun logo dosyasının HTTPS adresidir.
• a=: Sağlayıcının kabul ettiği VMC/CMC kanıt dosyasının HTTPS adresidir. Bu örnekte dosya VMC’yi temsil eder; gerçek sertifika zinciri CA yönergelerine göre hazırlanmalıdır. Alanı boş bırakmak Gmail koşullarını karşılamaz.

Gmail’in güncel kurulum belgesi, logo PEM içine gömüldüğünde l= boş ve a= PEM adresi olacak bir kayıt da gösterir. Kullanacağınız kaydı hedef sağlayıcının desteklediği biçime göre seçin.

Logo ve kanıt dosyasını kararlı HTTPS adreslerinde sunun; sertifika süresini, içerik türünü ve dosya erişimini izleyin. Statik barındırma veya CDN kullanılabilir, ancak erişim kısıtlamaları sağlayıcının dosyayı almasını engellememelidir. DCHost hesabınızda bu yolu seçiyorsanız ilgili planın dosya ve alt alan desteğini doğrulayın.

BIMI’nin iş faydaları: Neden uğraşmaya değer?

BIMI, destekleyen gelen kutularında markanın tanınmasına yardımcı olabilir. Ancak tıklama oranını, kullanıcı güvenini veya teslim edilebilirliği otomatik artırdığı söylenemez:

• DMARC, görünen alan adının yetkisiz kullanımına karşı politika sağlar; BIMI bu politikanın yerine geçmez.
• Gösterilen logo kullanıcının markayı ayırt etmesine yardımcı olabilir, fakat iletinin içeriğinin güvenli olduğu anlamına gelmez.
• Gelen kutusuna yerleşim, itibar ve içerik gibi başka etkenlere bağlıdır. Etkileşimdeki etkiyi kendi gönderim verilerinizle ölçerek değerlendirin.

MTA‑STS, TLS‑RPT ve BIMI’yi birlikte düşünmek

Şimdi bu üç mekanizmayı birlikte ele alalım. Alan adınız için ideal tabloyu şöyle özetleyebiliriz:

• Gönderim için SPF, DKIM, DMARC ve gerekli PTR/ileri DNS eşleşmesi doğru; BIMI hedefleniyorsa DMARC tam uygulamada.
• Gelen posta kabul eden alan adında test edilmiş mode: enforce politikası; bütün gerekli MX’ler ve sertifikaları uyumlu.
• TLS-RPT raporları ile SMTP günlükleri birlikte izleniyor.
• BIMI hedef sağlayıcının logo, VMC/CMC ve itibar koşullarına göre kurulmuş.

Böyle bir kurulumun pratikte size sağladığı avantajlar:

• Taşıma denetimi: Politikayı uygulayan uyumlu göndericiler uygunsuz MX/TLS yoluna teslimat yapmaz.
• Gözlemlenebilirlik: Katılan göndericilerin bağlantı sonuçları sorun araştırmasını destekler.
• Kimlik ve görünürlük: DMARC hizalaması ile BIMI logo uygunluğu ayrı ayrı değerlendirilir; hiçbiri tüm oltalama girişimlerini veya spam kararlarını ortadan kaldırmaz.

Örnek senaryo 1: KOBİ kurumsal alan adı + paylaşımlı e‑posta altyapısı

Aşağıdaki senaryo, koşulları sağlayan bir paylaşımlı hizmet için örnek çalışma planıdır:

1. Gönderici doğrulaması: Posta sağlayıcısının yetkili SPF kaynaklarını ve gerçek DKIM imzalamasını kurun. DMARC’ı raporlarla değerlendirin; mevcut sıkı politikayı sırf yeni kurulum diye gevşetmeyin.
2. MTA-STS: İzin verilen MX adlarını ve sertifikalarını sağlayıcıdan doğrulayın. mta-sts.example.com/.well-known/mta-sts.txt HTTPS yolunu hazırlayıp testing modunu ve _mta-sts TXT kaydını yayımlayın.
3. TLS-RPT: _smtp._tls kaydını, izlenen tls-report@example.com gibi bir alıcıya yöneltin.
4. Uygulama: Meşru göndericiler ve alıcı MX yolları doğrulandıktan sonra DMARC ile MTA-STS uygulama kararlarını ayrı verin; sabit 1–2 ay beklemek doğrulamanın yerini tutmaz.
5. BIMI: Uygun logo ve gereken VMC/CMC dosyalarıyla hedef sağlayıcının koşullarını karşılayın.

Süre; DNS yetkisi, posta sağlayıcısıyla koordinasyon, gözlemlenen trafik ve logo sertifikası hazırlığına bağlıdır. Panel erişimi tek başına bütün MX sunucularının TLS yapılandırmasını yönetme yetkisi vermez.

Örnek senaryo 2: SaaS ürünü + ayrı gönderim alan adı

Eğer SaaS veya yüksek hacimli transactional e‑posta gönderen bir yapınız varsa, ayrı gönderim alan adı kullanma stratejisini incelemenizi öneririz. Bu durumda:

• example.com kurumsal alan adı olarak kalabilir; gelen posta için MTA-STS/TLS-RPT, gönderim kimliği için SPF/DKIM/DMARC değerlendirilir.
• mail.example.com veya notify.example.com gibi alt alanlar belirli gönderim akışlarına ayrılabilir.
• Gönderim alt alanında gereken SPF/DKIM/DMARC kimlikleri ayrıca yapılandırılır. MTA-STS, dışarı gönderimi korumak için değil o alt alana gelen postanın teslimatı için anlamlıdır; gelen posta kabul ediyorsa kendi politikası gerekir, üst alan politikası otomatik miras alınmaz. BIMI kapsamı görünen From kimliği ve sağlayıcı kurallarına göre belirlenir.

Akışları ayırmak yönetimi kolaylaştırabilir; aynı IP’nin veya ilişkili alan adlarının itibarı yine birbirini etkileyebilir. Ayrı alt alan, ana markanın itibarını yalıtma garantisi değildir.

Adım adım uygulama rehberi

1. DNS sağlayıcınızı ve otoriteyi netleştirin

Önce hangi platformun alan adınız için yetkili DNS sağladığını netleştirin. NS kayıtları DCHost’a mı, farklı bir DNS servisine mi işaret ediyor? DNS kayıt türlerine dair rehberimiz bu noktada referans olabilir.

2. MTA‑STS için alt alan ve politika dosyasını hazırlayın

1. Politika hostunu hazırlayın: mta-sts.example.com için DNS, barındırma ve bu ada uygun HTTPS sertifikasını kurun.
2. Dosyayı yayımlayın: /.well-known/mta-sts.txt yolunda mode: testing, gerçek MX listesi ve seçilmiş max_age bulunsun.
3. Erişimi doğrulayın: Tam URL doğrudan 200 ve düz metin dönmeli; giriş, yönlendirme veya bot doğrulama sayfası araya girmemelidir.
4. Keşif kaydını ekleyin: Dosya hazır olduktan sonra _mta-sts.example.com için v=STSv1; id=2025010101 gibi tek geçerli TXT değeri yayımlayın. Tarih benzeri id yalnız örnektir.
5. MX’leri sınayın: SMTP sertifikasının SAN DNS-ID alanını gerçek MX adıyla karşılaştırın; yedek MX’leri de denetleyin.

3. TLS‑RPT raporlama adresini planlayın

1. Raporları okuyacağınız veya sisteme entegre edeceğiniz bir e‑posta adresi belirleyin (örn. tls-report@example.com).
2. DNS’e şu kaydı ekleyin:

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-report@example.com"

3. Gelen raporların imzasını ve zaman aralığını doğrulayın; sertifika/politika hatalarını SMTP günlükleriyle ilişkilendirin. Rapor henüz gelmediyse DNS, rapor kutusu ve gönderici katılımını araştırın.

4. BIMI için logo ve DMARC politikasını hazır hale getirin

1. DMARC: Meşru göndericilerin hizalamasını doğrulayıp BIMI için gereken tam uygulamayı sağlayın.
2. Logo: SVG Tiny PS dosyasını hazırlayın ve hedef sağlayıcının ölçü/biçim koşullarını doğrulayın.
3. Barındırma: Logo ve gerekiyorsa PEM dosyasını kararlı HTTPS adresine koyun.
4. VMC/CMC: Hedef sağlayıcının kabul ettiği sertifika türünü CA koşullarıyla birlikte değerlendirin. Gmail için sertifikasız kayıt yeterli değildir.
5. TXT: Aşağıdaki sertifikasız örneği yalnız bunu destekleyen sağlayıcılar için kullanın; genel bir Gmail kurulum örneği değildir.

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://brand.example.com/logo-bimi.svg; a="

VMC veya CMC kullandığınızda a= alanını gerçek PEM adresiyle doldurun. Gmail’in logo gömülü PEM biçiminde l= boş olabilir. DNS kaydını eklemek logo gösterimini veya görünür bir doğrulama işaretini garanti etmez.

DCHost altyapısında dikkat etmeniz gereken pratik noktalar

Paylaşımlı hosting, VPS, dedicated veya colocation seçeneklerinde operasyon sorumlulukları farklıdır. Planın koşullarına göre şu noktaları doğrulayın:

• Tek MX, çoklu IP: Politikaya mx: mail.example.com gibi host adı yazılır; bu adın bütün IPv4/IPv6 yollarında uygun TLS sunulmalıdır.
• Yedek MX: mx2.example.com gibi kullanılabilecek yedekleri politikaya ekleyip ayrı test edin; ana yol çalışırken raporlar yedekteki hatayı göstermeyebilir.
• TTL ve önbellek: DNS TTL’siyle politika max_age değerini ayrı yönetin. Kısa yeni değer, eski önbelleği hemen kısaltmaz; değişiklik planı önceki değerleri de kapsamalıdır.
• DNSSEC: Doğrulayan çözümleyicilerde imzalı DNS yanıtlarını korur; HTTPS/SMTP sertifika denetiminin yerine geçmez. DNSSEC rehberini ilgili kayıtların imza zinciri ve bakım sorumluluğuyla birlikte değerlendirin.
• İzleme: Sertifika yenilemeleri, politika erişimi ve SMTP/TLS hataları için uygun günlük ve uyarıları kurun; araç kurulması tek başına kapsama garantisi değildir.

Sonuç: E‑posta güvenliğini ve markanızı aynı anda güçlendirmek mümkün

MTA-STS, TLS-RPT ve BIMI farklı ihtiyaçlara yanıt verir: gelen SMTP teslimatına politika, bağlantı sonuçlarına görünürlük ve uygun iletilere marka logosu. Bunları doğru DNS, TLS ve gönderici kimliği yönetimiyle birlikte değerlendirin; her alan adı için aynı özelliklerin zorunlu olduğu varsayımından kaçının.

Seçtiğiniz barındırma türü ne olursa olsun, sonuçları şu ayrı kontrollerle değerlendirin:

• Uyumlu göndericilerin gerçek MX yollarında politikayı uygulaması.
• Rapor kapsamının ve SMTP günlüklerinin birlikte izlenmesi.
• Meşru iletilerin DMARC hizalaması ve hedef sağlayıcıda BIMI dosyalarının uygunluğu.

Başlamak için DNS yetkisini, gerçek MX adlarını, sertifikaları ve gönderici akışlarını envantere alın. DCHost hizmeti kullanıyorsanız planınızda hangi adımları sizin, hangilerini sağlayıcının yönettiğini netleştirin. Ardından test, uygulama ve bakım sorumluluklarını içeren bir geçiş planı oluşturun.