DMARC Sorgulama ve Kontrol

Bir alan adının DMARC kaydını alıcı posta sunucusunun okuduğu gibi sorgulayın: politikanın nerede bulunduğunu, geçemeyen e-postalara ne olduğunu, raporların birine ulaşıp ulaşmadığını ve uygulamaya geçmeden önce SPF ile DKIM'in neye ihtiyaç duyduğunu görün.

Güncellendi: 25 Ekim 2026

Kaynaklar: alan adının ve üst alan adlarının _dmarc TXT kayıtları, Google Public DNS üzerinden (arkasında Cloudflare 1.1.1.1) · RFC 9989 ağaç taraması · RFC 9990'a göre rapor yetkilendirmesi · kendi denetleyicilerimizden SPF ve DKIM · sizinle ilgili hiçbir şey kaydedilmez

DMARC kaydı nasıl kontrol edilir?

Yukarıya bir alan adı yazın: denetleyici DNS'ten _dmarc. artı alan adındaki TXT kaydını ister, kayıt yoksa kurumsal alan adına kadar yukarı çıkar (RFC 9989 §4.10) ve alıcı sunucunun geçemeyen e-postaya ne yaptığını gösterir.

Elle aynı adı sorun: dig +short TXT _dmarc.paypal.com veya Windows'ta nslookup -type=TXT _dmarc.paypal.com. v=DMARC1 ile başlayan tek bir yanıt kayıttır; iki yanıt, alıcıların hiçbirini kullanmadığı anlamına gelir (RFC 9989 §4.10).

dig orada durur. Bir alt alan adından yukarı çıkmaz, rapor adreslerinin raporları kabul edip etmediğini denetlemez ve alıcının hangi RFC'yi izlediğini söylemez. Denetleyicinin eklediği şey budur.

% dig +short TXT _dmarc.example.com

Addaki her yanıt. v=DMARC1 ile başlayan tek yanıt kayıttır.

dig'in gösterdiği ve göstermediği

terminal

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

1Ad, _dmarc. artı alan adıdırAlan adının kendisi değil: paypal.com üzerindeki bir TXT, SPF'nin yeridir.
2Tek kayıt, önce v=DMARC1Tek adda iki kayıt: alıcılar ikisini de atar (RFC 9989 §4.10).
3Etiketler, ; ile ayrılmışp politikadır; rua ve ruf raporların nereye gideceğini söyler.
4Burada bir şey yok mu? Yukarı çıkın_dmarc.mail.google.com NXDOMAIN: google.com kaydı geçerli.

paypal.com kaydı, Google Public DNS'in 24 Ekim 2026 tarihinde döndürdüğü haliyle; mail.google.com'un kendi kaydı yok.

Sonucu okumak: alıcının görünümü

Yanıt önce gelir, bir cümle olarak. Altında kanıtlar var: alıcıların ayrıştırdığı haliyle kayıt, her etiket tam karakterleri üzerinde renkli ve lacivert zeminde bir alıcı sunucunun bu alan adı için izlediği yol; yol, geçemeyen e-postaya ne yaptığıyla biter.

Puan yok: none politikası bir aşamadır, başarısızlık değil; yolun altındaki merdiven de sonraki adımın neye ihtiyaç duyduğunu söyler.

paypal.com için DMARC kontrolü: DMARC'ı geçemeyen e-postaları reddeder, alıcının görünümü ve uygulama merdiveniyle — paypal.com için bir DMARC kontrolü: karar, etiketlerine bölünmüş kayıt, her DNS sorusuyla ve geçemeyen e-postaya olanlarla alıcının görünümü ve uygulama merdiveni. Her bölümün ne gösterdiğini görmek için bir numara seçin.

DMARC ne işe yarar?

DMARC, alıcı posta sunucularına, alan adınızı From: satırında kullanan ama sizden geldiğini kanıtlayamayan e-postalara ne yapacaklarını ve bunlarla ilgili raporları nereye göndereceklerini söyler (RFC 9989 §4.7).

Kanıt, From: alan adıyla hizalı bir SPF veya DKIM'dir: aynı kuruluştaki bir geri dönüş (bounce) alan adı için geçen SPF ya da d= değeri alan adınız olan bir DKIM imzası. Tek bir hizalı geçiş yeterlidir (RFC 9989 §5.3.5); geri kalan her şey DMARC'ı geçemez ve kaydın politikası karar verir: teslim et, spam klasörü ya da reddet.

Raporlar diğer yarıdır. rua değerine uyan alıcılar, alan adınız adına gönderen her sunucunun günlük bir özetini gönderir; uygulamaya geçmeden önce unuttuğunuz meşru göndericileri böyle bulursunuz.

İki ileti, tek From: satırı

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

Bir e-posta hizmetiyle gönderilen faturanızözel DKIM kurulmuş bir hizmet üzerinden, bu yüzden d=example.com ile imzalar

SPFpass · bounces.esp.example (hizalı değil)
DKIMpass · d=example.com (hizalı)
DMARCpass: tek bir hizalı sonuç yeterli

Teslim edildi

203.0.113.9 adresinden sahte bir faturaexample.com'un hiç yetkilendirmediği bir sunucu

SPFfail · 203.0.113.9 listede yok
DKIMnone · imza yok
DMARCfail → p=reject

Reddedildi

550 5.7.1 Email rejected per DMARC policy for example.com

Yarınki toplu rapor dmarc@example.com adresine: 203.0.113.9 adresinden 1 ileti, SPF fail, DKIM none, disposition reject.

Geçmek teslim edileceği anlamına gelmez (alıcının filtreleri yine karar verir) ve p=reject altındaki bir başarısızlık bir emir değil, bir istektir (RFC 9989 §5.4, §7.4). Adresler RFC 5737'den; yanıt metni RFC 9989'un kendi örneğidir.

DMARC kaydı etiketleri açıklandı

Bir DMARC kaydı, _dmarc. artı alan adındaki bir TXT kaydında etiket=değer çiftlerinin listesidir: önce v=DMARC1, ardından politika, hizalama ve rapor etiketleri herhangi bir sırada (RFC 9989 §4.7).

RFC 9989 (Mayıs 2026), RFC 7489'un yerini aldı. np, psd ve t ekledi; pct, rf ve ri etiketlerini kaldırdı: güncel alıcılar bunları yok sayar, hâlâ RFC 7489 kullanan alıcılar ise okur; bu yüzden pct=25 içeren bir kayıt farklı alıcılar için farklı anlama gelir.

Yayımlamadığınız etiketler varsayılanlarını alır ve denetleyici bunları da gösterir: eksik bir sp, alt alan adlarının p aldığı anlamına gelir.

Her etiket, ne yaptığına göre

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1

SürümPolitikaTest ve son ekHizalamaRaporlarKaldırıldı

Etiket	Neyi belirler	Varsayılan	Durum	Görüldüğü yer
v	SürümDMARC1	zorunlu, ilk	RFC 9989	192
p	Alan adı politikasınone · quarantine · reject	eksikse ve rua geçerliyse none	RFC 9989	192
sp	Var olan alt alan adları politikasınone · quarantine · reject	p	RFC 9989	39
np	Var olmayan adlar politikasınone · quarantine · reject	sp, sonra p	RFC 9989'da yeni	2
t	Test modu: politikanın bir basamak altıy · n	n	RFC 9989'da yeni	0
psd	Genel son ek (y) veya kurumsal alan adı (n)y · n · u	u	RFC 9989'da yeni	1
adkim	DKIM hizalamasır · s	r	RFC 9989	20
aspf	SPF hizalamasır · s	r	RFC 9989	24
rua	Toplu raporların gittiği yermailto:…	rapor yok	RFC 9989	186
ruf	Hata raporlarının gittiği yermailto:…	rapor yok	RFC 9989	120
fo	Hata raporlarının ne zaman gönderileceği0 · 1 · d · s	0	RFC 9989	96
pct	Politikanın uygulandığı geçemeyen e-posta payı0–100	–	kaldırıldı	70
rf	Hata raporu biçimiafrf	–	kaldırıldı	9
ri	Rapor aralığı, saniye86400	–	kaldırıldı	14

Görüldüğü yer: 196 tanınmış alan adının yayımladığı 192 DMARC kaydının kaçında etiket var (24 Ekim 2026 tarihinde okundu; 70 pct etiketinin 69 tanesi pct=100 diyor). Varsayılanlar ve durum RFC 9989 §4.7 ve Ek C'den.

DMARC politikası: p=none, quarantine veya reject

p=none alıcılardan geçemeyen e-postayı her zamanki gibi teslim etmelerini ve yalnızca raporlamalarını ister; quarantine onu şüpheli saymalarını, genellikle spam klasörüne koymalarını ister; reject ise SMTP konuşması sırasında reddetmelerini ister.

None bir aşamadır, başarısızlık değil: RFC 9989 §7.4, raporlar akarken burada en az bir ay, reject'ten önce quarantine'de de bir o kadar daha önerir. İnsanları posta listelerine yazan alan adları quarantine'de durmalıdır.

Büyük posta kutusu sağlayıcıları da bunu böler: gmail.com ve outlook.com alan adının kendisi için p=none, alt alan adları için sp=quarantine yayımlar; google.com, yahoo.com ve microsoft.com ise reject yayımlar.

Sahte bir iletinin vardığı yer

Teslim edildip=none

apache.orggmail.comsamsung.com

192 içinde 23

Spam klasörüp=quarantine

github.comapple.comamazon.com

192 içinde 30

Reddedildip=reject

google.compaypal.commicrosoft.com

192 içinde 139

Alıcılar son kararı verir: p=reject altında geçemeyen e-postayı teslim edebilirler ve yalnızca politikaya dayanarak reddetmemelidirler (RFC 9989 §5.4, §7.4). Bir hizmet sağlayıcının çalışması, web'in geri kalanının ne kadar geride olduğunu gösteriyor: en büyük 1,8 milyon alan adında 2026 başında EasyDMARC, p=none için %29,2, quarantine veya reject için %22,9 buldu.

DMARC gerçekten gerekli mi?

Evet, Gmail, Yahoo veya Outlook.com'a toplu gönderiyorsanız: üçü de bir DMARC kaydı ister ve kuralı karşılamak için p=none yeterlidir. Uygulama (quarantine veya reject), başkalarının alan adınız adına göndermesini engelleyen şeydir ve BIMI logoları bunu gerektirir.

Gmail bunu, Gmail hesaplarına günde 5.000 iletiden fazla gönderenlerden 1 Şubat 2024 itibarıyla ister; Yahoo Şubat 2024 itibarıyla, hacim belirtmeden; Outlook.com 5 Mayıs 2025 itibarıyla, günde 5.000 üzerinde ister. Kayıt yoksa Gmail 4.7.31 (From: hizalı değilse 4.7.32), Outlook.com ise 550 5.7.515 ile reddeder.

Hiçbir şey göndermeyen bir alan adı için DMARC, var olan en ucuz korumadır: p=reject, bir null MX ve v=spf1 -all, example.com'un yayımladığı gibi (M3AAWG).

Her posta kutusu sağlayıcısının toplu göndericilerden istediği

Gmail1 Şub 2024Gmail hesaplarına günde 5.000+4.7.31 · 4.7.32

YahooŞub 2024yayımlanmış eşik yokDMARC geçmeli

Outlook.com5 May 2025günde 5.000+550 5.7.515

Teslim edildip=noneüç sağlayıcının kuralını da karşılar

Spam klasörüquarantinesahteciliğin çoğunu durdurur · BIMI logoları mümkün

Reddedildirejectsahteciliği kapıda durdurur · BIMI

✓Gerekli: bir kayıt, p=none veya daha sıkıiKoruma: quarantine veya reject

Her sağlayıcının kendi gönderici sayfalarından, 24 Ekim 2026 tarihinde okundu. %0,3 altında bir spam oranı ve tek tıkla abonelikten çıkma da kurallardır, ancak DNS bunları gösteremez; denetleyicinin Gereksinimler görünümü hangi kısımları kanıtlayabildiğini söyler.

DMARC hataları nasıl düzeltilir: yönlendirme, posta listeleri, bir sağlayıcının kendi alan adı

Başarısız olan kaynağı toplu raporlarınızda bulun ve göndericide düzeltin: kendi alan adınız için DKIM ile imzalayın veya kuruluşunuzdaki bir geri dönüş alan adına taşıyın. Üç neden hataların çoğunu açıklar.

Yönlendirme DKIM imzasını korur ama SPF'yi bozar; bu yüzden geçişi DKIM taşır. İletiyi düzenleyen posta listeleri ikisini de bozar. Kendi alan adıyla imzalayan bir e-posta hizmeti DKIM'i kendisi için geçer, sizin için değil: hizmetin özel DKIM'ini (genellikle s1._domainkey gibi CNAME'ler) ve özel bir geri dönüş yolunu açın.

Üç hata, rapor ne gösteriyor ve çözüm

Yönlendirme

SPF192.0.2.80, example.com SPF'sinde yok
DKIMimza bozulmadı

Rapor gösterirspf=fail dkim=pass → pass

Her şeyi DKIM ile imzalayın; DKIM yönlendirmeden sağ çıkar. ARC (RFC 8617), yönlendiricilerin güvence vermesine yardımcı olur.

Posta listesi

SPFlistenin sunucusu gönderir
DKIMgövde değişti: özet uyuşmaz

Rapor gösterirspf=fail dkim=fail → fail

From: değerini yeniden yazan listeler bunu çözer; insanları listelere yazan alan adları quarantine'de kalır (RFC 9989 §7.4).

Bir sağlayıcının kendi alan adı

SPFbounces.esp.example için pass: hizalı değil
DKIMesp.example için pass: hizalı değil

Rapor gösterirdkim=pass(esp.example) → fail

Sağlayıcının özel DKIM'ini açın: paypal.com'un s1 ve s2 kayıtları, paypal.com adına imzalayan SendGrid'e CNAME'dir.

Adresler RFC 5737'den; esp.example bir yer tutucudur. SendGrid CNAME'leri paypal.com'un gerçek seçicileridir (24 Ekim 2026).

Alt alan adları için DMARC: sp ve np

Kendi kaydı olmayan bir alt alan adı, kurumsal alan adının politikasını alır: var olan alt alan adları için sp, var olmayan adlar için np; her biri yoksa p değerine döner (RFC 9989 §4.7).

Kendi kaydını yayımlayan bir alt alan adı onu kendisi için kullanır. Ama bir ad ile kurumsal alan adı arasındaki bir kayıt o ad için asla kullanılmaz: berkeley.edu ağacı bunu gösterir; eecs.berkeley.edu'nun sp=none değeri www.eecs.berkeley.edu'ya ulaşmaz (RFC 9989 §4.10.1).

np ucuz bir kazançtır: var olmayan adlar gerçek e-posta göndermez; bu yüzden p hâlâ none iken bile np=reject onlardan gelen sahtecilikleri engeller. RFC 7489 alıcıları np'yi bilmez ve sp kullanır.

berkeley.edu ağacı, bir alıcının okuduğu gibi

berkeley.edup=reject; np=reject; psd=n; rua=…kendi kaydı · psd=n: kurumsal alan adıReddedildi

www.berkeley.edukayıt yokvar → sp, yok → pReddedildi

eecs.berkeley.edup=reject; sp=none; rua=…kendi kaydı → pReddedildi

www.eecs.berkeley.edukayıt yoktarama: eecs.berkeley.edu kaydı atlanır (kurumsal alan adı değil) → berkeley.edu'nun p değeriReddedildi

nosuch-x7.berkeley.eduNXDOMAINyok → npReddedildi

eecs.berkeley.edu'nun sp=none değeri hiç uygulanmaz: bir ad ile kurumsal alan adı arasındaki kayıt o ad için kullanılmaz (RFC 9989 §4.10.1). Denetleyici onu kullanılmayan bir kayıt olarak işaretler.

24 Ekim 2026 tarihinde Google Public DNS üzerinden okundu. nosuch-x7.berkeley.edu uydurma bir addır; NXDOMAIN yanıtı gerçektir.

DMARC raporlarını okumak (rua)

Toplu rapor, her alıcıdan gelen günlük bir XML dosyasıdır; alan adınız adına e-posta gönderen her sunucuyu, kaç ileti olduğunu ve SPF, DKIM ve DMARC'ın geçip geçmediğini listeler (RFC 9990).

Kaynağa göre okuyun: kendi sunucularınız ve hizmetleriniz hizalı bir geçiş göstermeli; başarısız olan bilinen bir hizmetin özel DKIM'e ihtiyacı var; p=reject altında başarısız olan bilinmeyen bir adres sahteciliktir, durdurulmuştur. Bir rapor hizmeti (dmarcian, Valimail, EasyDMARC, Postmark ve diğerleri) binlerce dosyayı bu listeye çevirir.

Başka bir alan adındaki adrese giden raporlar yalnızca o alan adı kabul ederse ulaşır: v=DMARC1 içeren yourdomain._report._dmarc.its-host yayımlar (RFC 9990 §4). Denetleyici bunu sizin için sorar ve eksikse tam kaydı verir.

Bir rapor, satır satır okundu

<org_name>google.com</org_name>1

<date_range>23 Eki 00:00 UTC – 24 Eki 00:00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

1Kim raporladıAlıcı başına günde bir dosya (RFC 9990: en az 24 saatte bir).
2Bulduğu politika_dmarc.example.com adında okuduğu.
3Yönlendirilen e-posta, DKIM ile kurtarıldıSPF yönlendiricide başarısız oldu; hizalı imza DMARC'ı geçti.
4Sahtecilik, durdurulduBilinmeyen bir sunucu, hiçbir şey hizalı değil, reddedildi.

paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ yetkili: raporlar akıyor

Denetleyicinin tanıdığı rapor hizmetleridmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 tane daha

XML kısaltılmış ve uydurulmuştur (belge adresleri, RFC 5737); yetkilendirme kaydı paypal.com'un gerçek kaydıdır, 24 Ekim 2026 tarihinde okundu.

DMARC kontrolü: sık sorulan sorular

DMARC nedir?

DMARC, alan adınızı From: satırında kullanan ama SPF ve DKIM hizalamasını geçemeyen e-postalara alıcı posta sunucularının ne yapacağını söyleyen bir DNS kaydıdır: teslim et, karantinaya al ya da reddet. Alıcıların bu e-postalarla ilgili raporları nereye göndereceğini de belirtir. _dmarc artı alan adınızdaki bir TXT kaydı olarak yayımlanır ve Mayıs 2026'da RFC 7489'un yerini alan RFC 9989 ile tanımlanır.

Bir DMARC kaydı denetleyicisi ne gösterir?

_dmarc artı alan adındaki TXT kaydını, yoksa üst alan adlarınınkini, bir alıcının yaptığı gibi okur. Bu araç kaydı etiket etiket varsayılanlarıyla, alan adı, alt alan adları ve var olmayan adlar için politikayı, rapor adreslerinin raporları kabul edip etmediğini ve alan adının SPF kaydı ile DKIM anahtarlarını puan vermeden gösterir.

DMARC nasıl test edilir?

Yayımlanmış politikayı görmek için yukarıdan alan adını kontrol edin: DNS'in yanıtlayabileceği DMARC testi budur. Gerçek bir iletinin geçip geçmediğini görmek için kontrol ettiğiniz bir posta kutusuna ileti gönderin ve Authentication-Results başlığını okuyun ya da başlıkları E-posta Başlık Analizi'ne yapıştırın. DMARC doğrulayıcı kaydın sözdizimini denetler; SPF veya DKIM'in hizalanıp hizalanmadığını yalnızca bir ileti gösterir.

Hangi DMARC politikasıyla başlamalıyım?

p=none ve bir rua adresiyle başlayın; böylece alıcılar teslimatı değiştirmeden size günlük rapor gönderir. Başarısız olan her meşru göndericiyi, genellikle özel DKIM'ini açarak düzeltin, sonra quarantine'e ve en sonunda reject'e geçin. RFC 9989, p=none'da en az bir ay, quarantine'de de bir o kadar daha önerir. E-posta göndermeyen bir alan adı doğrudan p=reject'e geçebilir.

p=none alan adımı korur mu?

Hayır. p=none, alıcılardan geçemeyen e-postayı her zamanki gibi işlemelerini ister; bu yüzden sahte bir iletiyi yalnızca kendi spam filtreleri değerlendirir. Verdiği şey raporlardır ve Gmail, Yahoo ve Outlook.com toplu gönderici kuralını karşılar. Onu bir izleme aşaması olarak görün: koruma quarantine ile başlar, reject ise sahte e-postayı kimseye ulaşmadan durdurur.

DMARC kaydında t=y ne anlama gelir?

t=y, RFC 9989'un test modudur: alıcılar yayımlanan politikanın bir basamak altını uygular; yani p=reject quarantine gibi, p=quarantine none gibi davranır. p=none üzerinde etkisi yoktur ve raporları değiştirmez. Hâlâ RFC 7489 kullanan alıcılar etiketi bilmez ve politikayı yazıldığı gibi uygular. Raporlar tüm meşru göndericilerin hizalandığını gösterdiğinde t=y'yi kaldırın.

pct etiketi hâlâ kullanılıyor mu?

RFC 9989, 0 ve 100 dışındaki değerler tutarsız uygulandığı için pct'yi rf ve ri ile birlikte kaldırdı. Güncel alıcılar onu yok sayar ve politikayı geçemeyen tüm e-postalara uygular. Hâlâ RFC 7489 kullanan alıcılar örnekleme yapar: quarantine ile pct=25, geçemeyen e-postanın dörtte birini spama gönderir, kalanını teslim eder. pct=100 zararsızdır; test aşaması için t=y kullanın.

rua adresim neden "yetkili değil" görünüyor?

Raporlar başka bir kurumsal alan adındaki bir posta kutusuna gittiğinde, o alan adının yourdomain._report._dmarc.its-host adında v=DMARC1 değerli bir TXT kaydı yayımlayarak kabul etmesi gerekir (RFC 9990 §4). Olmazsa denetleyen alıcılar adresi atlar. Kayıt sizin değil, hedefin DNS'ine girer: rapor hizmetleri tüm müşteriler için bir joker karakter yayımlar; bu yüzden genellikle bir yazım hatası ya da bir iş ortağının posta kutusudur.

Alt alan adlarının kendi DMARC kaydı gerekir mi?

Genellikle hayır. Kaydı olmayan bir alt alan adı, kurumsal alan adının politikasını alır: var olan alt alan adları için sp, var olmayan adlar için np; ikisi de yoksa p değerine döner. Bir alt alan adında yalnızca farklı bir politikaya ihtiyaç duyduğunda kayıt yayımlayın. www.team.example.com için team.example.com gibi ara bir addaki kayıt, daha derindeki ad için kullanılmaz.

Bir alan adı iki DMARC kaydı yayımlarsa ne olur?

Alıcılar ikisini de atar; bu yüzden biri reject dese bile hiçbir DMARC politikası geçerli olmaz ve rapor gönderilmez (RFC 9989 §4.10). Genellikle eski kayıt silinmeden yenisi eklendiğinde ya da DNS barındırıcısı varsayılan bir kayıt eklediğinde olur. _dmarc adında tek kayıt tutun ve diğerini silin; denetleyici hangisinin amaçlanan olduğunu gösterir.

SPF geçerken DMARC neden başarısız oluyor?

DMARC, SPF'nin From: adresiyle hizalı bir alan adı için geçmesini ister. Çoğu e-posta hizmeti kendi geri dönüş alan adıyla gönderir; bu yüzden SPF onlar için geçer, sizin için değil ve bu sayılmaz. Hizmetin alan adıyla imzalanan DKIM için de aynısı geçerlidir. Geçen alan adının sizin olması için hizmetin özel DKIM'ini veya özel geri dönüş yolunu kurun.

Denetleyici kayıt yok diyor ama az önce ekledim. Neden?

Önce ana bilgisayar alanına bakın: çoğu DNS paneli yalnızca _dmarc ister; oraya _dmarc.example.com yazmak _dmarc.example.com.example.com oluşturur. Sonra eski yanıtın süresinin dolmasını bekleyin: ad daha önce sorgulandıysa çözümleyiciler NXDOMAIN yanıtını bölgenin negatif TTL süresi boyunca, çoğu zaman 5 dakika ile bir saat arasında tutar. SERVFAIL veya zaman aşımı "kontrol edilemedi" olarak görünür, hiçbir zaman kayıt yok olarak değil.