DMARC-Policy: none, quarantine oder reject – welche solltest du verwenden?

Starte jede Einführung von DMARC (Domain-based Message Authentication, Reporting, and Conformance) mit p=none, beobachte die Aggregate-Reports ein paar Wochen lang, gehe dann auf p=quarantine und schließlich auf p=reject, sobald du sicher bist, dass jede legitime Versandquelle besteht. Direkt auf p=reject zu springen ist der häufigste Weg, auf dem Teams versehentlich ihre eigenen Transaktions- oder Marketing-Mails blockieren. Der Policy-Tag selbst ist simpel; die Disziplin, die Stufen sicher zu durchlaufen, ist der Punkt, an dem die meisten DMARC-Einführungen scheitern.

Was DMARC tatsächlich prüft

DMARC, definiert in RFC 7489, authentifiziert eine Nachricht nicht selbst – es baut auf SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail) auf und teilt empfangenden Mailservern mit, was zu tun ist, wenn beide fehlschlagen. Eine Nachricht besteht DMARC, wenn mindestens SPF oder DKIM besteht und dabei mit der Domain im sichtbaren From:-Header aligned ist, also übereinstimmt. Das Alignment ist wichtiger, als viele erwarten: Ein SPF-Pass für eine andere Versanddomain oder eine DKIM-Signatur einer fremden Domain zählt nicht.

Ein DMARC-Eintrag ist ein TXT-Record, der unter _dmarc.yourdomain.com veröffentlicht wird. Hier ein minimales Beispiel:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"

Falls du SPF noch nicht eingerichtet hast, erledige das zuerst – siehe unseren Leitfaden dazu, wie du einen sicheren SPF-Eintrag erstellst –, denn DMARC ohne einen authentifizierten Versandweg schützt gar nichts.

p=none vs. quarantine vs. reject

Der p=-Tag legt die Policy fest, die Empfänger auf Nachrichten anwenden sollen, die das DMARC-Alignment nicht bestehen. Außerdem gibt es einen sp=-Tag für Subdomains, der p= übernimmt, wenn du ihn nicht separat setzt.

p=none dient wirklich nur dem Monitoring: Es fordert keine Durchsetzung an, kann also die Zustellbarkeit nicht beeinträchtigen, setzt Spoofern aber auch keinen Widerstand entgegen. Mit p=quarantine und p=reject beginnt DMARC, echte Anti-Phishing-Arbeit zu leisten – es sind aber auch die Einstellungen, die dir auf die Füße fallen, wenn eine vergessene Marketingplattform oder ein Rechnungstool E-Mails von deiner Domain versendet, ohne das SPF-/DKIM-Alignment zu bestehen.

WarningWenn du sp= nicht setzt, übernehmen Subdomains den p=-Wert deiner Hauptdomain. Ein p=reject auf der Root-Domain lehnt auch fehlschlagende Mails von jeder Subdomain ab, sofern du es nicht überschreibst – prüfe deine Subdomains, bevor du die Policy durchsetzt.

Warum du DMARC-Reports brauchst, bevor du etwas durchsetzt

Der rua=-Tag legt fest, wohin aggregierte XML-Reports gesendet werden, und ruf= (seltener unterstützt) bestimmt, wohin forensische bzw. Fehler-Reports gehen. Für die Einführung sind die Aggregate-Reports entscheidend: Sie listen jede Quell-IP auf, die angeblich im Namen deiner Domain Mails versendet, und zeigen, ob sie das SPF-/DKIM-Alignment bestanden hat oder nicht.

Ohne Reports ist der Wechsel von none zu quarantine oder reject reines Raten. Mit ihnen wird daraus eine Checkliste:

• Jeder legitime Mailstrom (Transaktionsdienst, Marketingplattform, Helpdesk, interner Relay) taucht in den Reports als bestanden auf.
• Jede unbekannte Quelle ist entweder identifiziert und korrigiert oder tatsächlich nicht autorisiert und kann gefahrlos blockiert werden.
• Kein legitimer Absender mit hohem Volumen scheitert am Alignment wegen eines falsch konfigurierten SPF-Includes oder fehlender DKIM-Signierung.

Die meisten Report-Auswertungen laufen über Dashboards von Drittanbietern, da das rohe XML von Hand mühsam zu lesen ist – doch für große Agenturen oder Gründer, die eine Handvoll Domains betreiben, kann schon ein kurzer Blick auf die Reports einiger Wochen ausreichen, um einen unberechtigten Absender zu entdecken.

So stellst du DMARC sicher von none auf reject um

Eine gestaffelte Einführung über mehrere Wochen ist der Standardansatz:

1. Veröffentliche p=none mit gesetztem rua=. Lass die Reports mindestens 1–2 Wochen lang auflaufen – länger, wenn du E-Mails in monatlichen Batches oder über selten genutzte Plattformen (Rechnungsstellung, HR-Systeme) versendest.
2. Korrigiere jeden fehlschlagenden legitimen Absender. Ergänze fehlende SPF-Includes, aktiviere die DKIM-Signierung auf der Plattform oder sorge dafür, dass die From:-Domain mit dem übereinstimmt, was SPF/DKIM tatsächlich authentifizieren.
3. Wechsle zu p=quarantine mit einem niedrigen pct=. Der pct=-Tag wendet die Policy nur auf einen Prozentsatz der fehlschlagenden Nachrichten an (Standard ist 100, wenn er fehlt), sodass p=quarantine; pct=10 die Policy bei etwa jeder zehnten fehlschlagenden Nachricht durchsetzt – ein Sicherheitsnetz, während du prüfst, dass nichts Legitimes hängen bleibt.
4. Erhöhe pct= schrittweise über mehrere Wochen auf 25, 50 und dann 100 und beobachte bei jedem Schritt die Reports.
5. Wiederhole denselben gestaffelten Prozess für p=reject, statt direkt von quarantine auf volles reject zu springen.
6. Setze sp= explizit, sobald die Root-Domain durchgesetzt ist, besonders für Subdomains, die nie Mails versenden – dort ist reject die richtige Wahl, da es keinen legitimen Traffic gibt, der kaputtgehen könnte.

TipNutze unseren kostenlosen DMARC-Generator, um den Eintrag mit korrekter Tag-Reihenfolge und Syntax zu erstellen – ein einziges fehlerhaftes v= oder ein fehlendes Semikolon führt dazu, dass Empfänger den Eintrag komplett ignorieren, wodurch du stillschweigend ohne jeden Schutz dastehst.

Alignment-Modus: relaxed oder strict

Zwei weitere Tags bestimmen, wie streng der Abgleich ist: adkim= für das DKIM-Alignment und aspf= für das SPF-Alignment. Relaxed (r, der Standard) akzeptiert eine Übereinstimmung auf Ebene der Organisationsdomain – mail.example.com ist mit example.com aligned. Strict (s) verlangt eine exakte Übereinstimmung. Relaxed ist für die meisten Setups der sicherere Standard; strict lohnt sich, sobald du bei p=reject angekommen bist und eine Lücke für Subdomain-Spoofing schließen willst.

Verlangen Mailbox-Provider p=reject?

Kein großer Mailbox-Provider schreibt p=reject vor. Die Bulk-Sender-Anforderungen von Google und Yahoo verlangen einen veröffentlichten DMARC-Eintrag mit mindestens p=none, und auch Microsoft empfiehlt, mit der Zeit auf quarantine/reject umzustellen, statt es zwingend vorzuschreiben. Trotzdem: p=none allein verhindert kein Spoofing – es ist ein Reporting-Mechanismus, keine Abwehr. Betrachte es als ersten Schritt der Einführung, nicht als Ziel.

DMARC mit deinen übrigen DNS-Einträgen synchron halten

DMARC-, SPF- und DKIM-Einträge liegen alle als TXT-Records im DNS, neben deinen MX- und CAA-Einträgen – ein Blick in unseren vollständigen Leitfaden zu DNS-Record-Typen lohnt sich, wenn du das komplette Mail-Setup einer Domain prüfst. Die Verwaltung dieser Einträge fällt leichter, wenn die Zonen all deiner Domains an einem Ort liegen statt verstreut über verschiedene Registrar-Konsolen.

Bereit, deine Policy zu verschärfen? Verwalte den Eintrag mit unseren DNS-Management-Tools zusammen mit dem Rest deiner Zone und nutze den DMARC-Generator, um deinen nächsten p=-Schritt korrekt zu erstellen.