DMARC-Syntax-Prüfer

Die Struktur eines DMARC-Eintrags verstehen

Domain-based Message Authentication, Reporting and Conformance (DMARC) verbindet SPF- und DKIM-Ergebnisse zu einer Richtlinie, die als TXT-Eintrag unter _dmarc.<domain> veröffentlicht wird. Diese Seite erläutert, welche Tags der Validator auswertet und wie die von der API gelieferten Diagnosen zu interpretieren sind.

Beispiel für einen DMARC-Eintrag

Ein DMARC-Eintrag besteht aus Tag-Wert-Paaren, getrennt durch Semikolons. Jedes Tag enthält einen kurzen Namen, ein Gleichheitszeichen und einen Wert. Überflüssige Leerzeichen sind erlaubt, aber Tagnamen müssen ASCII sein und dürfen nicht doppelt vorkommen.

v=DMARC1; p=reject; rua=mailto:berichte@example.com; ruf=mailto:forensik@example.com; adkim=s; aspf=s; pct=100

Pflicht-Tags

v — die Version. DMARC1 ist derzeit die einzige gültige Angabe.
p — die Richtlinie für nicht ausgerichtete Nachrichten (none, quarantine oder reject).

Fehlen diese Tags, gilt der Eintrag als ungültig und empfangende Server ignorieren die Richtlinie.

Wichtige optionale Tags

rua — Zieladressen für aggregierte Berichte (mailto:-URIs). Unverzichtbar, um die Wirkung der Richtlinie zu beobachten.
ruf — Empfänger forensischer Berichte. Nur für überwachte, geschützte Postfächer verwenden.
sp — Richtlinie für Subdomains, falls sie von p abweicht.
adkim / aspf — Ausrichtungsmodus für DKIM und SPF (r relaxed, s strict).
pct — Prozentsatz der Nachrichten, die der Richtlinie unterliegen (standardmäßig 100).
fo — Optionen für Fehlermeldungen (z.B. 1, d, s).
ri — gewünschtes Intervall zwischen aggregierten Berichten in Sekunden (standardmäßig 86400).
rf — erwartete Berichtsformate (afrf, iodef).

Der Validator zeigt alle erkannten Tags an, um das spätere DNS-Ergebnis transparent zu machen.

Häufige Fehler, die das Tool erkennt

Unbekannte oder doppelte Tags. Jeder Name darf nur einmal vorkommen.
Ungültige Bericht-URIs. rua und ruf müssen gültige mailto:- oder https:-URIs enthalten.
Fehlende oder leere Richtlinie. Ohne p greift die Richtlinie nie.
Prozentsatz außerhalb des gültigen Bereichs. pct muss zwischen 1 und 100 liegen.
Nicht unterstützte Ausrichtung oder Optionen. Andere Werte als r/s für adkim bzw. aspf oder ungültige fo-Optionen erzeugen Fehler.

Best Practices vor dem Rollout

Starten Sie mit p=none und einem gültigen rua, um den Verkehr ohne Zustellrisiko zu beobachten.
Bewerten Sie die Berichte und wechseln Sie schrittweise zu p=quarantine und p=reject, sobald SPF und DKIM zuverlässig ausgerichtet sind.
Nutzen Sie sp nur, wenn Subdomains eine abweichende Richtlinie benötigen.
Dokumentieren Sie rua- und ruf-Postfächer, Verantwortliche und Aufbewahrungsfristen, damit Berichte verarbeitet werden.
Testen Sie den finalen Eintrag mit diesem Validator und prüfen Sie anschließend _dmarc.<domain>, um Veröffentlichung und Propagation zu bestätigen.

Eine konsequente Prüfung verhindert Syntaxfehler, erleichtert den DMARC-Rollout und liefert belastbare Diagnosen für Deliverability-Teams.