DMARC: der vollständige Leitfaden zum DMARC-Eintrag

Die Syntax des _dmarc-Eintrags

Ein DMARC-Eintrag ist ein einzelner TXT-Eintrag, veröffentlicht auf der Subdomain _dmarc der zu schützenden Domain. Eine Domain darf nur einen tragen — zwei Einträge machen die Policy mehrdeutig, und Empfänger ignorieren dann unter Umständen beide.

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:berichte@beispiel.de; adkim=s; aspf=r"

Der Wert ist eine Folge von Tag=Wert-Paaren, getrennt durch Semikolons. v=DMARC1 muss den Eintrag eröffnen — auch unter DMARCbis, das diese Versionskennung aus Gründen der Rückwärtskompatibilität beibehält. Hier die Tags, wie RFC 9989 sie definiert:

Tag	Zweck	Werte	Anmerkungen
v	Protokollversion	DMARC1	Pflicht, an erster Stelle — unter DMARCbis unverändert
p	Policy der Domain	none, quarantine, reject	Pflicht; gilt für die Domain und standardmäßig für ihre Subdomains
sp	Policy der Subdomains	none, quarantine, reject	Optional; überschreibt p für existierende Subdomains
np	Policy für nicht existierende Subdomains	none, quarantine, reject	Neu in DMARCbis; zielt auf Subdomains, die nicht auflösen
rua	Ziel der aggregierten Berichte	mailto: (eine oder mehrere Adressen)	Dringend empfohlen: ohne sie kein Feedback
ruf	Ziel der Fehlerberichte	mailto:	Optional; selten versendet und oft geschwärzt
adkim	DKIM-Alignment-Modus	r (relaxed), s (strict)	Standard: r
aspf	SPF-Alignment-Modus	r (relaxed), s (strict)	Standard: r
t	Testmodus	y, n	Neu in DMARCbis; ersetzt das gestrichene Tag pct
psd	Public-Suffix-Domain-Marker	y, n, u	Neu in DMARCbis; betrifft vor allem Registries

Zwei Änderungen von DMARCbis verdienen hier besondere Betonung. Erstens wurde das Tag pct — das die Policy angeblich auf einen Prozentsatz des Mailverkehrs anwendete — gestrichen: Empfänger interpretierten es uneinheitlich, und es vermittelte eine falsche Vorstellung von schrittweiser Einführung. An seine Stelle tritt das Testmodus-Tag t, binär und eindeutig: t=y signalisiert, dass die Policy erprobt wird. Zweitens stützt sich die Bestimmung der Organisationsdomain — die Grundlage des relaxed-Alignments — nicht mehr auf die Public Suffix List, eine extern gepflegte Datei, sondern auf den DNS Tree Walk: Der Empfänger steigt den DNS-Baum selbst hinauf, gedeckelt bei acht Abfragen. Das Ergebnis ist deterministisch und selbstgenügsam.

Wer nicht bei einer leeren Seite anfangen will, findet im Blog fertige Eintragsbeispiele zum Anpassen, Anbieter für Anbieter.

Die drei Policies: none, quarantine, reject

Das Tag p sagt den Empfängern, was mit einer Nachricht geschehen soll, die DMARC nicht besteht. Die drei Werte bilden eine Leiter, und die gewählte Sprosse ändert alles:

• p=none — reine Beobachtung. Durchgefallene Nachrichten werden normal zugestellt; nur Berichte werden erzeugt. Das ist der obligatorische Startpunkt: Er erlaubt die Inventur der Versandquellen ohne jedes Risiko für legitime Mail. Aber er schützt nichts und niemanden — eine Domain auf p=none bleibt vollständig fälschbar.
• p=quarantine — durchgefallene Nachrichten werden mit Misstrauen behandelt, in der Praxis in den Spam-Ordner geleitet. Der Schutz wird real: Eine gefälschte E-Mail erreicht den Posteingang nicht mehr, bleibt aber auffindbar, was den Schaden eines Fehlalarms begrenzt.
• p=reject — durchgefallene Nachrichten werden während der SMTP-Sitzung abgewiesen. Sie werden weder zugestellt noch gespeichert: Das Fälschen der exakten Domain wird bei jedem Empfänger unmöglich, der die Policy respektiert. Das ist das Endziel — und die einzige Stufe, die Phishing im Namen der Domain wirklich stoppt.

Wann ist welche Policy richtig? p=none während der Inventurphase, solange die Berichte noch legitime, aber nicht alignte Quellen zeigen. p=quarantine, sobald die Berichte sauber sind, als Validierungsstufe unter Realbedingungen. p=reject als Dauerzustand, sobald die Quarantäne keine Vorfälle mehr zutage gefördert hat. Der ausführliche Vergleich der beiden Durchsetzungsstufen — einschließlich der Fälle, in denen eine verlängerte Quarantäne gerechtfertigt ist — steht in p=quarantine oder p=reject: was wählen. Das Prinzip zum Merken: none ist ein Übergangszustand, kein Ziel. Eine Domain, die dort jahrelang parkt, dokumentiert ihre Angreifbarkeit, ohne sie zu verringern.

Die DMARC-Berichte: rua und ruf

Der „Reporting"-Teil von DMARC ist das, was die Einführung steuerbar macht. Ohne ihn hieße eine Policy zu verschärfen, im Blindflug zu navigieren; mit ihm stützt sich jede Entscheidung auf beobachtete Daten.

Aggregierte Berichte (rua, spezifiziert in RFC 9990) sind XML-Dokumente, die — typischerweise täglich — von Empfängern gesendet werden, die Mail verarbeitet haben, die sich auf Ihre Domain beruft. Google, Microsoft und Yahoo produzieren sie in großem Umfang. Jeder Bericht fasst pro sendender IP-Adresse zusammen: das Nachrichtenvolumen, das SPF-Ergebnis, das DKIM-Ergebnis, den Alignment-Status und die angewandte Policy. Sie enthalten keine Nachrichteninhalte und keine Empfängeradressen — nur Statistik. Sie sind das Rohmaterial jeder Einführung: Sie decken die vergessenen Versanddienste auf (Marketingplattform, CRM, Rechnungstool), die vor der Verschärfung aligned werden müssen. Struktur und Interpretation werden in DMARC-Aggregatberichte lesen im Detail erklärt.

Fehlerberichte (ruf, RFC 9991) sind anders: Sie werden einzeln, im Moment eines Fehlschlags, versendet und enthalten Auszüge der betroffenen Nachricht. Sie versprechen eine feine Diagnose, halten das Versprechen aber selten: Die meisten großen Empfänger versenden sie gar nicht oder schwärzen sie stark — aus Datenschutzgründen, denn eine echte Nachricht kann personenbezogene Daten enthalten. In der Praxis steuert man eine Einführung über die Aggregatberichte; Fehlerberichte sind eine gelegentliche Ergänzung, die man in Kenntnis der Lage anfordert. Unterschiede, Einsatzfälle und Vorsichtsmaßnahmen der beiden Kanäle vergleicht rua vs ruf: welche Berichte anfordern.

Eine rua-Adresse gehört in jeden Eintrag, vom ersten Tag an und unabhängig von der Policy. Gehen die Berichte an eine fremde Domain (etwa einen Analysedienst), muss diese Domain einen externen Autorisierungseintrag veröffentlichen, der bestätigt, dass sie sie annehmen will.

Der Weg der Einführung: von p=none zu p=reject

Die DMARC-Einführung ist ein iterativer Prozess, in dem jeder Schritt durch die Berichte validiert wird. Die bewährte Abfolge:

1. p=none mit einer rua-Adresse veröffentlichen. Keine Auswirkung auf die Mail; die Sammlung beginnt. Zwei bis vier Wochen einplanen, um ein repräsentatives Bild zu erhalten — einschließlich Abrechnungszyklen und Monatsversänden.
2. Die Quellen inventarisieren. Die Berichte zeigen jede IP, die im Namen der Domain sendet. Sie werden klassifiziert: legitime Dienste zum Alignen, unbekannte Dienste zum Untersuchen, eindeutige Fälschung.
3. Jede legitime Quelle alignen. Versender in den SPF-Eintrag aufnehmen, DKIM mit einer alignten Signaturdomain bei jedem Versanddienstleister aktivieren. Das ist der längste Schritt — er hängt von der Mitwirkung der Teams und Anbieter ab.
4. Auf p=quarantine wechseln. Sobald die Berichte zeigen, dass alle legitime Mail aligned ist. Der Testmodus t=y von DMARCbis erlaubt, die Verschärfung als Experiment zu deklarieren, während man prüft, dass keine vergessene Quelle durchfallen würde.
5. Auf p=reject wechseln. Nach einigen Wochen Quarantäne ohne Vorfall. Die Überwachung der Berichte läuft danach als Routine weiter: Eine neue Quelle taucht immer dann auf, wenn ein Team ein neues Tool einführt.

Die objektiven Kriterien, die anzeigen, dass eine Domain bereit ist, eine Sprosse höher zu steigen — Alignment-Quote, Stabilität, Subdomain-Abdeckung —, versammelt die Checkliste von p=none zu p=reject; den vollständigen Weg samt Fallstricken erzählt p=reject erreichen, ohne die eigene Mail zu brechen. Und vor allem anderen: Prüfen Sie den tatsächlichen Zustand Ihres aktuellen Eintrags mit unserem kostenlosen DMARC-Check — veröffentlichte Policy, Alignment, Syntaxfehler. Der Startpunkt wird gemessen, nicht geraten.

DMARCbis in Kürze

DMARCbis ist die vollständige Revision des Standards, von der IETF als drei RFCs veröffentlicht: 9989 (das Protokoll), 9990 (aggregierte Berichte) und 9991 (Fehlerberichte). Zusammen ersetzen sie RFC 7489 von 2015 und heben DMARC erstmals auf den Status eines Proposed Standard — den Standards Track, wo der ursprüngliche Text nur informativ war.

Das Wesentliche in vier Punkten:

• Volle Rückwärtskompatibilität. Einträge beginnen weiterhin mit v=DMARC1; ein bestehender Eintrag bleibt ohne Änderung gültig.
• pct gestrichen, t eingeführt. Die prozentuale Einführung verschwindet zugunsten eines binären Testmodus — ehrlicher und einheitlich interpretiert.
• np und psd eingeführt. Das erste verriegelt nicht existierende Subdomains, ein Lieblingsziel von Fälschern; das zweite kennzeichnet Public-Suffix-Domains.
• Der DNS Tree Walk ersetzt die Public Suffix List. Die Bestimmung der Organisationsdomain wird DNS-nativ, deterministisch und bei jedem Empfänger identisch.

Die vollständige Analyse des neuen Standards — Entstehung, Debatten der Arbeitsgruppe, Folgen für das Ökosystem — steht in DMARCbis erklärt. Und wer sich fragt, was an einem bestehenden Eintrag konkret zu ändern ist: Die kurze Antwort lautet „sehr wenig". Die Anleitung passt in muss man zu DMARCbis migrieren? — ein wirkungslos gewordenes pct entfernen, np=reject erwägen, und das war es im Wesentlichen.

Sonderfälle: Subdomains und geparkte Domains

Subdomains erben standardmäßig die p-Policy der Organisationsdomain — es sei denn, ein sp-Tag entscheidet anders oder die Subdomain veröffentlicht einen eigenen _dmarc-Eintrag. Diese Flexibilität ist nützlich (eine transaktionale Versand-Subdomain kann vor der Root-Domain verschärfen), aber sie ist auch ein klassischer blinder Fleck: Ein p=reject auf der Root kombiniert mit sp=none lässt jede Subdomain fälschbar. DMARCbis ergänzt das Tag np für einen noch heimtückischeren Fall: nicht existierende Subdomains. Nichts hindert einen Angreifer daran, als gehalt.beispiel.de zu senden, selbst wenn dieser Name in Ihrer Zone nie existiert hat — und da kein legitimer Dienst davon abhängen kann, lässt sich np=reject ohne jedes Risiko veröffentlichen, oft lange bevor die Root bereit ist. Das vollständige Zusammenspiel der drei Ebenen — p, sp, np — und ihre Vererbungsfallen behandelt die DMARC-Subdomain-Policy.

Geparkte Domains — im Besitz, aber ohne jeden Mailversand — sind der andere blinde Fleck. Gerade weil niemand sie beobachtet, sind sie ideale Fälschungsziele: Der Empfänger hat keinen Grund, einer Domain zu misstrauen, die Ihnen tatsächlich gehört. Der Schutz ist einfach und sofort wirksam, da keine legitime Mail zu bewahren ist: p=reject von Anfang an, ein SPF-Eintrag v=spf1 -all, der keinen Versender autorisiert, kein DKIM und ein Null-MX als Signal, dass keine Mail erwartet wird. Die vollständige Prozedur, Eintrag für Eintrag, beschreibt eine geparkte Domain schützen. Ein gut gepflegtes Domain-Inventar wendet diese Verriegelung auf jede schlafende Domain des Portfolios an — das beste Verhältnis von Aufwand zu Schutz im gesamten Programm.

FAQ

Ersetzt DMARC SPF und DKIM?

Nein. DMARC funktioniert nicht ohne sie: Es baut auf ihren Ergebnissen auf und ergänzt das Alignment mit der From:-Domain, dann die Policy und die Berichte. Eine Nachricht besteht DMARC, wenn SPF oder DKIM mit einer alignten Domain erfolgreich ist. Die drei Standards werden deshalb gemeinsam eingeführt: erst SPF und DKIM, dann DMARC, um sie an die sichtbare Adresse zu binden und das Ganze durchsetzbar zu machen.

Darf eine Domain mehrere DMARC-Einträge veröffentlichen?

Nein. Eine Domain darf nur einen einzigen TXT-Eintrag auf _dmarc tragen. Existieren mehrere Einträge, die mit v=DMARC1 beginnen, ist das Verhalten der Empfänger undefiniert — die meisten ignorieren alle, womit die Domain ohne Policy dasteht, während sie sich geschützt glaubt. Jede Änderung muss in einen einzigen Eintrag zusammengeführt werden.

Gibt es das Tag pct noch?

Nein. DMARCbis (RFC 9989) hat pct gestrichen, dessen Semantik „Policy auf einen Prozentsatz der Mail anwenden" von Empfänger zu Empfänger unterschiedlich interpretiert wurde. Ersetzt wird es durch das Tag t, einen binären Testmodus: t=y signalisiert, dass die Policy erprobt wird. Ein übrig gebliebenes pct in einem bestehenden Eintrag wird von aktuellen Implementierungen schlicht ignoriert — es zu entfernen hält den Eintrag sauber.

Wie lange dauert der Weg von p=none zu p=reject?

Das hängt davon ab, wie viele Dienste im Namen der Domain senden. Eine einfache Domain mit einer Mailplattform und ein, zwei Versandtools lässt sich in wenigen Wochen verriegeln. Eine Organisation mit Dutzenden Quellen — Marketing, CRM, Rechnungswesen, Support — rechnet eher in Monaten, der Zeit, jeden Anbieter zu alignen. Realistische Zeitmarken, Phase für Phase, liefert wie lange es bis p=reject dauert.

Schützt p=none eine Domain vor Spoofing?

Nein. Bei p=none werden Nachrichten, die DMARC nicht bestehen, normal zugestellt: Die Policy verlangt von den Empfängern keinerlei Aktion. p=none dient der Beobachtung — eine unverzichtbare Etappe, aber eine Domain, die dort unbegrenzt verharrt, bleibt genauso fälschbar wie eine Domain ganz ohne DMARC. Der Schutz beginnt bei p=quarantine und wird bei p=reject vollständig.

Was passiert, wenn eine Domain gar keinen DMARC-Eintrag hat?

Die Empfänger finden keine Policy und behandeln die Mail allein nach ihren eigenen Heuristiken: Eine E-Mail, die die Domain fälscht, kann durchaus im Posteingang landen. Die Domain erhält außerdem keine Berichte, also keinerlei Sichtbarkeit über den Missbrauch ihres Namens. Hinzu kommt ein Zustellbarkeitseffekt: Die großen Mailbox-Anbieter verlangen von Massenversendern inzwischen einen DMARC-Eintrag — sein Fehlen bestraft auch die legitime Mail.