Zuletzt geprüft:
DMARC einrichten: Schritt für Schritt
DMARC verbindet die beiden Prüfverfahren SPF und DKIM mit der Absenderadresse, die Empfänger sehen, und sagt den Empfangsservern, was sie mit E-Mails tun sollen, die die Prüfung nicht bestehen. Gmail, Yahoo und Outlook.com verlangen von Massenversendern mindestens einen DMARC-Eintrag mit p=none. Diese Seite zeigt den Weg vom ersten Eintrag bis zu einer Richtlinie, die gefälschte E-Mails abweist. Grundlage ist RFC 9989 vom Mai 2026, der die frühere Fassung RFC 7489 ersetzt.1
Schritt 1: Voraussetzungen prüfen
Bevor Sie DMARC einrichten, sollten alle Systeme, die in Ihrem Namen E-Mails verschicken, SPF oder DKIM bestehen – besser beides:
- Inventur: Wer verschickt E-Mails mit Ihrer Domain im Absender? Typisch sind das eigene Postfach, das Newsletter-System, der Shop, die Buchhaltung, ein Kontaktformular, ein Ticketsystem.
- SPF: Alle diese Dienste stehen im SPF-Eintrag der Domain – es darf nur einen geben (RFC 7208). Einzelheiten unter SPF-Eintrag erstellen und prüfen.
- DKIM: Jeder Dienst signiert mit einem Schlüssel unter Ihrer Domain (RFC 6376). Signiert ein Dienst nur mit seiner eigenen Domain, besteht er DKIM zwar, aber nicht ausgerichtet an Ihrer Absenderadresse.
Schritt 2: Der erste Eintrag mit p=none
DMARC steht als TXT-Eintrag unter dem Namen _dmarc Ihrer Domain. Ein guter Anfang:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@example.com"| Teil | Bedeutung |
|---|---|
v=DMARC1 | Kennung, muss am Anfang stehen |
p=none | keine Vorgabe an Empfänger – nur beobachten |
rua=mailto:… | Adresse für die täglichen Sammelberichte |
RFC 9989 beschreibt genau diesen Weg: Domain-Inhaber beginnen üblicherweise mit p=none und einer Berichtsadresse, werten die Berichte aus, beheben Fehler und entscheiden erst dann über eine strengere Richtlinie.1 Den Eintrag können Sie mit dem DMARC-Baukasten zusammenstellen; er erklärt jede Option, fragt aber kein DNS ab.
Schritt 3: Berichte lesen
Empfangsserver, die DMARC-Berichte unterstützen, schicken an die rua-Adresse Sammelberichte als XML-Datei (RFC 9990). Sie zeigen je sendender IP-Adresse, wie viele E-Mails mit Ihrer Domain ankamen und ob SPF und DKIM bestanden und ausgerichtet waren.2 Was Sie darin suchen:
- Eigene Dienste, die durchfallen. Fehlt das Newsletter-System im SPF-Eintrag oder signiert es nicht mit Ihrer Domain, sehen Sie es hier.
- Dienste, die Sie vergessen hatten. Die Rechnungssoftware, ein altes Kontaktformular – alles, was mit Ihrer Domain sendet, taucht auf.
- Fremde Absender. E-Mails von Servern, die nichts mit Ihnen zu tun haben, sind oft Fälschungen. Genau gegen sie wirkt eine strengere Richtlinie.
Die XML-Dateien sind für Menschen schwer lesbar. Es gibt Dienste, die sie auswerten; prüfen Sie dabei, wohin die Berichte gehen, denn sie enthalten IP-Adressen und Domainnamen.
Schritt 4: Schrittweise verschärfen
Wenn die Berichte über mindestens einige Wochen – bei seltenen Versandarten wie Monatsrechnungen besser einige Monate – zeigen, dass alle eigenen Dienste bestehen, geht es weiter:
| Stufe | Eintrag (Auszug) | Wirkung |
|---|---|---|
| Beobachten | p=none | nichts, nur Berichte |
| Testen | p=quarantine; t=y | Testmodus: Empfänger sollen die Richtlinie noch nicht voll anwenden |
| Quarantäne | p=quarantine | nicht bestehende E-Mails gelten als verdächtig, z. B. Spam-Ordner |
| Ablehnen | p=reject | nicht bestehende E-Mails sollen abgelehnt werden |
Der frühere Prozent-Schalter pct ist in RFC 9989 entfallen; an seine Stelle tritt der Testmodus1 t=y bzw. t=n. In älteren Anleitungen finden Sie pct noch. Microsoft empfiehlt für Outlook.com auf Dauer3 p=reject.
Weitere Schalter
| Schalter | Bedeutung | Voreinstellung |
|---|---|---|
sp= | Richtlinie für Subdomains | wie p |
np= | Richtlinie für Subdomains, die es im DNS gar nicht gibt | wie sp |
adkim=, aspf= | Ausrichtung streng (s, identische Domain) oder locker (r, gleiche Organisationsdomain) | r |
ruf= | Adresse für Fehlerberichte zu einzelnen E-Mails | – |
fo= | wann Fehlerberichte erzeugt werden (wirkt nur zusammen mit ruf) | 0 (Bericht, wenn weder SPF noch DKIM ausgerichtet besteht) |
Die lockere Ausrichtung (r) erlaubt etwa, dass das Newsletter-System mit news.example.com signiert, während im Absender example.com steht. Für die meisten Newsletter ist sie die richtige Wahl.
Typische Fehler
- Zwei DMARC-Einträge unter
_dmarc– dann gilt keiner. - Sofort
p=reject, ohne Berichte gelesen zu haben: Eigene Rechnungen oder Formular-E-Mails werden abgelehnt. - Berichtsadresse in fremder Domain ohne Freigabe: Berichtsadressen müssen nach RFC 9989 (Abschnitt 11.6) in der Regel in der Domain liegen, über die berichtet wird. Für Adressen bei einem fremden Dienst beschreibt RFC 9990 ein Verfahren, mit dem dessen Domain im DNS zustimmt; fehlt die Zustimmung, kommen keine Berichte an.
- Weiterleitungen und Mailinglisten verändern E-Mails oder den Versandweg; dann können SPF und DKIM scheitern, obwohl die E-Mail echt ist. Prüfen Sie Auffälligkeiten in den Berichten, bevor Sie verschärfen.