Bir e-posta gönderiyorsunuz. Meşru olduğunu biliyorsunuz — kendi alan adınızdan, gerçek bir insan tarafından yazılmış, gerçek bir iş hakkında. Ve yine de spam'e düşüyor. Ya da daha kötüsü, hiçbir yere düşmüyor: geri dönüş yok, hata yok, sadece sessizlik, çünkü bazı alıcı sunucular onu sessizce düşürdü.
Eğer hiç "mesaj gönderildi" onayına bakarken, bir şekilde, mesajın asla okunmayacağını biliyorsanız — bu sizin için. Bir kontrol listesi değil. Gerçek bir araştırmanın gittiği sırayla, gerçekte neyin bozuk olduğunu nasıl bulacağınıza dair bir rehber.
Kimsenin düzgün açıklamadığı üç harfli kısaltmalar
Herhangi bir şeyde hata ayıklamadan önce, gerçekte neyin kontrol edildiğini anlamak yardımcı olur, çünkü başarısızlık modları yalnızca her mekanizmanın ne için olduğunu bildiğinizde anlam kazanır.
SPF (Sender Policy Framework) tek bir soruya yanıt verir: "Bu sunucunun bu alan adı için posta göndermesine izin var mı?" Bu, sizin adınıza göndermeye yetkili IP adreslerini ve hizmetleri listeleyen bir DNS TXT kaydıdır. Bir e-posta geldiğinde, alıcı sunucu zarf gönderenini — gördüğünüz "Kimden" adresiyle her zaman aynı olmayan gerçek SMTP işleminde kullanılan adresi — bu listeye karşı kontrol eder. Gönderen sunucu listede değilse, SPF başarısız olur.
DKIM (DomainKeys Identified Mail) farklı bir soruya yanıt verir: "Bu mesaj gerçekten iddia ettiği alan adı tarafından mı gönderildi, ve değiştirildi mi?" Gönderim anında e-postayı özel bir anahtarla kriptografik olarak imzalayarak ve eşleşen genel anahtarı DNS'te yayınlayarak çalışır. Alıcı sunucu genel anahtarı çeker, imzayı doğrular ve mesajın iletim sırasında değiştirilmediğini onaylar. SPF'nin aksine, DKIM hangi sunucunun postayı gönderdiğini umursamaz — imzanın geçerli olup olmadığını umursar.
DMARC (Domain-based Message Authentication, Reporting and Conformance) her ikisinin üstünde oturan politika katmanıdır. Alıcı sunuculara SPF veya DKIM başarısız olduğunda ne yapacaklarını söyler — karantinaya alın, doğrudan reddedin, veya hiçbir şey yapmayın ve sadece size geri bildirin. DMARC ayrıca "hizalama" kontrolünü de etkinleştirir: SPF veya DKIM'in bireysel olarak geçmesi yeterli değildir, kontrol ettikleri alan adı, görünen "Kimden" başlığında gerçekte olanla eşleşmelidir. Bu, neredeyse herkesin kaçırdığı kısımdır, ve SPF ve DKIM her ikisi de bireysel olarak iyi göründüğünde ve posta hâlâ başarısız olduğunda genellikle gerçek kök nedendir.
Ne olması gerektiğiyle değil, gerçekte ne olduğuyla başlayın
İçgüdü, DNS kayıtlarınızı açıp yukarıdan aşağıya okumaya başlamak ve bir yazım hatası aramaktır. Bunu henüz yapmayın — niyeti okuyorsunuz, sonucu değil, ve ikisi genellikle gerçek bir teslimat girişimine bakana kadar görünmez şekillerde anlaşmazlığa düşer.
Bunun yerine, başarısız olmuş veya spam'e düşmüş gerçek bir mesaj alın ve başlıklarına bakın. Her büyük posta sağlayıcısı (Gmail, Outlook vb.) alınan bir e-postanın "orijinal" veya "ham" versiyonunu görmenize izin verir, ki bu bir Authentication-Results başlığı içerir — bu, alıcı sunucunun kendi sözleriyle tam olarak neyi kontrol ettiğini ve ne olduğunu size anlatmasıdır.
Şuna benzer görünür:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounce@yourdomain.com designates 203.0.113.5 as permitted sender)
dkim=pass header.i=@yourdomain.com header.s=selector1
dmarc=fail (p=REJECT sp=REJECT dis=none) header.from=yourdomain.comBunu dikkatlice okuyun. SPF geçti. DKIM geçti. DMARC yine de başarısız oldu. Bu, çoğu rehberin açıklamadığı tam senaryodur, çünkü çelişkili görünür — her şey geçti, öyleyse neden bütünüyle başarısız oldu?
Cevap hizalamadır. SPF bounce@yourdomain.com'a karşı geçti — bu zarf gönderenidir, genellikle geri dönüş işleme için kullanılan farklı bir alt alan adı (pazarlama platformları, işlemsel e-posta hizmetleri ve üçüncü taraf bir gönderen kullanan her şey için yaygın). DKIM yourdomain.com için geçti. Ama DMARC, görünen From başlığındaki alan adının — alıcının gerçekte gördüğü şeyin — SPF veya DKIM'in kimlik doğruladığı ile eşleşip eşleşmediğini kontrol eder. Görünen From'unuz yourdomain.com ise ama SPF geçişiniz düzgün şekilde hizalanmamış bir geri dönüş işleme alt alan adı içinse, bireysel kontroller temiz görünse bile DMARC başarısız olur.
Bir başlık analizörünün tam olarak bunun için olduğu yer burasıdır — ham SMTP başlıklarını elle ayrıştırmanıza gerek kalmadan bunu ayrıştırmak. MarinaDNS'in E-posta Başlığı Analizi aracını tam olarak bu an için oluşturdum: başarısız bir mesajın ham başlıklarını yapıştırın, ve Authentication-Results sözdizimini elle çözmek yerine kimlik doğrulama zincirini ayrı geçiş/başarısızlık/hizalama sonuçlarına ayırır.
Şimdi DNS'inizin gerçekte ne dediğini kontrol edin, ne söylediğini düşündüğünüzü değil
Hangi kontrolün başarısız olduğunu bildiğinizde, gerçekte yayınlanan kaydı doğrulamaya gidin — çünkü düşündüğünüzü söylemediğine dair çok iyi bir şans var. E-posta kimlik doğrulaması için DNS kayıtları, ince şekillerde yanlış yapılması kolay olmasıyla ünlüdür: fazladan bir boşluk, eksik bir ~all, tek olması gereken ama iki TXT girdisine bölünmüş bir kayıt, e-posta sağlayıcınızın döndürdüğü ve DNS'te asla güncellenmemiş bir DKIM seçicisi.
Yaygın başarısızlık desenleri, gerçekte ne sıklıkla ortaya çıktıklarına göre kabaca sıralı:
SPF kaydı arama sınırını aşıyor. SPF, değerlendirme sırasında maksimum 10 DNS aramasına izin verir — her include: mekanizması sayılır, ve iç içe geçerler. Google Workspace, Mailchimp ve SendGrid gibi işlemsel bir hizmeti hepsini tek bir SPF kaydında kullanıyorsanız, her biri kendi iç içe include'larıyla, fark etmeden 10'u aşmak kolaydır. Bu olduğunda, çoğu doğrulayıcı zarif bir şekilde başarısız olmaz — bir permerror döndürürler, ve alıcı sunucular genellikle bunu doğrudan bir başarısızlık olarak ele alır, "şüpheden yararlanma hakkı" olarak değil.
Tek bir birleştirilmiş kayıt yerine birden fazla SPF kaydı. Spesifikasyon açıkça bir alan adının tam olarak bir SPF TXT kaydına sahip olması gerektiğini söyler. Önceki bir sağlayıcı bir tane eklediyse ve daha sonra eskisini kaldırmadan yeni bir tane eklendiyse, şimdi ikiniz var, ve RFC 7208'e göre bu otomatik bir kalıcı hatadır — tüm mekanizma, birisi fark edene kadar sessizce bozulur.
DKIM seçici uyuşmazlığı. Her DKIM imzası, alıcı sunucuya hangi belirli DNS TXT kaydının genel anahtarı tuttuğunu söyleyen bir selector belirtir (imzanın d= ve s= etiketlerinde görülür) — çünkü bir alan adının farklı hizmetler için aynı anda birkaç aktif DKIM anahtarı olabilir. E-posta sağlayıcınız anahtarları döndürdüyse ve DNS yeni seçiciyle güncellenmediyse, ya da iki hizmet kullanıyorsanız (diyelim ki normal posta için Google Workspace ve kampanyalar için bir pazarlama platformu) ve sadece bir seçici yayınlanmışsa, uyuşmayan imzalar, DKIM teknik olarak yapılandırılmış olsa bile başarısız olur.
Hizalamanın gerçekten çalıştığı doğrulanmadan önce DMARC politikası p=reject'e ayarlandı. Bu, küçük bir kimlik doğrulama boşluğunu tam bir posta kaybına dönüştüren şeydir. DMARC'ın raporlama modu (p=none) özellikle, alıcı sunuculara hizalanmayan her şeyi reddetmelerini söylemeden önce, toplu raporları izleyip her meşru gönderme kaynağının doğru şekilde hizalandığını doğrulayabilmeniz için var. Genellikle bir güvenlik denetiminin alan adını sıkı DMARC'a sahip olmadığı için işaretlemesi nedeniyle yapılan, önce p=none ve sonra p=quarantine'den geçmeden doğrudan p=reject'e atlamak, "bazı e-postaların neden ortadan kaybolduğunu anlayamıyoruz" durumunun en yaygın tek nedenidir.
MarinaDNS'in SPF/DKIM/DMARC Kontrolü tam olarak bunu yakalamak için oluşturulmuştur — bir alan adı için canlı kayıtları çeker ve sadece bir kaydın var olduğunu onaylamak yerine tam olarak bu desenleri (arama sayısı, yinelenen kayıtlar, eksik hizalama) işaretler.
Sekmeyi kapatmak istemeden bir DMARC toplu raporunu okumak
DMARC raporlar göndermek üzere ayarlandıysa (politikada rua= etiketi), bunu düzgün düzeltmek için ihtiyacınız olan veriyi zaten alıyorsunuz — sadece alan adınızdan geldiğini iddia eden bir mesaj alan her büyük posta alıcısından günde bir kez, sıkıştırılmış bir XML dosyası olarak teslim ediliyor. Kimse bunları elle açmaktan hoşlanmaz, ve bu isteksizlik tam olarak neden bu kadar çok alan adının yıllarca sadece-raporlama modunda DMARC çalıştırdığının ve kimsenin gerçekten raporları okumadığının nedenidir.
XML gürültüsünden arındırılmış yapı temelde şudur:
- Hangi IP sizin adınıza olduğunu iddia eden posta gönderdi
- SPF geçti mi, ve hizalı mıydı
- DKIM geçti mi, ve hizalı mıydı
- Kaç mesaj bu desene uydu
Yararlı hamle, kaynak IP'ye göre gruplandırmak ve her biri için sormaktır: bunu tanıyor muyum? Evet ise, ve hizalamayı başarısız oluyorsa, bu düzeltmeniz gereken meşru bir hizmetteki yapılandırma boşluğudur. Hem SPF hem de DKIM'i başarısız olan posta gönderen tanımadığınız bir IP ise, birisi alan adınızı taklit etmeye çalışıyor demektir — ve DMARC'ın var olma nedeni tam olarak budur. Sadece tanımadık IP'lerden tutarlı hizalama başarısızlıkları görmek, bilinen gönderme hizmetlerinizden tutarlı geçişlerle birlikte, aslında zorlamaya geçmeden önceki sağlıklı durumdur — meşru postanın hizalandığı ve başarısızlıkların yanlış yapılandırma değil sahtecilik girişimi olduğu anlamına gelir.
Gerçekte neyin düzelttiği, yapılacak sırayla
Hangi katmanın neden başarısız olduğunu bildiğinizde, düzeltme genellikle mekaniktir:
- Tek bir SPF kaydında birleştirin. İkiniz varsa, gerekli tüm
include:mekanizmalarını birleştirerek tek bir TXT kaydında birleştirin. - 10 arama sınırına yakınsanız SPF include'larını düzleştirin veya kısaltın. Bazı hizmetler, tam olarak bunu önlemek için iç içe include'lar yerine statik IP'lere çözümlenen "düzleştirilmiş" SPF parçacıkları sunar.
- Her gönderme hizmetinin DKIM seçicisinin sadece gönderen platform tarafında yapılandırılmadığından, gerçekten DNS'te yayınlandığından emin olun — bunlar iki ayrı adımdır ve birinin diğeri yapılmadan yapılması yaygındır.
- Henüz orada değilseniz önce DMARC'ı
p=none'a ayarlayın, en az tam bir gönderme döngüsü boyunca raporları izleyin (sadece günlük işlemsel posta değil, aylık bültenler veya toplu işler dahil), sonrap=quarantine'e geçin, ve sadece raporlar her meşru kaynaktan tutarlı hizalama gösterdiğindep=reject'e geçin.
Sıra, bireysel adımlardan daha önemlidir. SPF hizalamasını kontrol etmeden DKIM'i düzeltmek, veya önce bir raporlama dönemi olmadan doğrudan katı DMARC zorlamasına atlamak, her bireysel kayıt teknik olarak doğru olsa bile bunun yanlış gitmesinin iki yoludur.
Şu anda teşhis ortasındaysanız, en hızlı yol: başarısız mesajın ham başlıklarını hangi katmanın başarısız olduğunu ve bunun bir hizalama sorunu olup olmadığını görmek için bir analizöre çekin, sonra yayınlananın gerçekte amaçladığınızla eşleşip eşleşmediğini görmek için canlı DNS kayıtlarını bir kontrol aracıyla kontrol edin. On seferden dokuzunda, bu iki şey arasındaki boşluk sorunun tamamıdır.