DMARC Analyzer
DMARC-Record auslesen, Policy, Ausrichtung und Reporting-Adressen bewerten.
DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf und legt fest, was ein Empfänger mit E-Mails tun soll, die keine der beiden Prüfungen im Namen der sichtbaren Absenderdomain bestehen. Der Record ist ein TXT-Eintrag unter _dmarc.<domain>. DMARC schließt die Lücke, die SPF und DKIM offen lassen: Erst DMARC bezieht die im Mailprogramm angezeigte From-Adresse ein und liefert dem Domaininhaber Berichte darüber, wer in seinem Namen sendet.
Was dieses Werkzeug prüft
Es liest den Record aus, prüft die Syntax jedes Tags nach RFC 9989 §4.7 (v, p, sp, np, rua, ruf, fo, rf, ri, adkim und aspf) und erklärt in Klartext, was jede wirksame Einstellung bewirkt, inklusive der Standardwerte, die auch ohne Angabe gelten (etwa adkim=r, aspf=r, fo=0). Steht noch ein pct im Record, wird es als das ausgewiesen, was es seit RFC 9989 ist: wirkungslos. Hat eine Subdomain keinen eigenen Record, löst das Werkzeug die organisatorische Domain über die Public Suffix List auf und zeigt, dass dort sp greift. Zeigen rua oder ruf auf eine fremde Domain, wird zusätzlich geprüft, ob diese den Empfang per <domain>._report._dmarc.<fremd>-Record autorisiert.
Das Ergebnis lesen
Grün steht für einen syntaktisch sauberen Record mit durchgesetzter Policy (p=quarantine oder p=reject) und mindestens einer gültigen rua-Adresse. p=none ist reines Monitoring ohne Durchsetzung: ein sinnvoller Startpunkt, aber kein Zielzustand, und wird als Hinweis ausgewiesen. Gewarnt wird bei fehlender rua-Adresse (ohne sie erfährt man nie, wer im eigenen Namen sendet), bei ungültigen URI-Formaten und bei einer externen Report-Adresse ohne Autorisierungs-Record. Ein Fehler steht für einen fehlenden v=DMARC1-Anfang, ein doppeltes Tag oder einen zweiten Record.
Grundlagen
Maßgeblich ist RFC 9989, seit 2026 der Nachfolger von RFC 7489. Die Tag-Liste steht in §4.7, die formale Syntax in §4.8, das Ausrichtungskonzept (Alignment) in §4.4, und das Auffinden der zuständigen Policy über den Baumdurchlauf in §4.10. Zwei Änderungen gegenüber RFC 7489 sind für die Praxis wichtig: np (Policy für nicht existierende Subdomains) ist jetzt Teil des Standards, und pct wurde ersatzlos gestrichen.
Typische Fehlerbilder und wie man sie behebt
- Kein DMARC-Record. Mit einem Monitoring-Record beginnen:
v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.example. Einige Wochen Berichte sammeln, alle legitimen Versandwege in SPF und DKIM sauber abbilden, dann aufp=quarantineund schließlichp=rejecthochstufen. - Dauerhaft bei
p=none. Monitoring allein verhindert kein Spoofing. Sobald die Aggregatberichte nur noch bekannte, korrekt authentifizierte Quellen zeigen, die Policy verschärfen. - Externe Berichte kommen nicht an. Liegt die
rua-Domain außerhalb der geprüften Domain, braucht sie einen TXT-Record<ihre-domain>._report._dmarc.<report-domain>mit Inhaltv=DMARC1. Fehlt er, verwerfen viele Absender die Berichte stillschweigend. - Legitime Mail wird nach dem Hochstufen einsortiert oder abgewiesen. Fast immer fehlt für einen Versandweg entweder SPF-Alignment oder eine DKIM-Signatur mit passender
d=-Domain. Den betroffenen Dienst in den Berichten identifizieren und dort DKIM-Signierung für die eigene Domain einrichten. - Strikte Ausrichtung ohne Grund.
adkim=soderaspf=sverlangt exakte Domaingleichheit und bricht oft mit Subdomains von Dienstleistern. Ohne konkreten Bedarf beirelaxed(Standard) bleiben.
Häufige Fragen
- Was bedeutet p=none, p=quarantine, p=reject?
- Die Durchsetzungsstufe: none = nur beobachten und Berichte sammeln, quarantine = nicht authentifizierte Mail in den Spam-Ordner, reject = schon beim SMTP-Dialog abweisen. Empfohlen ist der schrittweise Weg von none über quarantine zu reject, jeweils erst nach Auswertung der Berichte.
- Was bedeutet p=none genau, reicht das als Schutz?
- p=none ändert für den Empfänger nichts an der Zustellung, es aktiviert nur das Reporting. Als Spoofing-Schutz reicht es nicht: erst p=quarantine oder p=reject sorgt dafür, dass gefälschte Mail mit deiner Domain im From tatsächlich aussortiert oder abgewiesen wird.
- Warum sehe ich einen Record, obwohl meine Subdomain keinen hat?
- DMARC fällt für Subdomains ohne eigenen Record auf die organisatorische Domain zurück. Dann greift dort der Tag sp (Subdomain-Policy), ersatzweise p. Eine eigene Subdomain-Policy setzt man gezielt über sp im Record der Hauptdomain.
- Wozu dient der _report._dmarc-Record?
- Zeigt rua oder ruf auf eine fremde Domain, muss diese den Empfang erlauben: über einen TXT-Record <ihre-domain>._report._dmarc.<fremde-domain> mit dem Inhalt v=DMARC1. Fehlt er, werden die Berichte von vielen Versendern nicht zugestellt.
- Was ist DMARC-Ausrichtung (Alignment)?
- DMARC gilt nur als bestanden, wenn eine bestandene SPF- oder DKIM-Prüfung zur sichtbaren From-Domain passt. Bei relaxed (Standard) genügt dieselbe organisatorische Domain, bei strict muss sie exakt übereinstimmen. Genau daran scheitern reine SPF-Setups nach einer Weiterleitung.
- Brauche ich SPF und DKIM beide für DMARC?
- Technisch reicht eine der beiden ausgerichteten Prüfungen. In der Praxis sollten beide stehen: SPF überlebt keine Weiterleitung, DKIM schon; erst zusammen bleibt DMARC über Mailinglisten und Weiterleiter hinweg stabil.
- Mein Record enthält pct, was bedeutet das heute?
- Nichts mehr. RFC 9989 hat den Tag aus DMARC entfernt, und unbekannte Tags müssen Empfänger ignorieren. Früher ließ sich damit die Policy auf einen Teil der Mail begrenzen; heute gilt sie in jedem Fall für alle Nachrichten. Der Tag schadet nicht, gehört aber aus dem Record, weil er einen Zustand vortäuscht, den es nicht mehr gibt.