DMARC-Policy-Guide: Von None zu Reject in 4 Schritten

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ist die Policy-Schicht, die SPF und DKIM miteinander verbindet und empfangenden Servern sagt, was sie tun sollen, wenn eine Nachricht die Authentifizierung nicht besteht. Ohne DMARC entscheidet ein Mailbox-Provider womöglich nach eigenen internen Regeln, ob unauthentifizierte E-Mails stillschweigend durchgelassen, in Quarantäne verschoben oder abgewiesen werden. Mit DMARC legst du explizit fest, wie E-Mails deiner Domain behandelt werden.

Dieser Guide führt dich durch den gesamten DMARC-Implementierungsprozess – vom Veröffentlichen deines ersten Monitoring-Records bis hin zur vollständigen Durchsetzung mit einer Reject-Policy.

Warum DMARC wichtig ist#

E-Mail-Spoofing ist nach wie vor einer der häufigsten Angriffsvektoren. Ein Angreifer kann den "From"-Header einer E-Mail so fälschen, dass die Nachricht aussieht, als käme sie von deiner Domain. Ohne DMARC haben empfangende Server keine zuverlässige Möglichkeit, deine Absicht für den Umgang mit solchen Nachrichten zu erkennen.

DMARC löst drei Probleme:

• Phishing-Prävention: Es hindert Angreifer daran, E-Mails zu versenden, die aussehen, als kämen sie von deiner Domain.
• Markenschutz: Es verhindert, dass deine Domain in Betrugskampagnen verwendet wird, die deinen Ruf schädigen.
• Sichtbarkeit: DMARC-Berichte zeigen dir genau, wer mit deiner Domain E-Mails versendet – inklusive legitimer Dienste, die du vielleicht vergessen hast, und unautorisierter Absender, von deren Existenz du nichts wusstest.

Große Mailbox-Provider wie Google, Microsoft und Yahoo verlangen inzwischen DMARC für Bulk-Versender. Seit 2024 verlangt Google, dass Domains, die mehr als 5.000 E-Mails pro Tag an Gmail-Adressen senden, eine DMARC-Policy veröffentlicht haben.

Wie DMARC mit SPF und DKIM zusammenarbeitet#

DMARC führt keine eigenen Authentifizierungsprüfungen durch. Stattdessen wertet es die Ergebnisse von SPF und DKIM aus und wendet eine zusätzliche Anforderung namens Alignment an.

Die Alignment-Anforderung#

Damit DMARC besteht, muss mindestens eine der folgenden Bedingungen erfüllt sein:

1. SPF besteht UND die per SPF authentifizierte Domain ist mit der Domain im "From"-Header aligned. SPF prüft den Envelope-Sender (Return-Path). DMARC verlangt, dass diese Domain mit der Domain im sichtbaren "From"-Header übereinstimmt (oder eine Subdomain davon ist).

2. DKIM besteht UND die DKIM-signierte Domain (d=-Tag) ist mit der Domain im "From"-Header aligned. Die Domain in der DKIM-Signatur muss mit der Domain im "From"-Header übereinstimmen (oder eine Subdomain davon sein).

Alignment kann entweder strict (exakte Domain-Übereinstimmung) oder relaxed (Subdomains sind erlaubt) sein. Relaxed ist der Standard und funktioniert für die meisten Konfigurationen.

Warum Alignment wichtig ist#

Ohne Alignment könnte ein Angreifer SPF und DKIM für attacker.com einrichten, eine Nachricht mit From: ceo@yourcompany.com senden, und die E-Mail würde die SPF- und DKIM-Prüfungen (für attacker.com) bestehen – aber der Empfänger sieht deine Domain. DMARC-Alignment schließt diese Lücke, indem es verlangt, dass die authentifizierte Domain mit dem übereinstimmt, was der Nutzer sieht.

DMARC-Record-Syntax#

Ein DMARC-Record ist ein DNS-TXT-Record, der unter _dmarc.yourdomain.com veröffentlicht wird. Hier ein vollständiges Beispiel:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;

Tag-Referenz#

Tag	Pflicht	Beschreibung	Werte
v	Ja	Protokollversion	Immer DMARC1
p	Ja	Policy für die Domain	none, quarantine, reject
rua	Nein*	Empfänger für Aggregate-Reports	mailto:-URI
ruf	Nein	Empfänger für Forensic-Reports	mailto:-URI
pct	Nein	Prozentsatz der Nachrichten, auf die die Policy angewendet wird	1-100 (Standard: 100)
aspf	Nein	SPF-Alignment-Modus	r (relaxed, Standard) oder s (strict)
adkim	Nein	DKIM-Alignment-Modus	r (relaxed, Standard) oder s (strict)
sp	Nein	Subdomain-Policy	none, quarantine, reject
fo	Nein	Failure-Reporting-Optionen	0, 1, d, s

*rua ist technisch zwar optional, du solltest es aber immer angeben. Ohne Aggregate-Reports veröffentlichst du eine Policy blind, ohne zu sehen, was passiert.

Policy-Werte erklärt#

• none: Nur Monitoring. Nachrichten, die DMARC nicht bestehen, werden normal zugestellt. Du erhältst Berichte mit den Authentifizierungsergebnissen, aber es wird keine Aktion ausgeführt. Das ist der Startpunkt.
• quarantine: Nachrichten, die DMARC nicht bestehen, werden als verdächtig behandelt. Üblicherweise landen sie im Spam- oder Junk-Ordner des Empfängers.
• reject: Nachrichten, die DMARC nicht bestehen, werden direkt abgewiesen. Der empfangende Server gibt einen Fehler zurück und die Nachricht wird nicht zugestellt.

Failure-Reporting-Optionen (fo-Tag)#

• 0 (Standard): Erzeugt nur dann einen Report, wenn sowohl SPF als auch DKIM kein Alignment haben.
• 1: Erzeugt einen Report, wenn entweder SPF oder DKIM kein Alignment hat. Das ist für Debugging nützlicher und die empfohlene Einstellung.
• d: Erzeugt einen Report, wenn DKIM fehlschlägt – unabhängig vom Alignment.
• s: Erzeugt einen Report, wenn SPF fehlschlägt – unabhängig vom Alignment.

Der 4-Schritte-Weg zur vollen Durchsetzung#

Direkt zu p=reject zu springen ist ohne Vorbereitung gefährlich. Du könntest legitime E-Mails von Diensten blockieren, die du gar nicht mehr auf dem Schirm hattest. Der sichere Ansatz ist eine schrittweise Progression.

Schritt 1: Mit p=none starten (Monitoring)#

Beginne mit einer reinen Monitoring-Policy, um Daten zu sammeln, ohne die Mail-Zustellung zu beeinflussen.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Was du in dieser Phase tun solltest:

• Veröffentliche den Record und warte mindestens 2 bis 4 Wochen, um genügend Report-Daten zu sammeln.
• Sieh dir die Aggregate-Reports an, um alle legitimen E-Mail-Quellen für deine Domain zu identifizieren. Dazu gehören dein primärer Mailserver, Marketing-Plattformen (Mailchimp, SendGrid, HubSpot), transaktionale E-Mail-Dienste, CRM-Systeme, Ticket-Systeme und alle SaaS-Tools, die in deinem Namen E-Mails versenden.
• Stelle für jede legitime Quelle sicher, dass SPF konfiguriert ist (die Sende-IPs des Dienstes in deinem SPF-Record enthalten sind) und DKIM eingerichtet ist (der öffentliche DKIM-Schlüssel des Dienstes in deinem DNS veröffentlicht ist).
• Untersuche alle Quellen, die du nicht erkennst. Das können entweder vergessene legitime Dienste oder unautorisierte Absender sein.

Dauer: Mindestens 2 bis 4 Wochen. Länger, wenn du eine komplexe Sende-Infrastruktur hast.

Schritt 2: Auf p=quarantine bei 25 % wechseln (sanfte Durchsetzung)#

Sobald du sicher bist, dass alle legitimen Quellen DMARC bestehen, beginne mit der Durchsetzung bei einem kleinen Prozentsatz des Traffics.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Das weist empfangende Server an, 25 % der Nachrichten, die DMARC nicht bestehen, in Quarantäne zu schicken (üblicherweise in den Spam-Ordner). Die übrigen 75 % werden so behandelt, als wäre die Policy none.

Was du in dieser Phase tun solltest:

• Beobachte die Reports genau auf Anstiege bei DMARC-Fehlschlägen aus legitimen Quellen.
• Wenn du einen neuen legitimen Sender entdeckst, bei dem SPF oder DKIM fehlt, korrigiere die Konfiguration, bevor du weitermachst.
• Achte auf Berichte, dass legitime E-Mails im Spam-Ordner landen.
• Sieht nach 1 bis 2 Wochen alles sauber aus, gehe zum nächsten Schritt über.

Dauer: 1 bis 2 Wochen.

Schritt 3: Auf p=quarantine bei 100 % erhöhen (volle Quarantäne)#

Entferne das Prozent-Limit, sodass die Quarantäne-Policy für alle fehlschlagenden Nachrichten gilt.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Oder lass den pct-Tag einfach weg, da 100 der Standard ist:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Was du in dieser Phase tun solltest:

• Beobachte weiterhin die Reports.
• Stelle sicher, dass keine legitimen E-Mails in Quarantäne landen.
• Sprich mit deinem Team, ob jemand fehlende E-Mails meldet.
• Nach 2 bis 4 Wochen ohne Probleme bist du bereit für den letzten Schritt.

Dauer: 2 bis 4 Wochen.

Schritt 4: p=reject durchsetzen (voller Schutz)#

Das ist der Endzustand. Nachrichten, die DMARC nicht bestehen, werden komplett abgewiesen.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

Ab diesem Punkt werden Nachrichten, die ohne korrekte Authentifizierung von deiner Domain versendet werden, abgewiesen. Deine Domain ist vollständig gegen Spoofing geschützt.

Laufende Wartung:

• Schau dir Aggregate-Reports weiterhin mindestens monatlich an.
• Wenn du einen neuen E-Mail-Versanddienst hinzufügst, konfiguriere SPF und DKIM dafür, bevor du E-Mails sendest.
• Rotiere DKIM-Schlüssel regelmäßig und prüfe, dass neue Schlüssel DMARC bestehen.
• Erwäge, ruf für Forensic-Reports hinzuzufügen, wenn dein Postfach das Volumen verkraftet.

DMARC-Reports lesen#

Aggregate-Reports (rua)#

Aggregate-Reports sind XML-Dateien, die von empfangenden Servern täglich gesendet werden. Sie enthalten:

• Den Namen der Organisation, die den Report erstellt hat.
• Den abgedeckten Zeitraum.
• Deine veröffentlichte DMARC-Policy.
• Für jede Quell-IP, die mit deiner Domain E-Mails versendet hat: die Anzahl der Nachrichten, SPF-/DKIM-/DMARC-Ergebnisse und Alignment-Ergebnisse.

Ein vereinfachter Auszug aus einem Aggregate-Report sieht so aus:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Rohes XML ist in größerem Umfang schwer lesbar. Die meisten Organisationen nutzen einen DMARC-Report-Analyse-Service oder ein Tool, um die Daten zu parsen und zu visualisieren. Dienste wie Postmarks kostenloses DMARC-Monitoring, dmarcian oder EasyDMARC können dabei helfen.

Forensic-Reports (ruf)#

Forensic-Reports enthalten Details zu einzelnen Nachrichten, die DMARC nicht bestanden haben – inklusive Message-Headers und manchmal Teilen des Inhalts. Sie sind nützlich, um konkrete Spoofing-Vorfälle zu untersuchen, erzeugen aber hohe Volumina und können sensible Informationen enthalten. Viele Empfänger senden aus Datenschutzgründen keine Forensic-Reports mehr.

Häufige DMARC-Fallstricke#

1. p=reject ohne vorheriges Monitoring veröffentlichen#

Das ist der gefährlichste Fehler. Wenn ein legitimer E-Mail-Dienst nicht korrekt mit SPF und DKIM konfiguriert ist, werden seine Nachrichten abgewiesen. Starte immer mit p=none und werte die Reports aus.

2. Drittanbieter-Sender vergessen#

Die häufigste Ursache für DMARC-Fehlschläge aus legitimen Quellen ist, dass man ein SaaS-Tool vergisst, das mit deiner Domain E-Mails versendet. Häufige Übeltäter sind:

• Marketing-Automation-Plattformen
• Customer-Support-Ticket-Systeme
• CRM-Plattformen, die in deinem Namen E-Mails versenden
• Rechnungs- und Buchhaltungssoftware
• HR- und Recruiting-Tools
• Kalender- und Terminplanungs-Tools

Prüfe jeden mit deiner Domain verbundenen Dienst, bevor du p=none verlässt.

3. SPF-Record überschreitet 10 DNS-Lookups#

SPF hat ein hartes Limit von 10 DNS-Lookup-Mechanismen (include, a, mx, redirect, exists). Überschreitet dein SPF-Record dieses Limit, gibt die SPF-Auswertung einen "permerror" zurück, was bedeutet, dass SPF für alle Nachrichten effektiv fehlschlägt. Da DMARC verlangt, dass entweder SPF oder DKIM mit Alignment besteht, lastet ein SPF-permerror mehr Druck auf DKIM.

Wenn du viele Versanddienste hast, erwäge, deinen SPF-Record zu flatten oder eine Subdomain-Strategie zu nutzen, bei der unterschiedliche Dienste von unterschiedlichen Subdomains senden.

4. rua nicht verwenden#

Ohne Aggregate-Reports hast du keinen Einblick, wie die E-Mails deiner Domain authentifiziert werden. Nimm immer ein rua-Tag auf – auch bei p=none.

5. Subdomains ohne sp=-Tag#

Standardmäßig erben Subdomains die Policy der Hauptdomain, wenn du den sp-Tag nicht setzt. Wenn du Subdomains für unterschiedliche Zwecke nutzt (z. B. marketing.yourdomain.com), erwäge, eine explizite Subdomain-Policy zu setzen oder separate DMARC-Records pro Subdomain zu veröffentlichen.

6. DMARC nach Erreichen von Reject ignorieren#

DMARC ist keine "einmal einrichten und vergessen"-Konfiguration. Neue Versanddienste kommen hinzu, Schlüssel laufen ab, SPF-Records werden geändert. Schau dir Aggregate-Reports weiterhin monatlich an, um Regressionen zu erkennen.

Deine DMARC-Konfiguration prüfen#

Du kannst deinen aktuellen DMARC-Record per DNS-Abfrage prüfen:

dig TXT _dmarc.yourdomain.com

Für eine umfassende Prüfung, die deinen DMARC zusammen mit SPF, DKIM, MX-Records und Blacklist-Status auswertet, nutze Nova Uptimes kostenlosen Email Health Checker. Das Tool gibt dir einen Score von 100, eine Buchstabennote (A bis F) und konkrete Empfehlungen, wie du deine DMARC-Policy verbessern kannst.

Das Tool bewertet die Strenge deiner DMARC-Policy als Teil des Scores. Eine p=reject-Policy mit Aggregate-Reporting bekommt den höchsten Score, während p=none oder ein fehlender DMARC-Record zu deutlichen Punktabzügen führt. So bekommst du ein klares Bild davon, wo deine Domain steht und welche Schritte als Nächstes anstehen.

DMARC-Implementierungs-Timeline#

Hier ein realistischer Zeitplan für ein vollständiges DMARC-Deployment:

Woche	Aktion	DMARC-Record
1	Monitoring-Record veröffentlichen, Report-Verarbeitung einrichten	p=none; rua=mailto:...
2-4	Reports auswerten, SPF/DKIM für alle legitimen Sender korrigieren	p=none; rua=mailto:...
5-6	Sanfte Durchsetzung bei 25 %	p=quarantine; pct=25; rua=mailto:...
7-8	Volle Quarantäne	p=quarantine; rua=mailto:...
9-12	Volle Durchsetzung	p=reject; rua=mailto:...
Laufend	Monatliche Report-Auswertung, Konfigurationen pflegen	p=reject; rua=mailto:...

Bei Organisationen mit einfacher E-Mail-Infrastruktur (ein primärer Mail-Dienst, ein bis zwei Marketing-Tools) lässt sich das auf 4 bis 6 Wochen verkürzen. Bei Unternehmen mit Dutzenden Versanddiensten plane 3 bis 6 Monate ein.

Wichtigste Erkenntnisse#

• DMARC baut auf SPF und DKIM auf, indem es Policy-Durchsetzung und Alignment-Anforderungen ergänzt.
• Starte immer mit p=none und Aggregate-Reporting. Springe niemals direkt auf p=reject.
• Nutze den pct-Tag, um die Durchsetzung schrittweise zu erhöhen.
• Werte Aggregate-Reports aus, um alle legitimen E-Mail-Quellen zu identifizieren, bevor du durchsetzt.
• p=reject zu erreichen ist das Ziel – aber es braucht Vorbereitung.
• Beobachte die Konfiguration auch nach dem Deployment weiter. DMARC erfordert laufende Pflege.
• Nutze Nova Uptimes Email Health Checker, um deine DMARC-Konfiguration zu verifizieren und eine vollständige E-Mail-Authentifizierungs-Bewertung zu bekommen.

Eine sauber implementierte DMARC-Policy gehört zu den stärksten Schutzmaßnahmen, die du für deine Domain einsetzen kannst. Sie verhindert Spoofing, baut Vertrauen bei Mailbox-Providern auf und gibt dir klare Sichtbarkeit darüber, wer in deinem Namen E-Mails versendet.

Häufig gestellte Fragen#

Was ist ein DMARC-Check?#

Ein DMARC-Check verifiziert, ob deine Domain einen gültigen DMARC-DNS-Record hat, und bewertet seine Policy-Einstellungen. Er bestätigt, dass die Syntax deines DMARC-Records korrekt ist, deine Policy (none/quarantine/reject) richtig konfiguriert ist und deine Reporting-Adressen funktionieren. Führe einen kostenlosen DMARC-Check aus, um deine aktuelle Konfiguration zu sehen.

Ist kostenloses DMARC-Monitoring möglich?#

Ja. Nova Uptime enthält DMARC-Monitoring als Teil seines Email Health Checkers. Es prüft deinen DMARC-Record zusammen mit SPF, DKIM und Blacklist-Status auf einem konfigurierbaren Zeitplan und alarmiert dich, wenn sich etwas ändert. Der kostenlose Plan deckt bis zu 5 Domains ab.

Wie lange dauert es, bis man p=reject erreicht?#

Für die meisten Organisationen dauert die Progression von p=none bis p=reject 2 bis 4 Monate. Der Zeitplan hängt davon ab, wie viele legitime E-Mail-Quellen du identifizieren und authentifizieren musst. Eilig zu reject zu springen, ohne DMARC-Reports auszuwerten, riskiert, deine eigenen legitimen E-Mails zu blockieren.

Was passiert, wenn ich DMARC ohne SPF und DKIM auf reject setze?#

Deine E-Mails werden von empfangenden Servern abgewiesen. Die DMARC-Durchsetzung verlangt, dass mindestens entweder SPF oder DKIM besteht UND mit deiner From-Domain aligned ist. Richte zuerst SPF und DKIM ein und führe DMARC dann schrittweise von none zu reject.

Verwandte Artikel#

• SPF, DKIM & DMARC: Vollständiger Guide — Wie alle drei Protokolle zusammenarbeiten
• DMARC-Test- & Konfigurations-Guide — Fortgeschrittene DMARC-Policy-Konfiguration
• E-Mail-Blacklist-Check & Removal-Guide — Was tun, wenn Authentifizierungsprobleme zu Blacklisting führen
• E-Mail-Deliverability-Checkliste — 15 Schritte für besseres Inbox-Placement
• Kostenloser Email Health Checker — DMARC, SPF, DKIM und Blacklists in einem Scan prüfen