Die häufigsten Syntaxfehler im DMARC-Eintrag (und ihre Korrekturen)

Von Thomas · virtueller CISO · 24. August 2026

Ein DMARC-Eintrag passt auf eine einzige DNS-Zeile, und diese Zeile versammelt eine bemerkenswerte Dichte an Fehlern. Ein verrutschtes Tag, ein vergessenes mailto:, ein verlorenes Semikolon: Jede dieser Kleinigkeiten genügt, um die Policy einer ganzen Domain außer Kraft zu setzen. Das Terrain lädt dazu ein, denn das DNS validiert nichts. Ein TXT-Eintrag akzeptiert jede beliebige Zeichenkette, und ein fehlerhafter DMARC-Eintrag lässt sich genauso reibungslos veröffentlichen wie ein korrekter — ohne Warnung, ohne Fehlermeldung, ohne das kleinste rote Lämpchen.

Genau das macht den Fehler im DMARC-Eintrag so tückisch: Er ist still. Die Domain glaubt, „DMARC gemacht" zu haben; in Wirklichkeit ignorieren die empfangenden Server den Eintrag, wenden eine schwächere Policy an als die angezeigte oder versenden die erwarteten Berichte nie. Die Symptome zeigen sich erst Wochen später — ein Sammelpostfach, das verzweifelt leer bleibt, eine Fälschung, die ungehindert durchgeht, ein Audit, das entdeckt, dass das angezeigte p=reject in den Augen der Empfänger nie existiert hat.

Dieser Leitfaden stellt die reale Pannensammlung zusammen: die überall beobachteten Syntaxfehler, jeder mit seiner Korrektur. Er benennt auch die falschen Fehler — die Groß-/Kleinschreibung, die modernen Tags —, die veraltete Validatoren zu Unrecht anprangern, und schließt mit der Methode, mit der sich eine Korrektur beweisen lässt. All das setzt voraus zu wissen, wie ein gesunder Eintrag aussieht: Dort beginnt es.

Die Anatomie eines gültigen Eintrags

Ein DMARC-Eintrag ist ein DNS-Eintrag vom Typ TXT, veröffentlicht an einem präzisen Ort: der Subdomain _dmarc der zu schützenden Domain. Für beispiel.de fragen die Empfänger also _dmarc.beispiel.de ab, und nirgendwo sonst. Der Wert ist eine Folge von Tag=Wert-Paaren, getrennt durch Semikolons:

_dmarc.beispiel.de.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de"

Drei Elemente tragen das Wesentliche. v=DMARC1 identifiziert die Version und muss den Eintrag eröffnen, ohne Ausnahme. p= benennt die von den Empfängern erbetene Policy: none, quarantine oder reject, nichts anderes. rua= bezeichnet das Ziel der aggregierten Berichte, in Form einer mailto:-URI. Drumherum verfeinern optionale Tags das Verhalten: sp für Subdomains, adkim und aspf für die Strenge des Alignments, fo für die Optionen der Fehlerberichte, dazu die von DMARCbis eingeführten Tags (np, t, psd), auf die noch zurückzukommen ist. Vollständige, kommentierte Einträge, vom einfachsten bis zum fortgeschrittensten, sind in den Beispielen für DMARC-Einträge versammelt; hier liegt der Fokus auf dem, was kaputtgeht.

Verrutschtes `v`, fehlendes `p`: die Fehler, die die Policy neutralisieren

Die strengste Regel der gesamten Syntax betrifft das Versions-Tag: v=DMARC1 muss das allererste Paar des Eintrags sein. Ein p=reject; v=DMARC1 — Frucht einer unglücklichen Umsortierung bei einer Änderung — ist kein „unordentlicher" Eintrag: Es ist ein Eintrag, den die Empfänger vollständig verwerfen. Die Domain steht ganz ohne Policy da, während im DNS ein Eintrag gut sichtbar liegt. Die Korrektur ist trivial (v=DMARC1 wieder an den Anfang stellen); die Diagnose ist es nicht, gerade weil alles an seinem Platz zu sein scheint.

Das p-Tag hält eine subtilere Falle bereit. Fehlt es oder ist es falsch geschrieben — p=rejekt, p=quarantaene, p=block kommen auf produktiven Domains tatsächlich vor —, macht das den Eintrag nicht immer unsichtbar. Der Standard sieht einen Rückfall vor: Ist die Policy unlesbar, aber eine brauchbare rua-Adresse vorhanden, behandeln die Empfänger den Eintrag wie ein p=none. Die Berichte kommen weiter an, das Dashboard lebt, alles wirkt normal … nur ist die tatsächlich angewandte Policy die freizügigste überhaupt. Eine Domain kann monatelang ein falsch geschriebenes p=reject anzeigen und sich geschützt wähnen. Die Korrektur besteht in einem einzigen richtigen Wort: Zulässig sind allein none, quarantine und reject, auf Englisch, ohne Varianten.

`rua=` ohne `mailto:`: Berichte, die nie losgeschickt werden

Die Sammeladresse der aggregierten Berichte ist keine nackte E-Mail-Adresse, sondern eine URI. rua=dmarc@beispiel.de sieht glasklar aus, doch kein Berichtsgenerator wird es akzeptieren — die korrekte Form lautet rua=mailto:dmarc@beispiel.de. Das vergessene mailto:-Präfix ist wahrscheinlich der am weitesten verbreitete Fehler dieser ganzen Sammlung, und sein Symptom ist unerbittlich: ein ansonsten korrekter Eintrag, eine angewandte Policy und null empfangene Berichte, auf unbestimmte Zeit.

Die Regel gilt für jedes Ziel. Mehrere Adressen werden durch Kommas getrennt, und jede trägt ihr eigenes Präfix: rua=mailto:dmarc@beispiel.de,mailto:archiv@beispiel.de ist korrekt; rua=mailto:dmarc@beispiel.de,archiv@beispiel.de ist es nur zur Hälfte, denn die zweite Adresse wird ignoriert. Dieselbe Anforderung gilt für ruf, die Adresse der Fehlerberichte, wo sie verwendet wird.

Semikolons, Anführungszeichen und unsichtbare Zeichen

Das Semikolon ist der Tag-Trenner, und sein Fehlen verschmilzt zwei Tags zu einem einzigen unlesbaren Wert. v=DMARC1; p=none rua=mailto:dmarc@beispiel.de macht „none rua=mailto:…" zum Wert von p: eine ungültige Policy, im besten Fall mit stillem Rückfall auf p=none. Umgekehrt werden überzählige Semikolons (;;, ; ;) von manchen Parsern toleriert und von anderen abgelehnt — die kanonische Form ist der sichere Weg: ein Semikolon zwischen jedem Paar, ein etwaiges Semikolon am Ende ohne Folgen.

Anführungszeichen sind eine Oberflächen-Falle. In einer Zonendatei steht der TXT-Wert zwischen Anführungszeichen; in der Weboberfläche eines DNS-Hosters sind sie fast immer überflüssig, weil die Oberfläche sie selbst hinzufügt. Wird "v=DMARC1; p=none" mitsamt Anführungszeichen in ein Feld geklebt, das keine erwartet, entsteht ein Eintrag, dessen erstes Zeichen ein wörtliches Anführungszeichen ist: Das v-Tag eröffnet den Wert nicht mehr, der gesamte Eintrag wird verworfen. Das Symptom zeigt sich bei der DNS-Abfrage: verdoppelte oder maskierte Anführungszeichen um den veröffentlichten Wert.

Unsichtbare Zeichen schließlich sind der Feind des Kopierens und Einfügens. Ein in einer Textverarbeitung verfasster oder aus einem PDF übernommener Eintrag schleppt gern ein geschütztes Leerzeichen anstelle eines einfachen mit, typografische Anführungszeichen, einen Gedankenstrich statt des Bindestrichs. Für das Auge unterscheidet nichts diese Zeichen von ihren ASCII-Gegenstücken; für den Parser eines Empfängers existiert das Tag schlicht nicht mehr. Die Gegenmaßnahme ist einfach: den Wert in einem Klartext-Editor neu eintippen, statt ihn aus einem formatierten Dokument zu übernehmen.

Der falsche Ort und der doppelte Eintrag

Ein perfekter Eintrag am falschen Ort ist nichts wert. Auf der nackten Domain veröffentlicht — beispiel.de statt _dmarc.beispiel.de —, wird er nie abgefragt: Die Empfänger befragen ausschließlich die Subdomain _dmarc. Auch der umgekehrte Fehler existiert: Manche DNS-Oberflächen hängen den Zonennamen automatisch an, und die Eingabe von _dmarc.beispiel.de ins Feld „Name" erzeugt _dmarc.beispiel.de.beispiel.de. Je nach Hoster erwartet das Feld _dmarc allein oder den vollständigen Namen; ein Blick auf den tatsächlich veröffentlichten Zustand klärt das in Sekunden.

Der doppelte Eintrag ist heimtückischer. Koexistieren auf _dmarc.beispiel.de zwei TXT-Einträge, die mit v=DMARC1 beginnen — ein alter, nie gelöschter, und ein neuer, von einem anderen Werkzeug oder einem anderen Team gesetzter —, ist der Standard eindeutig: Die Empfänger wählen keinen von beiden. Zwei Policies sind null Policy, und die Domain fällt in den ungeschützten Zustand zurück. Dieselbe Falle existiert auf der SPF-Seite, wo die Verdopplung einen permanenten Fehler erzeugt; der Mechanismus und seine Korrektur sind in dem Fall der mehrfachen SPF-Einträge ausgeführt.

Ein Sonderfall: Ist _dmarc per CNAME an einen anderswo verwalteten Eintrag delegiert — gängige Praxis bei Überwachungsplattformen —, lässt sich daneben kein lokaler TXT setzen oder er gerät in Konflikt, und lokale Änderungen bleiben wirkungslos. Wie diese Delegation funktioniert und wo ihre Grenzen liegen, erklärt der DMARC-Eintrag als CNAME.

Die falschen Fehler: Groß-/Kleinschreibung und die DMARCbis-Tags

Nicht alles, was dem Auge missfällt, ist ein Fehler. Zuerst die Schreibweise: Der Vergleich der Tags und ihrer Werte ignoriert die Groß-/Kleinschreibung. p=REJECT gilt exakt so viel wie p=reject, und P=Quarantine wird ohne Schwierigkeit interpretiert. Das ist ein sehr verbreiteter Diagnosefehler: Angesichts eines Zustellbarkeitsproblems heftet sich die Aufmerksamkeit an „verdächtige" Großbuchstaben, die „Korrektur" ändert rein gar nichts — und der echte Fehler, ein fehlendes mailto: drei Tags weiter, überlebt die Durchsicht. Die Kleinschreibung (mit DMARC1 in Großbuchstaben) bleibt der Lesbarkeit halber empfohlen, ist aber eine Frage der Konvention, nicht der Gültigkeit.

Dann die modernen Tags. Der aktuelle Standard — DMARCbis, veröffentlicht als RFC 9989 bis 9991 — hat np eingeführt (die Policy für nicht existierende Subdomains), t (den Testmodus, der das alte pct ersetzt) und psd (eine Markierung im Zusammenhang mit dem DNS Tree Walk, dem Nachfolger der Public Suffix List). Ein Eintrag mit np=reject oder t=y ist vollkommen gültig; dennoch melden alternde, nie aktualisierte Online-Validatoren ihn als „unbekanntes Tag". Das ist ein Fehlalarm: Die DMARC-Syntax ist per Konstruktion erweiterbar, und ein unbekanntes Tag wird ignoriert, nie fatal. Umgekehrt macht ein aus einem älteren Rollout geerbtes pct=50 nichts ungültig, wird von modernen Empfängern aber nicht mehr interpretiert: Der Testmodus wird heute mit t=y ausgedrückt.

Externes Reporting: wenn `rua` auf eine andere Domain zeigt

Ein letzter Fall, an der Grenze der Syntax: Der Eintrag ist tadellos, die Policy greift, und die Berichte kommen trotzdem nicht an. Gehört die rua-Adresse zu einer anderen Domain als der, die den Eintrag veröffentlicht — beispiel.de, das seine Berichte an dmarc@beispiel.org schickt —, verlangen die Berichtsgeneratoren einen Nachweis der Zustimmung des Empfängers. Die empfangende Domain muss einen Autorisierungseintrag am Ort beispiel.de._report._dmarc.beispiel.org veröffentlichen, mit dem schlichten Wert v=DMARC1. Ohne diese Autorisierung verzichten die meisten Generatoren auf den Versand — still, wie immer.

Seriöse Sammelplattformen veröffentlichen diese Autorisierung von Haus aus, oft in generischer, für alle Kunden gültiger Form; das Problem tritt daher kaum außerhalb handgestrickter Sammlung zwischen Domains derselben Organisation auf. Die vollständige Einrichtung einer Sammeladresse — Autorisierung eingeschlossen — wird Schritt für Schritt in der Konfiguration der rua-Adresse durchgespielt.

Die Methode: korrigieren und die Korrektur beweisen

Jede Korrektur beginnt mit der Lektüre des realen Zustands, nicht des vermuteten. Der Befehl dig TXT _dmarc.beispiel.de +short (oder das Äquivalent nslookup -type=TXT) zeigt, was die Empfänger tatsächlich sehen — was von dem abweichen kann, was die Oberfläche des Hosters anzeigt, wegen eines Caches, einer nicht synchronisierten Sekundärzone oder einer vergessenen Delegation.

Auf dieser Ausgabe folgt die Durchsicht einer kurzen Liste: ein einziger Eintrag, der mit v=DMARC1 beginnt; v an allererster Stelle; ein vorhandenes p mit einem der drei zulässigen Werte; ein mailto: vor jeder rua- und ruf-Adresse; ein Semikolon zwischen jedem Paar; kein wörtliches Anführungszeichen am Anfang des Werts; kein exotisches Zeichen — Zweifel beseitigt das Neueintippen des Werts von Hand in einem schlichten Editor.

Nach der Veröffentlichung der Korrektur ist Geduld gefragt: Die TTL des alten Eintrags kann die fehlerhafte Version stundenlang im Cache halten. Eine neue Abfrage über mehrere Resolver bestätigt die Ausbreitung. Der endgültige Beweis ist nicht syntaktisch, sondern operativ: Aggregierte Berichte, die binnen 24 bis 48 Stunden eintreffen, belegen, dass die gesamte Kette — Ort, Syntax, Policy, Sammlung — von Ende zu Ende funktioniert.

Fazit

Ein gültiger DMARC-Eintrag ist ein einziger TXT auf _dmarc.<domain>, eröffnet von v=DMARC1, mit einem korrekt geschriebenen p und einer rua als mailto:-URI. Die Fehler, die zählen, lassen sich an zwei Händen abzählen: verrutschtes Versions-Tag, fehlende oder fehlerhafte Policy mit stillem Rückfall auf p=none, vergessenes mailto:, verlorenes Semikolon, in den Wert geklebte Anführungszeichen, am falschen Ort gesetzter Eintrag, Doppelung, die alles annulliert, unsichtbares Zeichen aus einem Kopiervorgang. Auf der anderen Seite stehen zwei falsche Fehler, die keine „Korrektur" mehr verdienen: die Groß-/Kleinschreibung, die von den Empfängern ignoriert wird, und die DMARCbis-Tags (np, t, psd), die nur alternde Validatoren für Mängel halten. Dazu ein toter Winkel: die Autorisierung des externen Reportings, ohne die perfekt konfigurierte Berichte nie losgeschickt werden.

Der kürzeste Weg vom Zweifel zur Gewissheit bleibt das Werkzeug: Ein Durchlauf der Domain durch die kostenlose DMARC-Analyse erkennt die Fehler dieser Sammlung in Sekunden — verrutschtes Tag, fehlendes mailto:, doppelter Eintrag —, ohne falsche über Schreibweise oder moderne Tags zu erfinden. Ist der Eintrag bereinigt, erlaubt das Eröffnen eines Kontos, die Rückkehr der Berichte zu verfolgen und die Policy auf endlich gesunden Fundamenten in Richtung p=reject zu heben.