E-posta Yöneticisi Olmadan SPF, DKIM ve DMARC Sonuçlarını Okuma

Adım adım

1. 1

   Zihinsel modeli kurun: üç soru, üç kayıt

   Her kayıt, alıcı posta sunucusunun sorduğu bir soruya cevap verir. SPF: 'Bu iletiyi teslim eden sunucunun bu alan adı için posta göndermeye izni var mı?' — izinli göndericilerin DNS'teki listesidir. DKIM: 'Bu ileti alan adı tarafından imzalandı mı ve yolda değiştirilmedi mi?' — gönderici kriptografik bir imza ekler, imzayı denetleyecek açık anahtar DNS'te durur. DMARC: 'SPF veya DKIM sonuçları, insanın From satırında gördüğü alan adıyla gerçekten eşleşiyor mu; eşleşmiyorsa ne yapmalıyım?' — diğer ikisini görünen From adresine bağlar, üstüne bir politika ve raporlama ekler. Bir ileti herhangi bir alan adı için SPF ve DKIM'den geçip yine de DMARC'tan kalabilir; çünkü DMARC, geçen alan adının From alan adıyla hizalanmasında ısrar eder.

2. 2

   Gerçek bir SPF kaydını parça parça okuyun

   SPF bir TXT kaydında yaşar ve soldan sağa okunur. Şunu ele alalım: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all. v=spf1 etiketi kaydın SPF olduğunu belirtir. ip4: bir IP adresini veya aralığını doğrudan yetkilendirir. include: başka bir alan adının SPF kaydını içeri alır — Google Workspace'i, Mailchimp'i veya CRM'inizi sizin adınıza göndermeye yetkilendirmenin yolu budur. Sondaki 'all' terimi, öncesinde eşleşmeyen her sunucu için varsayılan hükümdür: ~all (softfail) 'yetkisiz göndericiler şüphelidir ama sert reddetme' der; -all (fail) ise 'doğrudan reddet' der. Softfail temkinli geçiş dönemi tercihidir; -all, listenin eksiksiz olduğundan emin olduğunuzda varılacak son noktadır.

3. 3

   10 DNS sorgusu sınırına dikkat edin

   SPF standardı, denetim başına değerlendirmeyi 10 DNS sorgusuyla sınırlar; include:, a, mx ve birkaç mekanizmanın her biri bir sorgu tüketir, iç içe include'lar da sayılır. Sınırı aşarsanız alıcılar kalıcı hata ('permerror') döndürür — pratikte bu, kayıttaki her servis gerçekten sizin olsa bile meşru postanızın SPF geçerliliğini yitirmesi anlamına gelebilir. Bu, büyüyen şirketleri sürekli ısırır: her yeni SaaS aracı 'include kaydımızı SPF'inize ekleyin' der ve yedinci araç sizi sessizce sınırın üstüne iter. Bir denetleyici sorgu sayısını 10'a yakın veya üstünde raporluyorsa sadeleştirin: artık kullanmadığınız servisleri çıkarın ve varsa sağlayıcıların düzleştirilmiş veya birleşik include kayıtlarını tercih edin.

4. 4

   DKIM seçicilerini (selector) anlayın

   Bir alan adının aynı anda birden çok DKIM anahtarı olabilir ve seçiciler bunların bir arada var olma yoludur. İletideki imza başlığı bir seçici adı verir (s=google, s=k1, s=mail…), alıcı da açık anahtarı DNS'te selector._domainkey.alanadi.com adresinden çeker. Her gönderici servis tipik olarak kendi seçicisini kullanır; bir posta sağlayıcısını kurarken tuhaf adlı bir iki CNAME veya TXT kaydı eklemenizin nedeni budur. DKIM'i dışarıdan denetlerken hangi seçiciyi sorgulayacağınızı bilmeniz gerekir — bir alan adının tüm seçicilerini listelemenin standart bir yolu yoktur. Bunu gerçek bir iletide bulun: ham başlıkları görüntüleyin, DKIM-Signature satırını bulun ve s= etiketini okuyun.

5. 5

   DMARC politika satırını çözün

   DMARC, _dmarc.alanadi.com adresindeki bir TXT kaydında yaşar ve şöyle görünür: v=DMARC1; p=quarantine; rua=mailto:raporlar@alanadi.com. p= etiketi, DMARC'tan kalan postalar için alıcılara iletilen istektir: p=none 'normal teslim et ama bana rapor gönder' demektir — izleme modu; p=quarantine 'şüpheli muamelesi yap' demektir ve genellikle spam klasörüne düşürür; p=reject 'geri çevir' demektir. rua= etiketi toplu raporların gideceği adrestir: alıcılar, alan adınız olduğunu iddia ederek posta gönderenlerin kimler olduğunu ve nasıl doğrulandığını özetleyen XML raporlarını düzenli aralıklarla gönderir. Yıllarca p=none'da duran bir alan adı, yaptırım anlamında 'DMARC ile korunuyor' değildir — yalnızca gözlemliyordur. Sahteciliği gerçekten engelleyen, quarantine veya reject'e geçmektir ve bu, raporlar tüm meşru kaynakların geçtiğini gösterdikten sonra yapılmalıdır.

6. 6

   Klasik hata kalıplarını tanıyın

   Yönlendirme SPF'i bozar: bir ileti yönlendirildiğinde iletiyi yönlendiren sunucu teslim eder ve o sunucu asıl alan adının SPF listesinde yoktur — posta meşru olsa da SPF başarısız olur. DMARC'ın SPF veya DKIM'den herhangi birini kabul etmesinin nedeni tam olarak budur: DKIM imzası iletinin içinde taşınır ve yönlendirici içeriği değiştirmedikçe genellikle yönlendirmeden sağlam çıkar (altbilgi ekleyen e-posta listeleri bunu bozmasıyla meşhurdur). İkinci klasik, hizalama eksikliğidir: toplu posta sağlayıcınız teknik zarfta kendi alan adıyla gönderir, SPF sağlayıcının alan adı için geçer ama o alan adı sizin From alan adınızla eşleşmediği için DMARC kalır. Çözüm, sağlayıcının ayarlarında kendi alan adınız için özel dönüş yolu (return path) ve DKIM imzalama yapılandırmaktır.

7. 7

   Alan adınızı E-posta Kimlik Doğrulama Denetleyici ile kontrol edin

   E-posta Kimlik Doğrulama Denetleyiciaracını açın ve alan adınızı girin. Sonuçları şu sırayla okuyun: SPF kaydı var mı, tam olarak bir tane mi (birden çok SPF kaydı geçersizdir), nasıl bitiyor (~all mı -all mı) ve kaç DNS sorgusu kullanıyor? DMARC var mı, p= nedir ve raporları toplayan bir rua= adresi var mı? DKIM için göndericilerinizin kullandığı seçicileri denetleyin. Amaç kupa gibi bir ekran görüntüsü değil; somut eksiklerin listesini çıkarmak: 'DMARC kaydı yok', 'SPF ?all ile bitiyor', 'sorgu sayısı 11'. Bunların her biri belirli ve düzeltilebilir bir maddedir.