DMARC-Check — DMARC-Eintrag prüfen

Der DMARC-Check liest den DMARC-Eintrag jeder Domain so, wie ihn ein empfangender Mailserver liest: wo die Richtlinie gefunden wird, was mit Mails passiert, die durchfallen, ob Berichte jemanden erreichen und was SPF und DKIM brauchen, bevor Sie die Richtlinie durchsetzen.

Quellen: die _dmarc-TXT-Einträge der Domain und ihrer übergeordneten Domains, über Google Public DNS (dahinter Cloudflare 1.1.1.1) · RFC 9989 Tree Walk · Berichtsautorisierung nach RFC 9990 · SPF und DKIM aus unseren eigenen Checkern · nichts über Sie wird gespeichert

Wie prüfe ich einen DMARC-Eintrag?

Geben Sie oben eine Domain ein: Der Check fragt im DNS den TXT-Eintrag bei _dmarc. plus der Domain ab, läuft bei fehlendem Eintrag zur Organisationsdomain hinauf (RFC 9989 §4.10) und zeigt, was ein empfangender Server mit Mails tut, die durchfallen.

Von Hand fragen Sie denselben Namen ab: dig +short TXT _dmarc.paypal.com, unter Windows nslookup -type=TXT _dmarc.paypal.com. Eine Antwort, die mit v=DMARC1 beginnt, ist der Eintrag; bei zwei Antworten verwenden Empfänger keine von beiden (RFC 9989 §4.10).

dig hört dort auf. Es läuft nicht von einer Subdomain nach oben, prüft nicht, ob die Berichtsadressen die Berichte annehmen, und sagt nicht, welchem RFC ein Empfänger folgt. Genau das ergänzt der Check.

dig +short TXT _dmarc.example.com

Jede Antwort beim Namen. Eine, die mit v=DMARC1 beginnt, ist der Eintrag.

Was dig zeigt und was nicht

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

  1. 1Der Name ist _dmarc. plus die DomainNicht die Domain selbst: Ein TXT bei paypal.com ist der Platz für SPF.
  2. 2Ein Eintrag, v=DMARC1 zuerstZwei Einträge bei einem Namen: Empfänger verwerfen beide (RFC 9989 §4.10).
  3. 3Tags, getrennt durch ;p ist die Richtlinie; rua und ruf sagen, wohin Berichte gehen.
  4. 4Hier nichts? Weiter nach oben_dmarc.mail.google.com ist NXDOMAIN: Der Eintrag von google.com gilt.
Der Eintrag von paypal.com, wie Google Public DNS ihn am 24. Oktober 2026 lieferte; mail.google.com hat keinen eigenen.

Das Ergebnis lesen: die Sicht des Empfängers

Die Antwort steht zuerst, als Satz. Darunter die Belege: der Eintrag, wie Empfänger ihn auslesen, jeder Tag farbig über seinen genauen Zeichen, und auf Marineblau der Weg, den ein empfangender Server für diese Domain nimmt, bis zu dem, was er mit durchfallenden Mails tut.

Keine Punktzahl: Eine Richtlinie bei none ist eine Phase, kein Versagen, und die Stufenfolge unter dem Weg sagt, was der nächste Schritt braucht.

DMARC-Check von paypal.com: weist Mails ab, die DMARC nicht bestehen, mit Empfängersicht und Stufenplan zur DurchsetzungDMARC-Check von paypal.com: weist Mails ab, die DMARC nicht bestehen, mit Empfängersicht und Stufenplan zur DurchsetzungDas UrteilEin Satz dazu, was Empfänger mit durchfallenden Mails tun, mit Richtlinie, SPF und DKIM auf einen Blick.Der EintragJeder Tag farbig über seinen Zeichen: Überfahren oder antippen zeigt, was er bewirkt. Darunter die Standardwerte.Die Sicht des EmpfängersJede DNS-Abfrage, die ein empfangender Server für die Domain stellt, der Reihe nach, mit ihrer Antwort.Mails, die DMARC nicht bestehenWas Empfänger für die Domain, ihre bestehenden Subdomains und nicht existierende Namen tun.Der Stufenplan zur DurchsetzungWo die Domain zwischen none und reject steht und was der nächste Schritt braucht.
Ein DMARC-Check von paypal.com: das Urteil, der Eintrag in seine Tags zerlegt, die Sicht des Empfängers mit jeder DNS-Abfrage und dem Schicksal durchfallender Mails sowie der Stufenplan zur Durchsetzung. Wählen Sie eine Zahl, um zu sehen, was jeder Teil zeigt.

Wofür wird DMARC verwendet?

DMARC sagt empfangenden Mailservern, was sie mit Mails tun sollen, die Ihre Domain in der From:-Zeile verwenden, aber nicht belegen können, dass sie von Ihnen kommen, und wohin Berichte darüber gehen (RFC 9989 §4.7).

Der Beleg ist SPF oder DKIM, im Alignment mit der From:-Domain: SPF besteht für eine Bounce-Domain derselben Organisation, oder eine DKIM-Signatur trägt d= Ihrer Domain. Ein Treffer mit Alignment genügt (RFC 9989 §5.3.5); alles andere fällt bei DMARC durch, und die Richtlinie des Eintrags entscheidet: zustellen, Spam-Ordner oder abweisen.

Berichte sind die andere Hälfte. Empfänger, die rua beachten, senden eine tägliche Zusammenfassung jedes Servers, der als Ihre Domain gesendet hat, und so finden Sie die legitimen Absender, die Sie vergessen haben, bevor Sie die Richtlinie durchsetzen.

Zwei Nachrichten, eine From:-Zeile

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

Ihre Rechnung, über einen E-Mail-Dienst gesendetüber einen Dienst mit eingerichtetem Custom DKIM, daher signiert er mit d=example.com

  1. SPFpass · bounces.esp.example (kein Alignment)
  2. DKIMpass · d=example.com (Alignment)
  3. DMARCpass: Ein Ergebnis mit Alignment genügt
Zugestellt

Eine gefälschte Rechnung von 203.0.113.9ein Server, den example.com nie autorisiert hat

  1. SPFfail · 203.0.113.9 ist nicht aufgeführt
  2. DKIMnone · keine Signatur
  3. DMARCfail → p=reject
Abgewiesen

550 5.7.1 Email rejected per DMARC policy for example.com

Der aggregierte Bericht von morgen an dmarc@example.com: 1 Nachricht von 203.0.113.9, SPF fail, DKIM none, Disposition reject.

Ein Pass verspricht keine Zustellung (die Filter des Empfängers entscheiden weiter), und ein Fail bei p=reject ist eine Bitte, kein Befehl (RFC 9989 §5.4, §7.4). Adressen aus RFC 5737; der Antworttext ist das eigene Beispiel von RFC 9989.

DMARC-Tags im Eintrag erklärt

Ein DMARC-Eintrag ist eine Liste von Tag=Wert-Paaren in einem TXT-Eintrag bei _dmarc. plus der Domain: zuerst v=DMARC1, dann Richtlinien-, Alignment- und Berichts-Tags in beliebiger Reihenfolge (RFC 9989 §4.7).

RFC 9989 (Mai 2026) hat RFC 7489 abgelöst. Er hat np, psd und t hinzugefügt und pct, rf und ri entfernt: Aktuelle Empfänger ignorieren diese, Empfänger, die noch RFC 7489 anwenden, lesen sie, daher bedeutet ein Eintrag mit pct=25 für verschiedene Empfänger Verschiedenes.

Tags, die Sie nicht veröffentlichen, nehmen ihre Standardwerte an, und der Check zeigt auch diese: Ein fehlendes sp heißt, dass Subdomains p erhalten.

Jeder Tag, nach seiner Aufgabe

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1
VersionRichtlinieTest und SuffixAlignmentBerichteEntfernt
TagWas er festlegtStandardStatusGesehen in
vVersionDMARC1erforderlich, zuerstRFC 9989192
pRichtlinie für die Domainnone · quarantine · rejectnone, wenn er fehlt und rua gültig istRFC 9989192
spRichtlinie für bestehende Subdomainsnone · quarantine · rejectpRFC 998939
npRichtlinie für nicht existierende Namennone · quarantine · rejectsp, dann pneu in RFC 99892
tTestmodus: eine Stufe unter der Richtliniey · nnneu in RFC 99890
psdPublic Suffix (y) oder Organisationsdomain (n)y · n · uuneu in RFC 99891
adkimDKIM-Alignmentr · srRFC 998920
aspfSPF-Alignmentr · srRFC 998924
ruaWohin aggregierte Berichte gehenmailto:…keine BerichteRFC 9989186
rufWohin Fehlerberichte gehenmailto:…keine BerichteRFC 9989120
foWann Fehlerberichte gesendet werden0 · 1 · d · s0RFC 998996
pctAnteil der durchfallenden Mails, auf den die Richtlinie wirkt0–100–entfernt70
rfFormat der Fehlerberichteafrf–entfernt9
riBerichtsintervall in Sekunden86400–entfernt14
Gesehen in: bei wie vielen von 192 DMARC-Einträgen, die 196 bekannte Domains veröffentlichen, der Tag vorkommt (gelesen am 24. Oktober 2026; 69 der 70 pct-Tags sagen pct=100). Standardwerte und Status aus RFC 9989 §4.7 und Anhang C.

DMARC-Richtlinie: p=none, quarantine oder reject

p=none bittet Empfänger, durchfallende Mails wie gewohnt zuzustellen und sie nur zu melden; quarantine bittet sie, sie als verdächtig zu behandeln, meist im Spam-Ordner; reject bittet sie, sie während der SMTP-Verbindung abzuweisen.

None ist eine Phase, kein Versagen: RFC 9989 §7.4 empfiehlt dort mindestens einen Monat mit laufenden Berichten und noch einmal so lange bei quarantine, bevor es zu reject geht. Domains, von denen Personen an Mailinglisten schreiben, sollten bei quarantine bleiben.

Auch große Postfachanbieter unterscheiden: gmail.com und outlook.com veröffentlichen für die Domain selbst p=none und für Subdomains sp=quarantine, während google.com, yahoo.com und microsoft.com reject veröffentlichen.

Wo eine gefälschte Nachricht landet

Zugestelltp=none

apache.orggmail.comsamsung.com

23 von 192

Spam-Ordnerp=quarantine

github.comapple.comamazon.com

30 von 192

Abgewiesenp=reject

google.compaypal.commicrosoft.com

139 von 192

none 23quarantine 30reject 139von 192 Einträgen, 196 bekannte Domains, 24. Oktober 2026

Am Ende entscheiden die Empfänger: Sie dürfen Mails zustellen, die bei p=reject durchfallen, und dürfen nicht allein wegen der Richtlinie abweisen (RFC 9989 §5.4, §7.4). Eine Studie eines Anbieters zeigt, wie weit das übrige Web zurückliegt: Unter den Top 1,8 Millionen Domains fand EasyDMARC Anfang 2026 bei 29,2 % p=none und bei 22,9 % quarantine oder reject.

Ist DMARC wirklich nötig?

Ja, wenn Sie in großen Mengen an Gmail, Yahoo oder Outlook.com senden: Alle drei verlangen einen DMARC-Eintrag, und p=none genügt, um die Regel zu erfüllen. Durchsetzung (quarantine oder reject) verhindert, dass andere im Namen Ihrer Domain senden, und BIMI-Logos setzen sie voraus.

Gmail verlangt ihn seit dem 1. Februar 2024 von Absendern von mehr als 5.000 Nachrichten pro Tag an Gmail-Konten; Yahoo seit Februar 2024, ohne ein Volumen zu nennen; Outlook.com seit dem 5. Mai 2025, ab mehr als 5.000 pro Tag. Ohne Eintrag antwortet Gmail mit 4.7.31 (und 4.7.32, wenn From: nicht im Alignment ist), und Outlook.com weist mit 550 5.7.515 ab.

Für eine Domain, die nichts versendet, ist DMARC der günstigste Schutz überhaupt: p=reject, ein Null-MX und v=spf1 -all, wie es example.com veröffentlicht (M3AAWG).

Was jeder Postfachanbieter von Massenversendern verlangt

Gmail01.02.20245.000+ pro Tag an Gmail-Konten4.7.31 · 4.7.32
YahooFeb. 2024keine Schwelle veröffentlichtDMARC muss bestehen
Outlook.com05.05.20255.000+ pro Tag550 5.7.515
Zugestelltp=noneerfüllt die Regel aller drei Anbieter
Spam-Ordnerquarantinestoppt das meiste Spoofing · BIMI-Logos möglich
Abgewiesenrejectstoppt Spoofing an der Tür · BIMI

✓Pflicht: ein Eintrag, p=none oder strengeriSchutz: quarantine oder reject

Von den eigenen Absenderseiten der Anbieter, gelesen am 24. Oktober 2026. Eine Spam-Rate unter 0,3 % und die Abmeldung mit einem Klick sind ebenfalls Regeln, doch DNS kann sie nicht zeigen; die Ansicht Anforderungen des Checks sagt, welche Teile er belegen kann.

DMARC-Fehler beheben: Weiterleitung, Mailinglisten, die eigene Domain eines Anbieters

Finden Sie die durchfallende Quelle in Ihren aggregierten Berichten und beheben Sie sie beim Absender: Lassen Sie sie mit DKIM für Ihre eigene Domain signieren oder verlegen Sie sie auf eine Bounce-Domain innerhalb Ihrer Organisation. Drei Ursachen decken die meisten Fehler ab.

Weiterleitung behält die DKIM-Signatur, bricht aber SPF, daher trägt DKIM den Pass. Mailinglisten, die die Nachricht verändern, brechen beides. Und ein E-Mail-Dienst, der mit seiner eigenen Domain signiert, besteht DKIM für sich selbst, nicht für Sie: Aktivieren Sie sein Custom DKIM (meist CNAMEs wie s1._domainkey) und einen eigenen Return-Path.

Drei Fehler, was der Bericht zeigt, und die Lösung

Weiterleitung

  • SPF192.0.2.80 steht nicht im SPF von example.com
  • DKIMSignatur intakt

Bericht zeigtspf=fail dkim=pass → pass

Alles mit DKIM signieren; DKIM übersteht die Weiterleitung. ARC (RFC 8617) hilft Weiterleitern, sich zu verbürgen.

Mailingliste

  • SPFder Server der Liste sendet
  • DKIMText geändert: Hash schlägt fehl

Bericht zeigtspf=fail dkim=fail → fail

Listen, die From: umschreiben, beheben es; Domains, von denen Personen an Listen schreiben, bleiben bei quarantine (RFC 9989 §7.4).

Die eigene Domain eines Anbieters

  • SPFpass für bounces.esp.example: kein Alignment
  • DKIMpass für esp.example: kein Alignment

Bericht zeigtdkim=pass(esp.example) → fail

Aktivieren Sie das Custom DKIM des Anbieters: s1 und s2 von paypal.com sind CNAMEs auf SendGrid, das als paypal.com signiert.

Adressen aus RFC 5737; esp.example ist ein Platzhalter. Die SendGrid-CNAMEs sind die echten Selektoren von paypal.com (24. Oktober 2026).

DMARC für Subdomains: sp und np

Eine Subdomain ohne eigenen Eintrag erhält die Richtlinie ihrer Organisationsdomain: sp für Subdomains, die existieren, np für Namen, die nicht existieren, beide mit Rückfall auf p (RFC 9989 §4.7).

Eine Subdomain, die einen eigenen Eintrag veröffentlicht, verwendet ihn für sich selbst. Ein Eintrag zwischen einem Namen und seiner Organisationsdomain wird aber nie für diesen Namen verwendet: Der Baum von berkeley.edu zeigt es, wo das sp=none von eecs.berkeley.edu nicht bis www.eecs.berkeley.edu reicht (RFC 9989 §4.10.1).

np ist der schnelle Gewinn: Nicht existierende Namen versenden keine echte Mail, daher blockiert np=reject Fälschungen von dort, selbst wenn p noch bei none steht. Empfänger nach RFC 7489 kennen np nicht und verwenden sp.

Der Baum von berkeley.edu, wie ein Empfänger ihn liest

berkeley.edup=reject; np=reject; psd=n; rua=…eigener Eintrag · psd=n: die OrganisationsdomainAbgewiesen
www.berkeley.edukein Eintragexistiert → sp, fehlt → pAbgewiesen
eecs.berkeley.edup=reject; sp=none; rua=…eigener Eintrag → pAbgewiesen
www.eecs.berkeley.edukein EintragWalk: Der Eintrag von eecs.berkeley.edu wird übersprungen (nicht die Organisationsdomain) → p von berkeley.eduAbgewiesen
nosuch-x7.berkeley.eduNXDOMAINexistiert nicht → npAbgewiesen

Das sp=none von eecs.berkeley.edu wird nie angewendet: Ein Eintrag zwischen einem Namen und seiner Organisationsdomain wird für ihn nicht verwendet (RFC 9989 §4.10.1). Der Check markiert ihn als Eintrag, der nicht verwendet wird.

Gelesen am 24. Oktober 2026 über Google Public DNS. nosuch-x7.berkeley.edu ist ein ausgedachter Name; sein NXDOMAIN ist echt.

DMARC-Berichte (rua) lesen

Ein aggregierter Bericht ist eine tägliche XML-Datei jedes Empfängers, die jeden Server auflistet, der als Ihre Domain Mails gesendet hat, wie viele Nachrichten und ob SPF, DKIM und DMARC bestanden haben (RFC 9990).

Lesen Sie ihn nach Quelle: Ihre eigenen Server und Dienste sollten einen Pass mit Alignment zeigen; ein bekannter Dienst, der durchfällt, braucht sein Custom DKIM; eine unbekannte Adresse, die bei p=reject durchfällt, ist Spoofing, gestoppt. Ein Berichtsdienst (dmarcian, Valimail, EasyDMARC, Postmark und andere) macht aus Tausenden Dateien diese Liste.

Berichte an eine Adresse in einer anderen Domain kommen nur an, wenn diese Domain zustimmt: Sie veröffentlicht yourdomain._report._dmarc.its-host mit v=DMARC1 (RFC 9990 §4). Der Check fragt für Sie ab und nennt den genauen Eintrag, wenn er fehlt.

Ein Bericht, Zeile für Zeile gelesen

<org_name>google.com</org_name>1

<date_range>23. Okt., 00:00 UTC – 24. Okt., 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

  1. 1Wer berichtet hatEine Datei pro Empfänger und Tag (RFC 9990: mindestens alle 24 Stunden).
  2. 2Die Richtlinie, die er fandWas er bei _dmarc.example.com gelesen hat.
  3. 3Weitergeleitete Mail, von DKIM gerettetSPF schlug beim Weiterleiter fehl; die Signatur mit Alignment bestand DMARC.
  4. 4Spoofing, gestopptEin unbekannter Server, nichts im Alignment, abgewiesen.
paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ autorisiert: Berichte fließen

Berichtsdienste, die der Check erkenntdmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 weitere

Das XML ist gekürzt und ausgedacht (Dokumentationsadressen, RFC 5737); der Autorisierungseintrag ist der echte von paypal.com, gelesen am 24. Oktober 2026.

DMARC-Check: häufig gestellte Fragen

Was ist DMARC?

DMARC ist ein DNS-Eintrag, der empfangenden Mailservern sagt, was sie mit Mails tun sollen, die Ihre Domain in der From:-Zeile verwenden, aber beim Alignment von SPF und DKIM durchfallen: zustellen, in Quarantäne stellen oder abweisen. Außerdem nennt er, wohin Empfänger Berichte über diese Mails senden. Er wird als TXT-Eintrag bei _dmarc plus Ihrer Domain veröffentlicht und ist in RFC 9989 definiert, der im Mai 2026 RFC 7489 abgelöst hat.

Was zeigt ein DMARC-Checker für den Eintrag?

Er liest den TXT-Eintrag bei _dmarc plus der Domain, bei fehlendem Eintrag den der übergeordneten Domains, so wie es ein Empfänger tut. Dieses DMARC-Tool zeigt den Eintrag Tag für Tag mit Standardwerten, die Richtlinie für die Domain, ihre Subdomains und nicht existierende Namen, ob Berichtsadressen die Berichte annehmen und den SPF-Eintrag und die DKIM-Schlüssel der Domain, ohne Punktzahl.

Wie kann ich DMARC testen?

Prüfen Sie oben die Domain auf die veröffentlichte Richtlinie: Das ist der DMARC-Test, den DNS beantworten kann. Ob eine echte Nachricht besteht, sehen Sie, wenn Sie eine an ein Postfach senden, das Sie kontrollieren, und den Authentication-Results-Header lesen oder die Header in die E-Mail-Header-Analyse einfügen. Ein DMARC-Validator prüft die Syntax des Eintrags; nur eine Nachricht zeigt, ob SPF oder DKIM übereinstimmten.

Mit welcher DMARC-Richtlinie sollte ich beginnen?

Beginnen Sie mit p=none und einer rua-Adresse, damit Empfänger Ihnen tägliche Berichte senden, ohne die Zustellung zu ändern. Beheben Sie jeden legitimen Absender, der durchfällt, meist durch sein Custom DKIM, und wechseln Sie dann zu quarantine und schließlich zu reject. RFC 9989 empfiehlt mindestens einen Monat bei p=none und noch einmal so lange bei quarantine. Eine Domain, die keine Mails versendet, kann direkt zu p=reject gehen.

Schützt p=none meine Domain?

Nein. p=none bittet Empfänger, durchfallende Mails wie gewohnt zu behandeln, daher beurteilen nur ihre eigenen Spamfilter eine gefälschte Nachricht. Es liefert Ihnen aber Berichte und erfüllt die Regel von Gmail, Yahoo und Outlook.com für Massenversender. Betrachten Sie es als Überwachungsphase: Schutz beginnt bei quarantine, und reject stoppt gefälschte Mails, bevor sie jemanden erreichen.

Was bedeutet t=y in einem DMARC-Eintrag?

t=y ist der Testmodus von RFC 9989: Empfänger wenden eine Stufe unter der veröffentlichten Richtlinie an, sodass p=reject wie quarantine wirkt und p=quarantine wie none. Bei p=none hat es keine Wirkung und ändert die Berichte nicht. Empfänger, die noch RFC 7489 anwenden, kennen den Tag nicht und wenden die Richtlinie wie geschrieben an. Entfernen Sie t=y, sobald Ihre Berichte zeigen, dass jeder legitime Absender im Alignment ist.

Wird der pct-Tag noch verwendet?

RFC 9989 hat pct entfernt, ebenso rf und ri, weil andere Werte als 0 und 100 uneinheitlich angewendet wurden. Aktuelle Empfänger ignorieren ihn und wenden die Richtlinie auf alle durchfallenden Mails an. Empfänger, die noch RFC 7489 anwenden, ziehen Stichproben: pct=25 bei quarantine schickt ein Viertel der durchfallenden Mails in den Spam und stellt den Rest zu. pct=100 ist harmlos; für eine Testphase verwenden Sie t=y.

Warum ist meine rua-Adresse „nicht autorisiert“?

Gehen Berichte an ein Postfach in einer anderen Organisationsdomain, muss diese Domain zustimmen, indem sie einen TXT-Eintrag namens yourdomain._report._dmarc.its-host mit dem Wert v=DMARC1 veröffentlicht (RFC 9990 §4). Ohne ihn überspringen Empfänger, die das prüfen, die Adresse. Der Eintrag gehört ins DNS des Ziels, nicht in Ihres: Berichtsdienste veröffentlichen einen Wildcard für jeden Kunden, daher ist es meist ein Tippfehler oder das Postfach eines Partners.

Brauchen Subdomains einen eigenen DMARC-Eintrag?

Meist nicht. Eine Subdomain ohne Eintrag erhält die Richtlinie ihrer Organisationsdomain: sp für Subdomains, die existieren, np für Namen, die nicht existieren, beide mit Rückfall auf p. Veröffentlichen Sie nur dann einen bei einer Subdomain, wenn sie eine andere Richtlinie braucht. Ein Eintrag bei einem Zwischennamen, etwa team.example.com für www.team.example.com, wird für den tieferen Namen nicht verwendet.

Was passiert, wenn eine Domain zwei DMARC-Einträge veröffentlicht?

Empfänger verwerfen beide, daher gilt keine DMARC-Richtlinie und es werden keine Berichte gesendet, selbst wenn einer der beiden reject sagt (RFC 9989 §4.10). Meist passiert das, wenn ein neuer Eintrag hinzukommt, ohne den alten zu löschen, oder wenn ein DNS-Anbieter einen Standardeintrag ergänzt. Behalten Sie einen Eintrag bei _dmarc und löschen Sie den anderen; der Check zeigt, welcher beabsichtigt aussieht.

Warum fällt DMARC durch, obwohl SPF besteht?

DMARC braucht einen SPF-Pass für eine Domain, die mit der From:-Adresse übereinstimmt. Die meisten E-Mail-Dienste senden mit ihrer eigenen Bounce-Domain, daher besteht SPF für sie, nicht für Sie, und zählt nicht. Dasselbe gilt für DKIM, das mit der Domain des Dienstes signiert ist. Richten Sie das Custom DKIM oder den eigenen Return-Path des Dienstes ein, damit die Domain, die den Check besteht, Ihre eigene ist.

Der Check zeigt keinen Eintrag, aber ich habe gerade einen hinzugefügt. Warum?

Prüfen Sie zuerst das Host-Feld: Die meisten DNS-Oberflächen wollen nur _dmarc, und wer dort _dmarc.example.com eingibt, erzeugt _dmarc.example.com.example.com. Warten Sie dann, bis die alte Antwort abläuft: Wurde der Name schon einmal abgefragt, behalten Resolver sein NXDOMAIN für die negative TTL der Zone, oft 5 Minuten bis eine Stunde. Ein SERVFAIL oder Timeout erscheint als „nicht prüfbar“, nie als kein Eintrag.