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.
Design
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.
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.comJede Antwort beim Namen. Eine, die mit v=DMARC1 beginnt, ist der Eintrag.
Was dig zeigt und was nicht
$ 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
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.

Das 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.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
Ihre Rechnung, über einen E-Mail-Dienst gesendetüber einen Dienst mit eingerichtetem Custom DKIM, daher signiert er mit d=example.com
Eine gefälschte Rechnung von 203.0.113.9ein Server, den example.com nie autorisiert hat
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.
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
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
4.7.31 · 4.7.32DMARC muss bestehen550 5.7.515✓Pflicht: ein Eintrag, p=none oder strengeriSchutz: quarantine oder reject
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
Bericht zeigtspf=fail dkim=pass → pass
Alles mit DKIM signieren; DKIM übersteht die Weiterleitung. ARC (RFC 8617) hilft Weiterleitern, sich zu verbürgen.
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).
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.
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
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.
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
paypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ autorisiert: Berichte fließenBerichtsdienste, die der Check erkenntdmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 weitere
SPF-Einträge validieren und DNS-Lookup-Anzahl gemäß RFC 7208 prüfen
DKIM-Einträge mit automatischer Selektor-Erkennung verifizieren
BIMI-Einträge, SVG-Tiny-PS-Logos und VMC-Zertifikate prüfen; welche Postfächer es zeigen
Erstellen Sie Ihren DMARC-Eintrag nach RFC 9989, ausgehend von dem, den Sie jetzt veröffentlichen, und sehen Sie, was Empfänger mit Mails tun, die durchfallen.
Rohe E-Mail-Header analysieren und den E-Mail-Weg verfolgen
Mail-Exchange-Einträge und Mailserver-Details finden