DMARC-Eintrag setzen und Berichte lesen

SPF und DKIM prüfen jeweils eine Domain, aber nicht unbedingt die, die der Empfänger in seinem Postfach als Absender sieht. DMARC schließt diese Lücke. Es verlangt, dass die Domain in der Absenderzeile (From) durch SPF oder DKIM bestätigt wird, und lässt den Inhaber der Domain festlegen, was mit Mails geschehen soll, bei denen das nicht klappt ^[1]. Außerdem bekommst du Berichte darüber, wer alles mit deiner Domain Mails verschickt. Seit Mai 2026 gilt dafür RFC 9989. Er ersetzt die bisherige Beschreibung RFC 7489, die nur den Status einer Information hatte, und steht nun auf dem Standards Track der IETF. Die Berichtsformate stehen in RFC 9990 und RFC 9991 ^{[1, 2, 3]}.

Was DMARC prüft

Eine Mail besteht DMARC, wenn mindestens eine der beiden Prüfungen erfolgreich ist und die geprüfte Domain zur Absenderdomain passt. RFC 9989 nennt das Identifier Alignment, auf Deutsch etwa Übereinstimmung ^[1]. Bei SPF zählt dabei nur die Domain aus dem Umschlag der Mail (MAIL FROM, im Quelltext oft als Return-Path zu sehen), bei DKIM die Domain aus dem Feld d= der Signatur ^[1].

Es gibt zwei Stufen. Bei der lockeren Übereinstimmung reicht es, wenn beide Domains dieselbe Organisationsdomain haben, also dieselbe registrierte Domain. Bei der strengen müssen sie genau gleich sein ^[1]. RFC 9989 stellt fest, dass fast alle Domaininhaber mit der lockeren Stufe auskommen ^[1].

Die dritte Zeile zeigt einen typischen Fall: Ein Newsletter- oder Rechnungsdienst verschickt Mails mit deiner Absenderadresse, signiert aber mit seiner eigenen Domain. SPF und DKIM bestehen dann, DMARC trotzdem nicht. Abhilfe schafft eine DKIM-Signatur mit deiner Domain beim Dienst.

Aufbau des Eintrags

Der DMARC-Eintrag ist ein TXT-Eintrag unter dem Namen _dmarc vor der Domain, für beispiel.de also _dmarc.beispiel.de ^[1]. Ein Eintrag für den Anfang sieht so aus: v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de. Das Feld v=DMARC1 muss am Anfang stehen, sonst ignorieren Empfänger den ganzen Eintrag. Fehlt p=, gilt der Eintrag als p=none. Unbekannte Felder werden übergangen ^[1].

Die drei Werte von p bedeuten: none äußert keinen Wunsch, quarantine stuft fehlschlagende Mails als verdächtig ein, reject erklärt die Nutzung deiner Domain in solchen Mails für ungültig ^[1]. Was der Empfänger daraus macht, entscheidet er selbst. RFC 9989 verlangt, dass er Mails nicht allein wegen p=reject ablehnt. Er soll weiteres Wissen heranziehen, etwa bekannte Versandmuster oder Inhaltsfilter; fehlt das, behandelt er die Mail wie bei p=quarantine ^[1]. Microsoft beschreibt, dass Mails mit quarantine etwa im Junk-Ordner landen können und Mails mit reject in der Regel verworfen werden ^[4].

Was aus pct geworden ist

Ältere Anleitungen, auch die von Microsoft, nennen noch das Feld pct, mit dem sich die Richtlinie auf einen Prozentsatz der Mails beschränken ließ ^[4]. RFC 9989 führt pct, rf und ri nur noch als historisch. Die Begründung: Werte zwischen 0 und 100 wurden in der Praxis kaum genau umgesetzt, nützlich waren eigentlich nur 0 und 100. An die Stelle tritt das Feld t. Mit t=y wendet der Empfänger eine Stufe milder an, aus quarantine wird also none und aus reject wird quarantine ^[1]. Du kannst so die nächste Stufe ankündigen und in den Berichten beobachten, ohne dass gleich Mails verschwinden.

Einführung in drei Stufen

Bevor du DMARC veröffentlichst, sollten SPF und DKIM für alle Dienste laufen, die mit deiner Domain senden, und ein Postfach für die Berichte bereitstehen ^[1]. Dann gehst du schrittweise vor:

1. Beobachten mit p=none und rua. RFC 9989 nennt das Monitoring Mode. Er dient dazu, vergessene Server und Dienste zu finden ^[1].
2. Berichte auswerten und jede legitime Quelle so einrichten, dass sie besteht. Das muss erledigt sein, bevor du eine strengere Richtlinie setzt ^[1].
3. Auf p=quarantine umstellen, später auf p=reject. Für Domains, deren Nutzer an Mailinglisten teilnehmen, empfiehlt RFC 9989 vorher mindestens einen Monat p=none und genauso lange p=quarantine ^[1].

Wie lange das insgesamt dauert, hängt davon ab, wie oft du Mails verschickst. RFC 9989 spricht von unter Umständen vielen Monaten ^[1]. Microsoft rät, mit einer Subdomain mit wenig Mailverkehr anzufangen und die Hauptdomain zuletzt umzustellen ^[4].

Subdomains und Domains ohne Mailversand

Ein DMARC-Eintrag auf der Hauptdomain gilt auch für alle Subdomains, die keinen eigenen Eintrag haben, sogar für solche, die es gar nicht gibt ^{[1, 4]}. Mit sp legst du für vorhandene Subdomains eine andere Stufe fest, mit np für nicht existierende. Gerade np ist nützlich, weil Fälscher gern ausgedachte Subdomains wie rechnung.beispiel.de verwenden.

Für Domains, die nie Mails verschicken, zeigt Microsoft den kurzen Eintrag v=DMARC1; p=reject ohne Berichtsadressen, da von dort keine echten Mails kommen sollten ^[4]. Dazu passen ein SPF-Eintrag "v=spf1 -all" und ein Null-MX, wie im Ratgeber zum MX-Eintrag beschrieben.

Sammelberichte lesen

Sammelberichte (aggregate reports) kommen als XML-Datei, die meist mit gzip gepackt ist ^[2]. Ein Bericht deckt in der Regel einen Tag ab, gerechnet ab 0 Uhr UTC. Jeder Bericht betrifft genau eine Domain ^[2]. Die wichtigsten Teile:

• report_metadata: wer berichtet (org_name), über welchen Zeitraum (date_range, in Sekunden seit 1970).
• policy_published: der DMARC-Eintrag, den der Empfänger bei dir gefunden hat.
• record: je eine sendende IP-Adresse (source_ip) mit der Zahl der Mails (count), dem angewendeten Ergebnis (disposition) und dem DMARC-Ergebnis für DKIM und SPF.
• identifiers und auth_results: Absenderdomain (header_from), Umschlagdomain und die Einzelergebnisse von SPF und DKIM mit der jeweils geprüften Domain.

Die Feldnamen stammen aus RFC 9990 ^[2]. Beim Lesen gehst du die IP-Adressen durch. Adressen deines Mailanbieters sollten bestehen. Eine Adresse, die zu einem Dienst gehört, den du kennst, aber durchfällt, ist ein Einrichtungsfehler. Unbekannte Adressen mit vielen Fehlschlägen deuten auf Fälschungen hin. Wer sich als Firma gegen gefälschte Chefmails schützen will, findet Hintergründe unter CEO-Fraud und Business E-Mail Compromise.

Lesbar sind die Dateien von Hand nur bei wenigen Absendern. RFC 9989 empfiehlt, sie maschinell auszuwerten, und verweist auf die vielen Dienste, die das übernehmen, oder eigene Werkzeuge ^[1].

Berichte an eine fremde Domain

Liegt die Berichtsadresse unter einer anderen Domain, etwa bei einem Auswertungsdienst, muss diese Domain zustimmen. Sonst könnte jeder fremde Postfächer mit Berichten fluten. Der Empfänger fragt dafür einen TXT-Eintrag ab, der aus deiner Domain, dem Zusatz _report._dmarc und der Zieldomain besteht. Für beispiel.de und Berichte an berichte.example lautet er beispiel.de._report._dmarc.berichte.example und muss v=DMARC1 enthalten ^[2].

Fehlerberichte zu einzelnen Mails

Mit ruf kannst du zusätzlich Berichte zu einzelnen fehlgeschlagenen Mails anfordern. Sie können Kopfzeilen und Teile des Inhalts enthalten und damit personenbezogene Daten. RFC 9991 hält fest, dass viele große Anbieter solche Berichte deshalb einschränken oder ganz abschalten, und empfiehlt die Sammelberichte als üblichen Weg ^[3]. Outlook.com zum Beispiel verschickt Sammelberichte, plant aber keine Fehlerberichte ^[5]. Für die meisten Domains reicht rua.

Mailinglisten und p=reject

Mailinglisten und Weiterleitungen sind die Schwachstelle von DMARC. Eine weitergeleitete Mail kommt von einer fremden IP-Adresse, SPF schlägt dann fehl. Die DKIM-Signatur bleibt meist gültig, solange die Liste die Mail nicht verändert ^[1]. RFC 9989 zieht daraus zwei Regeln: Domains mit p=reject dürfen sich nicht allein auf SPF verlassen und müssen DKIM einsetzen. Domains, deren Nutzer an Mailinglisten im Internet schreiben, sollten p=reject nicht verwenden ^[1]. Wer trotzdem p=reject setzen will, soll laut RFC 9989 seine Nutzer darauf hinweisen, dass die Teilnahme an Mailinglisten dann Probleme machen kann ^[1]. Auch für Empfänger zieht RFC 9989 eine Grenze: Lehnt ein Server Mails ab, die eine Liste weitergereicht hat, hält die Listensoftware die Adresse leicht für ungültig und trägt den Abonnenten automatisch aus ^[1]. Die meisten Mailinglisten ändern deshalb inzwischen das From-Feld, zum Beispiel auf die Adresse der Liste, damit weitergereichte Mails DMARC bestehen ^[1].

Was große Postfachanbieter verlangen

Seit Februar 2024 verlangen Google und Yahoo von Absendern großer Mengen einen DMARC-Eintrag; p=none genügt ^{[6, 7]}. Google zieht die Grenze bei mehr als 5.000 Mails am Tag an Gmail-Konten ^[6]. Microsoft hat für Outlook.com, Hotmail und Live.com dieselbe Grenze eingeführt und lehnt seit dem 05.05.2025 Mails solcher Absender ab, die SPF, DKIM und DMARC nicht erfüllen ^[5]. Yahoo empfiehlt dringend, dabei eine rua-Adresse anzugeben ^[7]. Welche weiteren Punkte für die Zustellung zählen, steht unter Eigene E-Mails landen im Spam.

1. Gesetz RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). IETF. Stand Mai 2026. abgerufen am 29.10.2026
2. Gesetz RFC 9990: DMARC Aggregate Reporting. IETF. Stand Mai 2026. abgerufen am 29.10.2026
3. Gesetz RFC 9991: DMARC Failure Reporting. IETF. Stand Mai 2026. abgerufen am 29.10.2026
4. Organisation Einrichten von DMARC zum Überprüfen von E-Mails in Microsoft 365. Microsoft. Stand 03.07.2026. abgerufen am 29.10.2026
5. Organisation Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders. Microsoft Tech Community. Stand 02.04.2025, ergänzt 29.04.2025. abgerufen am 29.10.2026
6. Organisation Richtlinien für E-Mail-Absender. Google. Stand ohne Datum. abgerufen am 29.10.2026
7. Organisation Sender Requirements and Recommendations. Yahoo. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.