Bu araç sunucuda çalışır
Nasıl çalışır
E-posta protokolü göndereni doğrulamaz: herhangi bir sunucu alan adınızı gönderen olarak yazabilir. Üç DNS kaydı bu kapıyı kapatır. SPF, alan adı adına hangi sunucuların gönderebileceğini listeler. DKIM her mesajı, ortak anahtarı DNS'te yayımlanan özel bir anahtarla imzalar. DMARC ikisini birleştirir: en az birinin geçmesini ve görünen gönderen alan adıyla eşleşmesini ister, alıcıya başarısız olanlarla ne yapacağını söyler ve adınıza gönderilen her şey hakkında rapor ister.
Şubat 2024'ten bu yana Gmail ve Yahoo, kullanıcılarına günde 5000'den fazla mesaj gönderen herkesten SPF, DKIM ve DMARC istiyor; bunlardan birinin eksikliği reddedilen e-postalar veya spam klasörü demek. Bu yüzden üçünü birlikte kontrol etmek gerekir: kusursuz bir SPF, DMARC olmadan pek işe yaramaz; kötü yayımlanmış bir DKIM ile reject'e ayarlanmış DMARC ise kendi postanızı dışarıda bırakır.
Kontrol, herhangi bir posta sunucusunun yapacağı gibi, sunucumuzdan herkese açık DNS sorgularıyla yapılır. SPF tamamen değerlendirilir; DNS sorgularını saymak için her include ve redirect izlenir, çünkü 10 sınırını aşmak tüm kaydı geçersiz kılar. MX kayıtları ile isteğe bağlı MTA-STS, TLS-RPT ve BIMI kayıtları da sorgulanır.
Örnekler
github.comSPF · 10 / 10Sekiz sağlayıcı include'u (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) ve onların dahil ettikleri, değerlendirmeyi tam 10 DNS sorgusu sınırına getirir. Bir sağlayıcı daha eklenirse tüm SPF kalıcı hata verir.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sE-posta göndermeyen ve almayan bir alan adı için doğru yapılandırma: boş MX, kimseyi yetkilendirmeyen SPF ve reject'e ayarlı DMARC. Sahtecilikte sık hedef alınan park edilmiş alan adlarını korur.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Kademeli bir geçiş: başarısız mesajların yalnızca dörtte biri spam'e gider ve raporlar rua'da belirtilen posta kutusuna gelir; böylece henüz kimliği doğrulanmamış meşru göndericileri tespit edersiniz.Kullanım senaryoları
- Alan adının e-postalarının neden spam'e düştüğünü veya Gmail, Outlook ya da Yahoo tarafından reddedildiğini teşhis etmek.
- CRM veya bülten platformu gibi yeni bir gönderim sağlayıcısı eklemeden önce SPF'nin 10 DNS sorgusunu aşmadığından emin olmak.
- Bir sağlayıcının DKIM anahtarının kurulumdan sonra doğru yayımlandığını doğrulamak.
- DMARC'ı meşru postayı kesmeden none'dan quarantine'e ve reject'e geçirmeyi planlamak.
- Bir müşterinin veya satın alınan bir şirketin alan adlarını, e-posta göndermemesi gereken park edilmiş olanlar dahil denetlemek.
- Bir oltalama girişimini analiz ederken şüpheli bir göndericinin yapılandırmasını incelemek.
Sık sorulan sorular
Alan adım e-postalarını imzalıyorsa neden DKIM bulunamadı diyor?
Çünkü DKIM bir alan adının anahtarlarını listelemeye izin vermez: her biri <seçici>._domainkey.<alan adı> adresinde bulunur ve sorgulamak için seçiciyi bilmek gerekir. Araç en yaygın seçicileri dener, ancak birçok sağlayıcı kendine özgü veya tarihli adlar kullanır. Alan adından gönderilmiş bir e-postayı açın, DKIM-Signature başlığını bulun ve s= değerini kopyalayın; o seçiciyle kontrol kesin olur.
SPF 10 DNS sorgusunu aşarsa ne olur?
RFC 7208, alıcının kalıcı hata (permerror) döndürmesini zorunlu kılar ve DMARC açısından bu, SPF'nin başarısız olduğu anlamına gelir. include, a, mx, ptr ve exists mekanizmaları ile redirect değiştiricisi, her include içindekiler de dahil olmak üzere sorgu tüketir; ip4 ve ip6 tüketmez. Sayıyı düşürmek için artık kullanılmayan sağlayıcıları kaldırın, include'ları ip4 aralıklarıyla değiştirin veya kendi SPF'si olan alt alan adlarından gönderin.
~all mı -all mı?
DMARC etkinken fark küçüktür: alıcı SPF niteleyicisini değil DMARC politikasını uygular. ~all olağan seçimdir, çünkü bazı alıcılar -all ile DKIM'i değerlendirmeden hemen reddeder ve bu, DKIM'in kurtaracağı yönlendirilmiş e-postaların kaybolmasına yol açabilir. DMARC yoksa, yetkisiz postanın reddedilmesini istemenin tek yolu -all'dır.
DMARC'ı e-posta kaybetmeden none'dan reject'e nasıl geçiririm?
p=none ve rua'da bir adresle başlayın ve birkaç hafta toplu raporları okuyun: alan adınızla gönderen her sunucuyu ve SPF ya da DKIM'den geçip geçmediğini gösterirler. Eksik meşru göndericilerin kimliğini doğrulayın, düşük pct ile quarantine'e geçin, pct'yi yavaş yavaş artırın ve reject ile bitirin. Doğrudan reject'e geçmek genellikle faturalama sistemlerini, CRM'leri veya kimsenin hatırlamadığı iç sistemleri dışarıda bırakır.
1024 bitlik bir DKIM anahtarı yeterli mi?
Çalışır, çünkü RFC 8301 alıcıların 1024 ile 4096 bit arasındaki anahtarları kabul etmesini zorunlu kılar; ancak aynı standart imzalayanların en az 2048 kullanmasını önerir. 1024'ün altındaki anahtarlar geçerli sayılmaz. 2048'e geçmek kolaydır: yeni anahtarı başka bir seçiciyle yayımlayın, imzalamayı değiştirin ve ardından p'yi boş bırakarak eskisini iptal edin.
MTA-STS, TLS-RPT ve BIMI ne işe yarar?
MTA-STS (RFC 8461), gönderen sunuculardan MX'lerinize teslim ederken TLS zorunlu tutmalarını ister; bu, bağlantıyı düz metne düşüren saldırıları önler. TLS-RPT (RFC 8460), bu teslimler başarısız olduğunda size rapor gönderir. BIMI, destekleyen istemcilerde gönderenin yanında marka logosunu gösterir ve yalnızca quarantine veya reject'teki DMARC ile çalışır. Hiçbiri zorunlu değildir ama üçü de katkı sağlar.