Ein DMARC-Eintrag ist veröffentlicht, aber Empfänger verwerfen ihn

Worum es geht

Unter _dmarc.example.cz steht ein TXT-Eintrag, aber sein Version-Tag lautet nicht exakt v=DMARC1. Empfangende Server überspringen einen solchen Eintrag und behandeln die Domain, als hätte sie überhaupt kein DMARC.

Deshalb sagt der Scan nicht, der Eintrag fehle — Sie sehen ihn ja im DNS. Er sagt, dass Empfänger ihn nicht verwenden. Die Wirkung ist dieselbe wie bei einem fehlenden Eintrag: niemand setzt etwas durch, und es kommen keine Reports an.

Um welche Formen es geht

Es geht immer um den Anfang des Eintrags, nie um die Richtlinie p= dahinter. Es gibt zwei Gruppen.

Formen, die der Standard zu ignorieren vorschreibt

RFC 9989 verlangt in Abschnitt 4.7, dass das Tag v= zuerst steht und exakt den Wert DMARC1 hat; andernfalls muss der Empfänger den gesamten Eintrag ignorieren.

• v=dmarc1; p=reject — der Wert kleingeschrieben.
• v=DMARC10; p=reject — nach DMARC1 steht noch etwas.
• p=reject; v=DMARC1 — das Version-Tag erst nach der Richtlinie.
•  v=DMARC1; p=none — der Eintrag beginnt mit einem Leerzeichen. Entsteht typischerweise beim Kopieren des Werts aus einer Anleitung in das DNS-Panel.
• v=DMARC1 p=reject — nach der Version fehlt das Semikolon, der Versionswert ist also das ganze DMARC1 p=reject.
• v=DMARC2; p=reject — eine Version, die es nicht gibt; die einzige ist DMARC1.

Formen, die der Standard zulässt und Server trotzdem verwerfen

Hier muss man genau sein: nach der Grammatik in Abschnitt 4.8 sind diese beiden Schreibweisen in Ordnung. Dennoch verwerfen sie drei der vier verbreiteten Implementierungen, deren Quellcode wir im September 2026 gelesen haben (OpenDMARC, rspamd, go-msgauth, Mail::DMARC) — ihr Filter über der DNS-Antwort ist strenger als ihr eigener Tag-Parser.

• V=DMARC1; p=reject — großes V im Tag-Namen.
• v = DMARC1; p=reject — Leerzeichen um das =.

Wir behaupten also nicht, der Standard verbiete sie. Wir behaupten, dass der Schutz damit in der Praxis nicht gilt — und die Korrektur ein Zeichen kostet.

Warum das schlechter ist als gar kein Eintrag

• Falsche Sicherheit. Im DNS steht p=reject, die Domain wirkt also geschützt. Gespoofte Mail geht trotzdem durch.
• Keine Reports. Die Adresse in rua= gehört zu dem Eintrag, den der Empfänger verworfen hat — vom Spoofing erfahren Sie also nichts.
• Die Falle bei der Korrektur. Eine Anleitung „legen Sie einen DMARC-Eintrag an“ verleitet dazu, einen zweiten TXT-Eintrag neben den bestehenden zu setzen. RFC 9989 Abschnitt 4.10 sagt aber: Stehen unter dem Namen _dmarc zwei Einträge, gilt keiner davon. Danach steht es schlechter als vorher.

Wie man es behebt

Korrigieren Sie den bestehenden Eintrag, legen Sie keinen neuen an.

1. Lassen Sie sich ausgeben, was veröffentlicht ist: dig +short TXT _dmarc.example.cz (unter Windows nslookup -type=TXT _dmarc.example.cz).
2. Bearbeiten Sie diesen einen Eintrag im DNS-Panel. Alles nach dem Version-Tag bleibt unangetastet — die Richtlinie, rua= und die übrigen Tags.
3. Speichern und warten, bis die TTL abgelaufen ist (meist Minuten bis Stunden).

falsch:  v=dmarc1; p=quarantine; rua=mailto:dmarc@example.cz
richtig: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.cz

Achten Sie auf die zwei Dinge, die der DNS-Editor dem Wert hinzufügt und nicht Sie: ein führendes Leerzeichen und zusätzliche Anführungszeichen im Wert. Lesen Sie den Eintrag nach dem Speichern deshalb immer mit dig zurück, nicht aus dem Formular.

Überprüfung

Wenn dig genau einen Eintrag zurückgibt, der mit v=DMARC1; beginnt, ist es erledigt. Bestätigen können Sie das mit einem neuen Scan auf vulscan.app — die DMARC-Prüfung gehört zum kostenlosen Scan.

Erst danach lohnt sich die Frage nach der Stärke der Richtlinie: was p=none, p=quarantine und p=reject bedeuten und in welcher Reihenfolge man sie ausrollt, behandelt der Artikel Domain hat keinen DMARC-Eintrag.

Referenzen

• Vulscan docs: DMARC von Grund auf
• Vulscan docs: SPF
• RFC 9989 — DMARC — Abschnitt 4.7 (Version-Tag), 4.8 (Grammatik des Eintrags), 4.10 (zwei Einträge = keiner gilt)