SPF ve DMARC kontrolü: kayıtlarınızı nasıl sorgular, okur ve düzeltirsiniz

SPF, DKIM ve DMARC ayrı ayrı neyi denetler

SPF ve DKIM okuyucunun hiç görmediği bir alan adı için geçebilir. DMARC bu boşluğu hizalama ile kapatır: SPF veya DKIM, From alan adıyla hizalı bir alan adı için geçerse ileti geçer; hizalı tek bir geçiş yeterlidir. Varsayılan olan esnek hizalama yalnızca aynı kurumsal alan adını ister; yani bounce.example.com, example.com ile hizalanır. Katı hizalama birebir eşleşme ister.

Varsayımsal bir bülten hizmeti bunun neden önemli olduğunu gösterir. Hizmet news@example.com adıyla gönderir ama zarf göndereni olarak example.net üzerindeki kendi bounce alan adını kullanır. SPF example.net için geçer ama bu hizalı değildir; dolayısıyla DMARC yalnızca hizmet d=example.com ile DKIM imzalarsa geçer.

Kayıtları dig veya nslookup ile sorgulama

Yalnızca dig (Linux, macOS) veya nslookup (Windows) yeterlidir:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

SPF kaydı, v=spf1 ile başlayan TXT kaydıdır; diğer hizmetlerin doğrulama belirteçleri çoğu zaman yanında durur. DMARC kaydı, _dmarc altındaki v=DMARC1 ile başlayan TXT kaydıdır. SPF’i zarf göndereni alan adında kontrol edin; bu, From alan adından farklı olabilir. Teslim edilmiş bir iletinin Return-Path başlığı bunu gösterir.

DKIM anahtarları dışarıdan listelenemez, çünkü her biri bir seçicinin altındadır. Gönderdiğiniz bir iletinin DKIM-Signature başlığındaki s= ve d= değerlerini okuyun, ardından o adı sorgulayın; örneğin dig +short TXT s1._domainkey.example.com.

Bir değişiklikten sonra çözümleyiciler TTL süresi dolana kadar eski yanıtı sunabilir. Şu anda yayımlanan kaydı görmek için dig +short NS example.com ile yetkili sunucuları bulun ve birini doğrudan sorgulayın: dig +short TXT example.com @ns1.example.net. Ardından kontrolünüzdeki bir posta kutusuna gerçek bir ileti gönderin ve Authentication-Results başlığını okuyun. Alıcının SPF, DKIM ve DMARC için ne karar verdiğini gösterir; geçerli olan sonuç budur.

SPF kaydı nasıl okunur

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

Mekanizmalar soldan sağa değerlendirilir ve eşleşen ilk mekanizma sonucu belirler. Her birinin bir niteleyicisi olabilir: + geçer (varsayılan), - başarısız, ~ yumuşak başarısız, ? nötr.

~all mı -all mı

~all, listede olmayan sunucuların büyük olasılıkla yetkili olmadığını söyler; alıcılar yalnızca buna dayanıp reddetmemelidir. -all onların yetkili olmadığını söyler; sonrası alıcının kendi politikasıdır. İkisi de makuldür ve Almanya’nın BSI kurumu ikisini de kabul eder. RFC 9989 bir uyarı ekler: -all ile, SPF’i SMTP oturumunun başında denetleyen bir alıcı, hizalı DKIM’in geçireceği bir iletiyi (tipik olarak yönlendirilmiş postayı) reddedebilir ve bu ret DMARC raporlarında görünmez. ?all veya hiç all olmaması listede olmayan sunucular hakkında hiçbir şey söylemez. +all internetteki her IP adresinin geçmesine izin verir; asla yayımlamayın.

10 sorgu sınırı

Alıcılar en fazla 10 DNS sorgulayan terimi değerlendirir; dahil edilen kayıtların içindekiler de sayılır (bölüm 4.6.4). Aşılırsa sonuç permerror olur ve SPF artık bir iletinin DMARC’ı geçmesine yardımcı olamaz. Yanıt döndürmeyen sorgular için ayrı bir sınır vardır: bunlardan ikiden fazlası da permerror ile sonuçlanmalıdır. Dört terim gösteren bir kayıt, dahil edilen kayıtların kendi include’ları varsa yine de sınırı aşabilir; bu yüzden özyinelemeli sayın. Sınırın altına inmek için artık kullanmadığınız hizmetleri kaldırın, kontrol ettiğiniz adresler için ip4/ip6 yazın ve yüksek hacimli hizmetleri kendi SPF kaydı olan ayrı bir bounce alt alan adına taşıyın. Bir sağlayıcının IP aralıklarını kaydınıza kopyalayan düzleştirme, sağlayıcı aralıkları değiştirince eskir.

Ad başına tek kayıt

Aynı ad üzerinde v=spf1 ile başlayan iki TXT kaydı permerror üretir; bunları birleştirin. 255 karakterden uzun bir kayıt, alıcıların boşluksuz birleştirdiği birkaç tırnaklı dize olarak tek bir TXT kaydına yazılır. SPF devralınmaz da: example.com üzerindeki kayıt mail.example.com adını kapsamaz; zarf göndereni olarak kullanılan her adın kendi kaydı olmalıdır.

DMARC kaydı nasıl okunur

DMARC artık RFC 9989 (Mayıs 2026); RFC 7489’un yerini alan bir standart izleyen belirtimdir. Kayıt yine _dmarc altında durur ve v=DMARC1 ile başlar:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

example.com üzerindeki kayıt, kendi kaydı olmayan alt alan adlarını da kapsar; alıcılar kaydı RFC 9989’un DNS Tree Walk dediği yöntemle bulur. Toplu rapor gönderen alıcılar bunları genellikle günlük XML dosyaları olarak iletir; dosyalar alan adınız adına gönderen IP adreslerini ve sonuçlarını listeler. rua bir rapor hizmeti gibi başka bir kurumsal alan adına işaret ediyorsa, o alan adı example.com._report._dmarc.reports.example.net gibi v=DMARC1 ile başlayan bir TXT kaydı yayımlamalıdır (RFC 9990, bölüm 4); aksi hâlde alıcılar bu adresi yok sayar.

None’dan reject’e

1. Alan adı adına gönderen her hizmeti listeleyin: posta platformu, bülten, CRM, faturalama, destek masası, web sitesi formları.
2. rua ile birlikte p=none yayımlayın ve raporları okuyun.
3. Her meşru kaynağı hizalamayla geçene kadar düzeltin; mümkünse DKIM üzerinden, çünkü DKIM yönlendirmeyi genellikle atlatır, SPF atlatamaz.
4. quarantine’e geçin, isterseniz önce t=y ile; ardından reject’i düşünün.

RFC 9989, kullanıcıları posta listelerine yazan alan adlarının reject yayımlamaması gerektiğini (SHOULD NOT) söyler; yine de isteyenler önce en az bir ay none’da, sonra aynı süre quarantine’de kalıp sonuçları karşılaştırmalıdır. Reject yayımlayan her alan adı postasını DKIM ile imzalamalıdır (MUST). Almanya’nın BSI TR-03182 belgesi daha katı bir çizgi izler: gönderen alan adı reject istemelidir (SHOULD). Yalnızca fatura ve bildirim için kullanılan bir alan adı, çalışanlarınızın posta listelerinde kullandığı bir alan adından farklı bir durumdur. RFC 9989 ayrıca alıcılara yalnızca p=reject nedeniyle reddetmemelerini söyler, ama uygulamada From satırı değişmeyen liste postasının sık sık reddedildiğini kabul eder.

Posta göndermeyen alan adları

Park edilmiş, yazım hatası koruması amaçlı veya yalnızca yönlendirme yapan alan adları yine de sahte bir From satırında görünebilir. RFC 7208, posta göndermeyen alan adları için SPF kaydı yayımlamayı köklü bir iyi uygulama olarak niteler. Varsayımsal park edilmiş bir alan adı için eksiksiz küme:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

SPF kaydı kimseyi yetkilendirmez ve burada kaybedilecek meşru posta olmadığı için p=reject hiçbir şeye mal olmaz. RFC 7505’teki null MX alan adının posta kabul etmediğini söyler; raporlar example.com’a gider ve example.com’un example.net._report._dmarc.example.com kaydını yayımlaması gerekir. BSI TR-03182 bu aynı birleşimi kullanılmayan alan adları için MUST olarak listeler. DMARC politikası alt alan adlarını kapsar ama SPF kapsamaz; bu yüzden kendi A veya MX kaydı olan her alt alan adına da v=spf1 -all verin.

Gmail, Yahoo ve Outlook.com göndericilerden ne istiyor

Kasım 2025’ten beri Gmail, retler dahil olmak üzere uygulamayı sıkılaştırıyor. Google’ın kuralları kişisel Gmail hesaplarını kapsar, Google Workspace alıcılarını değil. Google ve Yahoo en az 1024 bitlik DKIM anahtarları ister. Microsoft gereksinimleri karşılamayan postayı 550 5.7.515 ile reddeder. Üçü de p=none kabul eder; bu kuralı karşılar ama sahte posta hakkında bir tercih bildirmez. Onu bitmiş yapı olarak değil, bir aşama olarak görün.

MTA-STS ve CAA: kontrol edilecek iki kayıt daha

MTA-STS (RFC 8461) gelen postayı korur: göndericilere, MX ana makineleriniz güvenilir bir sertifikayla TLS sunmuyorsa teslim etmemelerini söyler. _mta-sts.example.com adresinde v=STSv1; id=20261001000000Z; gibi bir TXT kaydı ve https://mta-sts.example.com/.well-known/mta-sts.txt adresinde mod, MX adları ve max_age değerlerini listeleyen bir politika dosyası gerekir. testing modunda başlayın; göndericiler yine teslim eder ve TLS raporlaması _smtp._tls.example.com adresinde kurulmuşsa hataları bildirir. Sonra enforce’a geçin. Politika her değiştiğinde id değerini değiştirin.

CAA (RFC 8659) alan adı için TLS sertifikası vermeye yetkili sertifika otoritelerini belirtir; örneğin CAA 0 issue "ca.example.net". Herkese açık CA’lar vermeden önce bunu kontrol etmelidir; yetkili bir CA’nın hatalı sertifika vermesini engellemez ve tarayıcılar bunu kullanmaz. example.com üzerindeki kayıt, kendi kaydı olmayan alt alan adlarını kapsar. CDN’inizinki dahil kullandığınız her CA’yı listeleyin, yoksa yenilemeler başarısız olabilir. TLS ve güvenlik başlıkları rehberi sertifikaları daha ayrıntılı ele alır.

Sık görülen SPF ve DMARC hataları ve çözümleri

Ücretsiz Yayına Hazırlık Snapshot’ı e-posta DNS’inizde neyi kontrol eder

Ücretsiz Yayına Hazırlık Snapshot’ı, kayıt gerekmeden tek bir herkese açık origin üzerinde sekiz pasif kontrol yapar. Sızma testi değildir ve altı alanlı denetim de değildir. Sekiz kontrolden biri e-posta DNS kayıtlarını okur:

• Tam ana makine adı. MX, TXT, _dmarc, _mta-sts ve CAA, girdiğiniz ana makine adında sorgulanır; üst alan adına geri dönülmez. www.example.com üzerinde kaydın olmaması, example.com’un korumasız olduğu anlamına gelmez. Posta alan adınızın kayıtlarını okutmak için alan adının kendisini girin (www.example.com yerine example.com); snapshot’ın puan üretmesi için bir adrese çözümlenmesi gerekir.
• SPF. Eksik kayıt yalnızca ana makinenin MX kayıtları varsa işaretlenir (orta). +all yüksek risk, ?all düşük risk olarak işaretlenir; ~all ve -all bir şey doğurmaz. On’dan fazla DNS sorgulayan terim işaretlenir (orta), ancak include: izlenmediği için yalnızca üst düzey kayıttaki terimler sayılır.
• DMARC. Eksik kayıt yalnızca ana makinenin MX kayıtları varsa işaretlenir (orta). p=none izleme modu olarak işaretlenir (düşük); quarantine veya reject geçti sayılır. sp, pct, rua ve hizalama değerlendirilmez.
• MTA-STS ve CAA. Eksik _mta-sts TXT kaydı yalnızca ana makinenin MX kayıtları varsa işaretlenir (düşük); politika dosyası alınmaz. Herhangi bir CAA kaydı geçti sayılır, hiç olmaması düşük bir sinyaldir; içeriği sertifikanızla karşılaştırılmaz.
• Kontrol edilmeyenler: DKIM, TLS raporlama ve DNSSEC.

Bir puan ve not, bir sertleştirme notu, risk sinyalleri ile geçen kontrollerin sayısı, en ciddiden başlayarak en fazla üç sinyal ve her e-posta DNS satırı dahil tüm kontroller derecelendirmesiyle birlikte listelenir. Bir adrese çözümlenmeyen ad puan almaz. Web sitesi yayın kontrol listesi sekiz kontrolün tamamını adım adım anlatır; DNS ve e-posta güvenliği rehberi ise süregelen incelemeyi ele alır.

Bu kontrolle başlamak için ücretsiz SPF ve DMARC kontrolünü kullanın: aynı snapshot’ı çalıştırır ve e-posta DNS kontrolünü açık hâlde diğer yedi kontrolün üstünde listeler.