DMARC-Eintrag: Beispiele zum Kopieren (und Verstehen)

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

Vorlage 2 — Quarantine (erste Durchsetzung)

Sind die Quellen ausgerichtet, geht es eine Stufe hoch. Die fehlgeschlagene Post geht in den Spam statt in den Posteingang. Wir fügen hier sp und np hinzu, um die Subdomains abzudecken, und t=y, um die Testphase zu signalisieren.

v=DMARC1; p=quarantine; sp=quarantine; np=reject; t=y; rua=mailto:dmarc@beispiel.de

Bemerkenswert ist np=reject von Anfang an: Die nicht existierenden Subdomains tragen keine legitime Post, also werden sie gleich verriegelt (siehe die Subdomain-Policy). Sobald die Berichte sauber und der Testmodus beruhigend sind, fällt t=y weg.

Vorlage 3 — Reject (das Ziel)

Die maximale Durchsetzung. Die im Namen der Domain gefälschte Post wird abgewiesen, bevor sie ankommt. Das ist das Ziel der meisten Deployments, zu erreichen, sobald die Berichte seit mehreren Wochen nachweislich sauber sind.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@beispiel.de

Symmetrisch und klar: Root, existierende und nicht existierende Subdomains, alle auf reject. Braucht eine legitime Subdomain Spielraum, ist sp nicht für alle zu senken — sie bekommt ihren eigenen dedizierten Eintrag. Die vollständige Sequenz, um bruchfrei hierher zu gelangen, wird in p=reject erreichen, ohne die E-Mails zu zerstören beschrieben; ob die Domain bereit ist, beantwortet die Eignungs-Checkliste.

Vorlage 4 — Geparkte Domain oder ohne E-Mail

Manche Domains versenden nie Post (defensive Marke, alter Name, Reservierung). Ohne DMARC zu bleiben macht aus ihnen ein kostenloses Fälschungsziel. Für sie gilt von Anfang an die strengste Policy, ohne Beobachtungsphase: Per Definition kann keine legitime E-Mail blockiert werden.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@beispiel.de

Das ist derselbe wie die reject-Vorlage, er lässt sich aber sofort setzen, ohne über none oder quarantine zu gehen, da es nichts zu beobachten gibt. Eine geschützte geparkte Domain ist eine Tür weniger für die Betrüger.

Wo den Eintrag veröffentlichen

Der Punkt, der die meisten Anfänger blockiert, ist nicht der Wert, sondern der Ort. Der Eintrag wird beim DNS-Hoster veröffentlicht (dem, der die Zone verwaltet), als TXT-Eintrag, auf dem Namen _dmarc. Je nach Oberfläche ist entweder der vollständige Name _dmarc.beispiel.de einzugeben oder einfach _dmarc (die Oberfläche fügt die Domain automatisch hinzu). Der Wert ist die Zeichenkette v=DMARC1; …, in den meisten Oberflächen ohne selbst hinzugefügte Anführungszeichen.

Achtung vor einem klassischen Fehler: Der Eintrag gehört nicht direkt auf beispiel.de, sondern auf den Subnamen _dmarc. Ein an der Root gesetzter DMARC-Eintrag wird von den Empfängern nie gefunden. Weiterer Punkt: Die DNS-Propagierung ist nicht sofort — nach der Veröffentlichung vergehen einige Minuten bis einige Stunden, bevor der neue Eintrag überall sichtbar ist, je nach TTL der Zone. Fünf Minuten nach dem Setzen zu schließen, er „funktioniere nicht", ist verfrüht; zu prüfen ist vielmehr, dass er nach abgeschlossener Propagierung korrekt gelesen wird.

Einstellungen je Anbieter

Der DMARC-Eintrag selbst ist identisch, egal welcher Mail-Anbieter — es ist eine Eigenschaft der Domain, nicht der Mail-Plattform. Was sich von Anbieter zu Anbieter ändert, ist die Ausrichtung (SPF/DKIM), die DMARC prüft. Ein paar Anhaltspunkte:

• Google Workspace: Die DKIM-Signatur wird in der Admin-Konsole aktiviert (Apps → Google Workspace → Gmail → E-Mail authentifizieren), was einen DKIM-Eintrag zur Veröffentlichung liefert. Sobald DKIM auf der Domain ausgerichtet ist, funktioniert das obige DMARC unverändert.
• Microsoft 365: DKIM wird im Security-Center (oder per PowerShell) aktiviert und signiert mit der eigenen Domain. SPF für Microsoft läuft über den include:spf.protection.outlook.com. Das SPF-Detail steht in SPF für Microsoft 365 und Google Workspace.
• OVH, Scaleway und deutsche/französische Hoster: Die Mechanik ist dieselbe — den TXT _dmarc in der DNS-Zone veröffentlichen und sicherstellen, dass die Versandplattform in DKIM mit d=beispiel.de signiert.
• Drittanbieter-Plattformen (Marketing, Rechnung, Transaktional): Jede liefert ihre eigene DKIM-Prozedur, um auf die Marke der Absenderdomain zu signieren. Hier entscheidet sich die reale Ausrichtung, Quelle für Quelle.

Anders gesagt: Es gibt keinen „speziellen Gmail-DMARC-Eintrag" oder „speziellen Microsoft-Eintrag": Es gibt einen DMARC-Eintrag für die eigene Domain und eine Ausrichtungsarbeit, die bei jedem Absender zu erledigen ist.

Relaxed oder strict Alignment (adkim / aspf)

Zwei optionale Tags verdienen ein Wort, denn sie tauchen oft in den online gefundenen Vorlagen auf: adkim und aspf, die die Strenge der Ausrichtung steuern. Im relaxed-Modus (r, der Standardwert) zählt eine Subdomain als ausgerichtet mit der organisatorischen Domain: Ein DKIM, signiert mit d=mail.beispiel.de, richtet ein From: auf beispiel.de aus. Im strict-Modus (s) müssen beide exakt übereinstimmen.

Der praktische Rat: bei relaxed bleiben, außer aus präzisem Grund. Der strict-Modus zerstört völlig legitime Konfigurationen (Plattformen, die mit einer technischen Subdomain signieren) und bringt nur in sehr speziellen Sicherheitsszenarien einen Gewinn. Wer nicht weiß, warum er auf strict wechseln sollte, braucht es nicht — deshalb erwähnt keine der obigen Vorlagen diese Tags: Ihr Fehlen ist die richtige Einstellung für nahezu alle Domains.

Sollte man ruf (Forensikberichte) hinzufügen?

Viele alte Beispiele enthalten ein Tag ruf= neben rua=. 2026 ist das selten nützlich: Die meisten großen Anbieter (Google, Microsoft, Yahoo) versenden keine Forensikberichte mehr, und diese werfen Datenschutzfragen auf, da sie Header oder gar Auszüge aus echten Nachrichten enthalten können. Außer bei präzisem Diagnosebedarf und beherrschtem DSGVO-Rahmen bleibt ruf am Start beiseite. Der Unterschied zwischen den beiden Berichtstypen wird in RUA vs RUF detailliert, und der Datenschutzwinkel in Forensikberichte und DSGVO. Aus diesem Grund enthält keine der obigen Vorlagen ruf: Einfach zu beginnen vermeidet, sensible Daten zu sammeln, für die es keine Verwendung gibt.

Häufige Syntaxfehler

• rua vergessen. Ein DMARC ohne Berichtsadresse „funktioniert", macht aber blind: Nie wird sichtbar, wer im Namen der Domain versendet, noch ob sich verschärfen lässt.
• Den Hostnamen verwechseln. Der Eintrag gehört auf _dmarc, nicht auf die Root der Domain.
• Mehrere DMARC-Einträge mischen. Es darf nur einen einzigen TXT-Eintrag geben, der mit v=DMARC1 beginnt, auf _dmarc. Zwei Einträge = undefiniertes Verhalten, oft ignoriert.
• Eine rua-Adresse einer anderen Domain kopieren. Berichte an dmarc@andere-domain.de zu senden erfordert eine Autorisierung auf Seite der empfangenden Domain (siehe die rua-Adresse konfigurieren). Zum Beginnen dient eine Adresse der eigenen Domain.
• t=y stehen lassen. Der Testmodus ist eine Phase des Anstiegs, keine dauerhafte Einstellung.

Wie man von einer Vorlage zur nächsten wechselt

Die vier Vorlagen sind keine Alternativen, zwischen denen man sich einmalig entscheidet, sondern in den meisten Fällen aufeinanderfolgende Etappen. Der typische Weg für eine aktive Versanddomain führt von Vorlage 1 über Vorlage 2 zu Vorlage 3. Es lohnt sich, den Übergang zwischen den Vorlagen bewusst zu gestalten, statt einfach den Wert zu überschreiben und zu hoffen.

Der Wechsel von Vorlage 1 zu Vorlage 2 erfolgt erst, wenn die Quellen aus den aggregierten Berichten identifiziert und ausgerichtet sind. Der Sprung von p=none auf p=quarantine ist der erste Moment, in dem eine falsch ausgerichtete legitime Quelle tatsächlich Konsequenzen hat — ihre Post geht in den Spam. Deshalb kommt hier das t=y ins Spiel: Es signalisiert den Empfängern eine laufende Testphase und macht den Einstieg sanfter. Diese Phase sollte kurz genug bleiben, um nicht in ihr steckenzubleiben, aber lang genug, um einen sauberen Trend zu sehen.

Der Wechsel von Vorlage 2 zu Vorlage 3 erfolgt, sobald die Berichte über mehrere Wochen sauber sind — keine legitime Quelle mehr im Fehlschlag. Der Übergang besteht aus zwei Änderungen: t=y entfernen und p sowie sp von quarantine auf reject hochziehen. np steht in beiden Vorlagen bereits auf reject, hier ändert sich also nichts. Genau diese Kontinuität von np über alle Etappen hinweg ist beabsichtigt: Da nichts Legitimes von einer nicht existierenden Subdomain kommt, gibt es keinen Grund, es je auf einem weicheren Wert zu halten.

Vorlage 4 steht außerhalb dieser Sequenz — eine geparkte Domain überspringt Vorlage 1 und 2 komplett und geht direkt auf das strenge Ziel. Der Grund ist einfach: Es gibt keine legitime Post zu beobachten, also keine Beobachtungsphase zu durchlaufen. Diese Unterscheidung — aktive Domain durchläuft die Sequenz, geparkte Domain springt ans Ende — ist eine der nützlichsten Faustregeln beim Aufsetzen von DMARC über ein ganzes Domainportfolio.

Und danach?

Eine kopierte Vorlage ist nur ein Anfang. Die eigentliche Arbeit — jede Quelle so auszurichten, dass die Verschärfung niemanden blockiert — beginnt danach. Sobald der Eintrag veröffentlicht ist, gehört er aus Sicht eines Empfängers geprüft, mit dem kostenlosen DMARC-Analyzer: Er bestätigt, dass die Syntax gültig ist, dass die Policy korrekt gelesen wird und vor allem, dass die Quellen sich wie geplant ausrichten. Das ist der schnellste Weg, eine generische Vorlage in einen wirklich auf die eigene Domain zugeschnittenen Schutz zu verwandeln — und den Tippfehler oder den doppelten Eintrag abzufangen, der sonst monatelang unbemerkt bliebe.