DMARC-Enforcement: von p=none kontrolliert zu quarantine oder reject

Was eine durchgesetzte Policy bewirkt – und was nicht

Eine Nachricht besteht DMARC, wenn mindestens ein Prüfpfad erfolgreich und zur sichtbaren Absenderdomain ausgerichtet ist: SPF für die Domain im SMTP-Rückpfad oder eine gültige DKIM-Signatur mit ihrer Signierdomain d=. Die Policy im DNS teilt Empfängern mit, wie Sie als Domaininhaber Nachrichten einschätzen, die diese Prüfung nicht bestehen. RFC 9989 spricht von Enforcement, wenn für eine Organisationsdomain und alle Subdomains darunter nicht mehr p=none gilt. RFC 9989, Abschnitte 3.2.9 und 4.4

Die Definitionen stehen in RFC 9989, Abschnitte 4.7, 5.4 und 7.4. Was genau mit einer Nachricht geschieht, entscheidet immer der Empfänger nach seinen eigenen Regeln. Er darf auch Nachrichten ablehnen oder aussortieren, die DMARC bestehen.

Eine durchgesetzte Policy hat klare Grenzen:

• Ähnliche Domains und Anzeigenamen: DMARC betrifft nur die exakte Domain im From. Gegen eine ähnlich geschriebene Domain, eine andere Top-Level-Domain oder einen täuschenden Anzeigenamen mit fremder Adresse hilft Ihre Policy nicht. RFC 9989, Abschnitte 2.2 und 11.4 Die Abschnitte zu Homograph-Angriffen und E-Mail-Spoofing behandeln diese Fälle.
• Missbrauch berechtigter Wege: Ein kompromittiertes Postfach, ein missbrauchtes Konto bei Ihrem Versanddienst oder eine zu weit gefasste SPF-Autorisierung erzeugt Nachrichten, die DMARC bestehen. Ein Pass besagt nur, dass die Nutzung der Domain für diese Nachricht autorisiert erscheint, nicht dass sie harmlos ist. RFC 9989, Abschnitte 1 und 11.1 Siehe auch Business Email Compromise.
• Übernommene Subdomains: Bei relaxed Alignment kann jemand, der SPF- oder DKIM-Einträge einer Subdomain kontrolliert, für Ihre Organisationsdomain einen DMARC-Pass erzeugen. RFC 9989, Abschnitt 11.8 Mehr dazu unter Echospoofing und SubdoMailing.
• Nachweis: Ein veröffentlichter Record beweist nicht, dass Ihre Nachrichten tatsächlich signiert und ausgerichtet sind. Ein Fehlschlag in einem Bericht beweist keinen Angriff. Ob Ihre Maßnahmen organisatorischen oder rechtlichen Anforderungen genügen, beantwortet dieser technische Ratgeber nicht; dafür gibt es das Kapitel E-Mail-Compliance.

Welche Zielpolicy zu welcher Domain passt

p=reject ist kein Pflichtziel für jede Domain. Die passende Dauerpolicy hängt davon ab, wer die Domain zum Versand nutzt.

Belege: RFC 9989, Abschnitt 7.4 und Anhang C.6, RFC 7960, Abschnitt 4.1.1.1, RFC 7505 zu Null MX. Ein vollständiges Beispiel für eine Domain ohne Versand und Empfang enthält der DMARC-Ratgeber.

Anforderungen großer Postfachanbieter sind kein Enforcement

Google, Yahoo und Microsoft verlangen für den Massenversand an ihre Verbraucherpostfächer eine DMARC-Policy – aber mindestens p=none, nicht quarantine oder reject. Die folgende Übersicht gibt die am 27. September 2026 gelesenen Anbieterseiten wieder. Sie gilt jeweils nur für den genannten Dienst und kann sich ändern.

Quellen: Google Email sender guidelines und Email sender guidelines FAQ; Yahoo Sender Requirements & Recommendations und FAQs; Microsoft Outlook-Anforderungen für Massenversender und Fehler 550 5.7.515.

Eine Enforcement-Policy verlangt keine dieser Seiten. Yahoo empfiehlt sie unabhängig davon, wenn Ihre Domain gefälscht wird; Microsoft rät zu einem schrittweisen Weg von none über quarantine zu reject, sobald legitime Quellen ausgerichtet sind. Wer eine Schwelle knapp erreicht, sollte die aktuelle Anbieterseite prüfen, statt sich auf eine Zahl aus einer älteren Anleitung zu verlassen.

Welche Identitäten zusammenpassen müssen

Bevor Sie eine Policy verschärfen, müssen Sie für jeden Versandweg wissen, welche Domains er tatsächlich verwendet. Diese Identitäten entstehen an verschiedenen Stellen und erscheinen in Nachrichtenheadern und Berichten unter eigenen Namen.

Belege: RFC 9989, Abschnitte 3.2.2–3.2.4, 4.4 und 5.3.1, RFC 9990, Abschnitt 3.1.1, RFC 8601, Abschnitte 2.7.1 und 2.7.2.

Standard ist relaxed Alignment: Die verglichene Domain muss zur selben Organisationsdomain gehören wie die From-Domain, etwa bounces.example.com zu example.com. Strict (aspf=s beziehungsweise adkim=s) verlangt identische Domains. RFC 9989 bestimmt die Organisationsdomain über eine Suche nach DMARC-Records im DNS, nicht durch Abschneiden der letzten beiden Namensteile; ältere Empfänger stützen sich teils noch auf die Public Suffix List. Nach RFC 9989 genügt relaxed Alignment fast allen Domaininhabern. Strict Alignment verhindert im jeweiligen Prüfpfad, dass allein die gemeinsame Organisationsdomain für den Pass genügt. Beide Pfade müssen entsprechend eingestellt sein, wenn Sie diese Möglichkeit ausschließen wollen. Das verhindert keine Subdomain- oder Kontoübernahme; jeder Dienst muss für den betreffenden Pfad exakt die From-Domain verwenden. RFC 9989, Abschnitte 3.2.10, 4.4, 4.10 und 11.8

Authentifiziert heißt nicht ausgerichtet. Dieses gekürzte, erfundene Headerfragment zeigt einen häufigen Fall bei Versanddienstleistern:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.mailer.example.org;
  dkim=pass header.d=mailer.example.org header.s=s1;
  dmarc=fail header.from=example.com

SPF und DKIM bestehen, aber jeweils für die Domain des Dienstleisters mailer.example.org. Keine der beiden gehört zur Organisationsdomain example.com der sichtbaren Absenderadresse, deshalb schlägt DMARC fehl. Abhilfe schafft eine vom Dienst unterstützte eigene Rückpfad-Domain unter example.com oder eine DKIM-Signatur mit d=example.com beziehungsweise einer Subdomain davon. Werten Sie nur Ergebnisse aus, die Ihr eigenes vertrauenswürdiges Empfangssystem eingetragen hat; wie Sie das erkennen, erklärt der Abschnitt zu Headerbefunden. RFC 8601, Abschnitt 5

Der Weg im Überblick: Entscheidungen statt Kalenderwochen

RFC 9989 beschreibt die Einführung als Folge von Entscheidungen: Berichtsziel einrichten, mit p=none und rua beobachten, Berichte auswerten, legitime Versandwege korrigieren und erst danach entscheiden, ob eine strengere Policy passt. Legitime Lücken müssen vor einer Enforcement-Policy behoben sein. Je nach Versandrhythmus kann es nach dem RFC viele Monate Berichtsauswertung dauern, bis Sie sicher sind, dass Sie Ihren gesamten Versand richtig authentifizieren. RFC 9989, Abschnitte 5.1.3–5.1.7

Feste Wochenpläne ersetzen diese Prüfung nicht. Konkrete Mindestzeiträume nennt RFC 9989 nur für Domains, deren Nutzer an Mailinglisten teilnehmen könnten und die trotz des Abratens p=reject veröffentlichen wollen: zuerst mindestens einen Monat p=none, danach ebenso lange p=quarantine, jeweils mit Vergleich der Berichtsdaten. RFC 9989, Abschnitt 7.4

Phase 1: Senderinventar aufbauen und mit p=none beobachten

Richten Sie zuerst ein erreichbares und betreutes Berichtsziel ein. Veröffentlichen Sie dann p=none mit rua und kontrollieren Sie, ob Berichte ankommen und ausgewertet werden können. RFC 9989 nennt die sorgfältige Auswertung der Aggregatberichte wesentlich für jede erfolgreiche Einführung und empfiehlt, sie maschinell zu verarbeiten – mit eigenen Werkzeugen oder einem Dienst. RFC 9989, Abschnitte 5.1.3 und 5.1.5

• Berichtsziel einrichten: ein eigenes Postfach oder einen bewusst gewählten Dienst mit geregeltem Zugriff, nicht das persönliche Postfach einer einzelnen Person.
• Vorhandenen Stand sichern: bestehenden Record, TTL, Zeitpunkt und Zuständigkeit notieren. Prüfen Sie auch, ob eine übergeordnete Policy greift.
• Zuständigkeiten klären: wer DNS ändern darf, wer Berichte liest und wer für jeden Versanddienst Ansprechpartner ist.

Für eine Organisationsdomain ohne bisherige Policy kann der Beobachtungsrecord so aussehen. Name und Adresse sind Dokumentationsbeispiele; die Zeile wurde nicht veröffentlicht. Manche DNS-Oberflächen erwarten im Namensfeld nur _dmarc und die Anführungszeichen nicht als Teil des Werts.

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

Liegt das Berichtsziel außerhalb Ihrer Organisationsdomain, muss der Empfänger der Berichte die Annahme im DNS bestätigen; sonst ignorieren standardkonforme Berichtssender dieses Ziel. Der Eintrag gehört in die Zone des Berichtsempfängers, nicht in Ihre. Für eine Policy an example.com und das Ziel dmarc@reports.example.net sieht er schematisch so aus:

example.com._report._dmarc.reports.example.net.  IN  TXT  "v=DMARC1"

Maßgeblich ist die Domain, von der die Policy tatsächlich stammt. RFC 9990, Abschnitt 4; weitere Einzelheiten im DMARC-Ratgeber.

Das Senderinventar

Das Inventar ist die Liste aller Systeme, die Nachrichten mit Ihrer Domain im From versenden – unabhängig davon, ob sie schon in Berichten auftauchen. Berichte zeigen nur, was berichtende Empfänger in einem Zeitraum beobachtet haben; seltene Aussendungen fehlen leicht. Fragen Sie deshalb auch Fachbereiche und Verträge ab: Postfächer, Newsletter und Marketing-Automation, CRM und Vertrieb, Ticket- und Helpdesksysteme, Rechnungs- und ERP-Versand, Webshop und Kontaktformulare, Termin- und Kalenderwerkzeuge, Bewerbermanagement, Alarm- und Überwachungsmeldungen, Scanner und Multifunktionsgeräte, Weiterleitungsregeln sowie automatische Antworten und Unzustellbarkeitsnachrichten.

Das Beispiel ist synthetisch; jede Zeile ist ein Versandweg, kein Anbieter. Die dritte und vierte Zeile zeigen typische Lücken: Der Rechnungsdienst authentifiziert nur seine eigene Domain, das Kontaktformular besteht allein über SPF. Vor quarantine braucht jeder legitime Weg mindestens einen ausgerichteten Pass. Vor reject braucht er zusätzlich eine gültige ausgerichtete DKIM-Signatur, weil SPF bei Weiterleitungen regelmäßig scheitert. RFC 9989 empfiehlt ohnehin, beide Verfahren einzusetzen; für die volle Teilnahme an DMARC verlangt es ausgerichtetes SPF und ausgerichtetes DKIM. RFC 9989, Abschnitte 4.5, 5.1.1, 5.1.2, 7.4 und 8

Weiter zu Phase 2, wenn …

• jede Quelle aus den Berichten einem Inventareintrag zugeordnet oder als indirekter Weg oder Missbrauch eingeordnet ist,
• jeder legitime Weg mindestens einen ausgerichteten Pass erzielt, belegt durch Berichte und eine eigene Testnachricht,
• alle relevanten Versandzyklen im Beobachtungszeitraum lagen oder gesondert geprüft wurden – auch seltene wie Jahresabschluss oder saisonale Aktionen,
• Weiterleitungen, Mailinglisten und zwischengeschaltete Gateways bekannt und bewertet sind,
• Rückweg, Zuständigkeiten und Kommunikation festgelegt sind.

Für legitime Versandwege verlangt RFC 9989, Authentifizierungs- und Alignment-Lücken vor einer Enforcement-Policy zu beheben. RFC 9989, Abschnitt 5.1.6 Eine hohe Gesamtquote bestandener Nachrichten reicht dafür nicht: Ein seltener, aber wichtiger Weg kann in der Quote verschwinden.

Aggregatberichte auswerten: Quellen einordnen statt Quoten lesen

Aggregatberichte nach RFC 9990 fassen zusammen, was ein berichtender Empfänger in einem Zeitraum zu Nachrichten mit Ihrer Domain beobachtet hat – bestandene wie fehlgeschlagene. Empfänger sollen mindestens alle 24 Stunden berichten; verpflichtet sind sie dazu nicht. Jeder Bericht betrifft genau eine Policy-Domain. RFC 9989, Abschnitte 1 und 5.3.8, RFC 9990, Abschnitt 3.1

Die Feldbedeutungen stehen in RFC 9990, Abschnitte 3.1.1, 3.1.6 und 3.3. Werten Sie Berichte nach Quellen aus, nicht nur nach Anteilen:

RFC 9989 beschreibt dieselbe Staffelung: Vollständig bestandene Prüfungen bestätigen Ihre Praxis, teilweise bestandene zeigen, wo auf dem Weg etwas bricht, vollständig gescheiterte zeigen ungeschützte Quellen oder Missbrauch. Eine zu großzügige Autorisierung kann DMARC-Passes für Nachrichten ermöglichen, die Sie nicht beabsichtigt haben. RFC 9989, Abschnitt 11.1 und Anhang B.5

Berichtsdaten können gefälscht oder absichtlich fehlerhaft sein. Verarbeiten Sie komprimierte XML-Dateien deshalb mit einem Werkzeug, das übergroße oder manipulierte Dateien abfängt, und behandeln Sie auffällige Einzelberichte mit Vorsicht. RFC 9990, Abschnitte 8.1 und 8.2

Beobachtung ist Ihre Betriebsaufgabe

Berichte kommen bei dem Ziel an, das Sie in rua angeben. Werten Sie sie selbst oder mit einem Dienst aus; ein bestimmtes externes Werkzeug ist keine Protokollvoraussetzung. Legen Sie fest, wer die Berichte wie oft liest, welche Veränderungen eine Prüfung auslösen – etwa eine neue Quelle mit nennenswertem Volumen oder ein sinkender ausgerichteter Anteil bei einem bekannten Dienst – und wie neue Versanddienste vor dem Start ins Inventar kommen. Das Berichtspostfach braucht Zugriffsregeln, die zu Ihren organisatorischen Anforderungen passen. RFC 9989, Abschnitte 5.1.5 und 10.1 Der E-Mail Security Check nimmt keine Berichte entgegen, wertet keine aus und überwacht Ihre Domain nicht.

Failure Reports nur mit klarem Zweck

Failure Reports (ruf) beschreiben einzelne fehlgeschlagene Nachrichten und können Kopfzeilen oder ganze Nachrichten mit personenbezogenen Inhalten enthalten. Viele Empfänger versenden sie nicht; Microsoft gibt für Microsoft 365 und Outlook.com an, keine zu senden. Für die Einführung einer Policy brauchen Sie sie nicht. Wenn Sie sie dennoch anfordern, klären Sie vorher Zweck, Empfänger, Zugriff und Aufbewahrung. RFC 9991, Abschnitte 1 und 7, RFC 9989, Abschnitt 10.2

Phase 2: p=quarantine – Auswirkungen gezielt beobachten

Mit p=quarantine stufen Sie DMARC-Fehlschläge als verdächtig ein. Was das konkret bedeutet, entscheidet der Empfänger: Spamordner, administrative Quarantäne, Markierung oder eine andere Behandlung. Microsoft beschreibt für Microsoft 365 bei aktivierter Einstellung zur Beachtung der DMARC-Policy den Junk-E-Mail-Ordner als Standard, der sich auf Quarantäne umstellen lässt. Dass eine legitime Nachricht für die Empfängerin auffindbar bleibt, ist nicht garantiert. RFC 9989, Abschnitt 4.7, Microsoft Learn

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

Ein zusätzliches sp=quarantine brauchen Sie nicht: Ohne sp gilt p auch für Subdomains ohne eigenen Record. Setzen Sie sp nur, wenn Subdomains bewusst anders behandelt werden sollen.

Beobachten Sie in dieser Phase vor allem:

• Berichtszeilen Ihrer Inventarquellen mit der Behandlung quarantine,
• Rückmeldungen über vermisste Newsletter, Rechnungen oder Einladungen, Helpdesk-Tickets und Hinweise von Partnern,
• Unzustellbarkeitsnachrichten an Ihre Rückpfad-Adressen,
• seltene Versandzyklen, die in Phase 1 noch nicht auftraten,
• über Mailinglisten oder Weiterleitungen verteilte Nachrichten Ihrer Nutzer.

Treten legitime Fehlschläge auf, korrigieren Sie zuerst den Versandweg. Ist das nicht kurzfristig möglich und sind wichtige Nachrichten betroffen, nehmen Sie die Policy zurück, wie im Abschnitt zur Rücknahme beschrieben.

Der Testmodus t=y: genaue Wirkung und Grenzen

RFC 9989 führt den Tag t neu ein. Mit t=y teilen Sie mit, dass Sie Ihre Policy testen: Wer die DMARC-Prüfung ausführt, soll die veröffentlichte Policy nicht anwenden, sondern gegebenenfalls eigene Sonderregeln – etwa das Umschreiben des From durch eine Mailingliste. Erwartet wird eine Behandlung eine Stufe unterhalb der veröffentlichten Policy. Auf die Berichterzeugung hat t=y keinen Einfluss, auf none keine Wirkung. RFC 9989, Abschnitt 4.7

t=y ersetzt die frühere Praxis mit pct=0: Manche Mittler und Postfachanbieter behandelten pct=0 als Signal, den From umzuschreiben. Wer Berichte vor und nach einer solchen Änderung verglich, konnte abschätzen, wie viel Verkehr über Mittler lief, die den From nicht umschreiben. pct selbst wurde mit Werten zwischen 0 und 100 in der Praxis ungenau umgesetzt und ist deshalb entfallen. RFC 9989, Anhang A.6

Ein Empfänger, der nur den früheren RFC 7489 umsetzt, ignoriert unbekannte Tags und kennt t nicht. RFC 7489, Abschnitt 6.3 Wie viele Empfänger t bereits auswerten, lässt sich aus dem DNS nicht ablesen und wurde für diesen Ratgeber nicht gemessen.

Woran Sie die Wirkung erkennen: In Aggregatberichten steht der veröffentlichte Wert unter policy_published/testing; eine wegen des Testmodus abweichende Behandlung kann als Grund policy_test_mode erscheinen. Im Header einer Nachricht kann der Empfänger die angewandte Policy als policy.dmarc angeben. Beides setzt voraus, dass der jeweilige Empfänger es einträgt. RFC 9990, Abschnitte 3.1.1.5 und 3.1.6, RFC 9989, Abschnitt 9.1

pct ist historisch. Empfänger nach RFC 9989 werten es nicht aus; ein pct=10 begrenzt die Policy dort nicht auf zehn Prozent. Nach dem früheren RFC 7489 bezeichnete pct den Anteil der Fehlschläge, auf den die Policy angewendet werden sollte; die übrigen Nachrichten sollten bei reject wie bei quarantine und bei quarantine normal behandelt werden. Ältere Implementierungen können noch so verfahren. Einige Anbieterhilfen beschreiben weiterhin pct-Stufen, etwa die Microsoft-Learn-Seite zu DMARC im Stand vom 3. Juli 2026. Das ist eine Abweichung in der Dokumentation, keine Aussage über das heutige Verhalten der Empfänger. RFC 9989, Anhang C.5, RFC 7489, Abschnitt 6.6.4

Phase 3: p=reject nur für geeignete Domains

Wer p=reject veröffentlicht, darf sich nach RFC 9989 nicht allein auf SPF verlassen und muss seine Nachrichten mit gültigen DKIM-Signaturen versehen. Damit eine Signatur den DMARC-Pass trägt, wenn SPF nach einer Weiterleitung scheitert, muss ihre Domain zur From-Domain ausgerichtet sein. RFC 9989, Abschnitte 7.4 und 8

Domains, deren Nutzer Nachrichten an Mailinglisten schicken könnten, sollen keine reject-Policy veröffentlichen; RFC 9989 richtet dieses Abraten ausdrücklich an Domains für den allgemeinen E-Mail-Verkehr. Wer sie dennoch veröffentlichen will, soll die Auswirkungen vorher mit Berichtsdaten prüfen – mindestens einen Monat p=none, danach ebenso lange p=quarantine – und entweder festlegen, dass Nutzer keine Internet-Mailinglisten verwenden, oder sie darauf hinweisen, dass ihre Teilnahme beeinträchtigt sein kann. RFC 9989, Abschnitt 7.4 und Anhang C.6

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Auch für Empfänger enthält RFC 9989 Regeln: Sie dürfen nicht allein wegen p=reject ablehnen und müssen ohne weitere Erkenntnisse wie bei quarantine verfahren. Zugleich stellt der RFC fest, dass Nachrichten, die Mailinglisten mit unverändertem From weiterleiten, in der Praxis häufig abgelehnt werden. Anbieter dokumentieren ihre eigenen Regeln: Google gibt an, bei DMARC-Fehlschlägen in der Regel die Policy der Absenderdomain anzuwenden; Yahoo nennt die Ablehnung von Nachrichten ohne passende DKIM-Signatur oder SPF-Alignment bei p=reject; Microsoft 365 lehnt solche Nachrichten bei aktivierter Einstellung zur Beachtung der DMARC-Policy während der SMTP-Sitzung ab. RFC 9989, Abschnitt 7.4, Google FAQ, Yahoo FAQ, Microsoft Learn

Bereit für reject, wenn …

• verbleibende Fehlschläge je legitimem Versandweg geklärt sind,
• repräsentative Versandzyklen unter quarantine ohne ungeklärte legitime Ausfälle beobachtet wurden,
• jeder legitime Weg eine gültige, ausgerichtete DKIM-Signatur trägt und nicht allein über SPF besteht,
• Mailinglisten und Weiterleitungen bewertet und betroffene Nutzer informiert sind,
• die wirksame Subdomain-Policy geprüft ist,
• der Rückweg vorbereitet ist.

Technische Richtlinie und organisatorischer Nachweis

Eine technische Policy allein belegt keine Konformität mit einer Richtlinie und keine Erfüllung gesetzlicher Pflichten. Die E-Mail-Compliance grenzt technische Richtlinien, organisatorische Anforderungen und den Aussagewert eines Scans voneinander ab. Klären Sie einen für Ihre Organisation geltenden Sollstand getrennt von der hier beschriebenen Interoperabilitätsentscheidung.

Subdomains und nicht existierende Namen: sp, np und eigene Records

Eine Policy an der Organisationsdomain gilt auch für Subdomains ohne eigenen Record. Welche Angabe greift, hängt davon ab, ob der Name existiert:

• Organisationsdomain selbst: p.
• Bestehende Subdomain ohne eigenen Record: sp; fehlt sp, gilt p.
• Nicht existierende Subdomain: np; fehlt np, gilt sp, sonst p. Nicht existierend ist ein Name, für den der DNS NXDOMAIN liefert. Jeder andere vorhandene Eintrag unter dem Namen genügt als Existenz.
• Subdomain mit eigenem gültigem Record: dessen p.

Belege: RFC 9989, Abschnitte 4.7 und 4.10.1 sowie Anhang A.4. Das folgende Zonenbeispiel ist synthetisch und wurde nicht veröffentlicht:

_dmarc.example.com.       IN  TXT  "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"
_dmarc.news.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Die Tabelle zeigt schematische Ergebnisse der Policy-Suche nach RFC 9989, keine gemessene Empfängerbehandlung. Weitere Regeln, die bei Subdomains häufig übersehen werden:

• Eigener Teilbaum mit psd=n: Soll ein Teilbaum eigene Regeln für seine Subdomains bekommen, kann dessen Record ihn mit psd=n zur eigenen Organisationsdomain erklären. Das hat eine Nebenwirkung: Relaxed Alignment zwischen Namen unterhalb von news.example.com und example.com besteht dann nicht mehr, weil beide unterschiedlichen Organisationsdomains angehören. RFC 9989, Abschnitte 4.10.2 und 5.1.8
• Record an der Organisationsdomain: Veröffentlichen Sie auch dort einen Record, wenn Sie nur für einzelne Subdomains Policies planen. Sonst gilt für die Hauptdomain keine DMARC-Policy. RFC 9989, Abschnitte 5.1.4 und 8
• Sehr lange Namen: Die Suche fragt höchstens acht Namen ab. Für Absenderdomains mit mehr als acht Labels müssen Sie einen Record direkt an diesem Namen veröffentlichen. RFC 9989, Abschnitte 4.10 und 5.1.8
• Wildcard-Einträge: Wenn ein Wildcard für den abgefragten Namen tatsächlich eine Antwort erzeugt, liegt kein NXDOMAIN vor; np greift dann nicht. Ein Wildcard deckt nicht pauschal jeden tieferen Namen ab: vorhandene Namen und näher liegende Teilbäume beeinflussen seine Anwendung. RFC 9989, Anhang A.4, RFC 4592, Abschnitt 2.2.1
• Ältere Empfänger: Empfänger nach RFC 7489 bestimmen die Organisationsdomain über eine Public Suffix List und können zu einem anderen Ergebnis kommen. Explizite Records für alle genutzten Absenderdomains vermeiden diese Abweichung. RFC 9989, Anhang C.3
• Verwaiste oder delegierte Subdomains: Entfernen Sie nicht mehr genutzte DNS-Einträge und prüfen Sie Delegationen. Bei relaxed Alignment kann eine übernommene Subdomain DMARC-Passes für Ihre Organisationsdomain erzeugen; strict Alignment begrenzt diesen Pfad; explizite Records legen die beabsichtigte Policy der genutzten Namen fest. Beides ersetzt weder die Bereinigung verwaister Einträge noch die Kontrolle delegierter DNS-Zonen. RFC 9989, Abschnitt 11.8

Eine Subdomain-Policy verhindert nicht den Missbrauch eines bereits autorisierten Versanddienstes.

Rücknahme und Sicherheitsnetze vorbereiten

Planen Sie die Rücknahme, bevor Sie verschärfen. Eine DNS-Änderung wirkt nicht überall gleichzeitig: Resolver dürfen eine Antwort bis zum Ablauf ihrer TTL zwischenspeichern. Wer die TTL vor einer geplanten Änderung senkt, muss zuerst die bisherige TTL abwarten, damit reguläre Caches die alte Antwort auslaufen lassen können. Die TTL steuert die reguläre Cache-Nutzung, ist aber keine Zusage einer weltweiten Aktualisierung; eine TTL von 300 Sekunden ist deshalb keine weltweite Fünf-Minuten-Garantie. Auch ein neu angelegter Record kann eine Zeit lang unsichtbar bleiben, wenn Resolver das vorherige Fehlen zwischengespeichert haben. RFC 1035, Abschnitt 3.2.1, RFC 2181, Abschnitt 8, RFC 2308, Abschnitt 5

Entscheidend ist die Quelle der wirksamen Policy: p=none an der Hauptdomain nimmt ein explizites sp=reject, np=reject oder einen eigenen p=reject-Record an einer Subdomain nicht zurück. Ermitteln und ändern Sie die jeweils betroffene Angabe.

Weitere Sicherheitsnetze:

• Dokumentieren Sie jede Änderung mit altem und neuem Record, TTL, Zeitpunkt und Zuständigen.
• Überspringen Sie keine Stufe, solange Berichte fehlen oder unklar sind.
• Nehmen Sie unbekannte IP-Adressen nicht pauschal in SPF auf, nur damit Fehlschläge verschwinden. Damit autorisieren Sie möglicherweise fremde Absender. Wer einen zu weit gefassten Absender in SPF behalten muss, kann ihn laut RFC 9989 mit dem Qualifier ? aus der DMARC-Bewertung heraushalten. RFC 9989, Abschnitt 11.1

Typische Fehlschläge finden und beheben

Gehen Sie von einer konkreten Nachricht oder Berichtszeile aus. Vergleichen Sie die Identitäten und klären Sie, ob die Authentifizierung oder das Alignment fehlt.

Belege: RFC 7960, Abschnitte 2.1.2, 2.2, 2.3 und 4.1, RFC 7208, Abschnitt 4.6.4 und Anhang D, RFC 9989, Abschnitte 4.4.1, 4.10, 7.1 und 7.4, RFC 9990, Abschnitt 4, Yahoo FAQ. Google empfiehlt für Weiterleitungen an Gmail ebenfalls DKIM, weil weitergeleitete Nachrichten SPF häufig nicht bestehen. Google: Weiterleitung an Gmail

ARC: eine Vertrauensentscheidung des Empfängers

Mit ARC können Weiterleiter und Listenserver die bei ihnen festgestellten Authentifizierungsergebnisse signiert weitergeben. Ob ein Empfänger diesen Angaben folgt, entscheidet er nach seiner lokalen Policy; ARC ist weder ein Vertrauensrahmen noch eine Reparatur gebrochener Signaturen. RFC 8617 hat den Status Experimental. RFC 9989 stellt fest, dass sich solche Verfahren für Listen ohne From-Umschreibung bis zu seiner Veröffentlichung nicht breit durchgesetzt haben. Empfangsseitig lassen sich teils vertrauenswürdige ARC-Siegel festlegen, bei Microsoft 365 etwa als „trusted ARC sealers“; Yahoo empfiehlt Weiterleitern, ARC einzusetzen. Als Absender können Sie die Auswertung bei fremden Empfängern nicht erzwingen. RFC 8617, Abschnitte 7.2.1 und 9.3 sowie Anhang A.2, RFC 9989, Abschnitt 7.4 Mehr im Kapitel ARC und E-Mail-Gateways.

Synthetisches Planungsbeispiel: Postfachdomain und Versandsubdomains trennen

Das folgende Beispiel ist erfunden. Es beschreibt keine Kundendomain und kein gemessenes Ergebnis; die Zeiträume sind Annahmen für einen monatlichen Rechnungsrhythmus.

Ausgangslage: Unter example.com arbeiten Mitarbeitende mit eigenen Postfächern, einige davon in fachlichen Mailinglisten. Außerdem versenden ein Newsletterdienst, ein Rechnungsdienstleister und das Kontaktformular der Website mit dieser Domain. Ziel: quarantine als Dauerpolicy für die Postfachdomain, reject für eigene Versandsubdomains.

1. Beobachten: example.com veröffentlicht p=none mit rua. Das Inventar entsteht aus Berichten und Rückfragen bei den Fachbereichen. Befund im Modell: Der Rechnungsdienst authentifiziert nur seine eigene Domain, das Kontaktformular besteht allein über SPF, ein Multifunktionsgerät ist ungeklärt. Beobachtet werden mindestens zwei Monatsabschlüsse.
2. Korrigieren: Der Rechnungsversand zieht auf rechnung.example.com um; der Dienst signiert mit d=rechnung.example.com und verwendet eine eigene Rückpfad-Domain darunter. Newsletter gehen über news.example.com mit eigener Signatur. Das Kontaktformular signiert per DKIM, das Gerät versendet über einen authentifizierten Einlieferungsdienst.
3. Quarantäne für die Postfachdomain: Zunächst p=quarantine; t=y, dann p=quarantine, ergänzt um np=reject. Über einen weiteren Monatsabschluss treten keine ungeklärten legitimen Fehlschläge auf. Wegen der Mailinglisten-Nutzer bleibt quarantine die Dauerpolicy.
4. Ablehnung für die Versandsubdomains: Nachdem Berichte und eigene Testnachrichten ausgerichtete DKIM-Signaturen für beide Dienste zeigen, erhalten news.example.com und rechnung.example.com eigene Records mit p=reject.
5. Betrieb: Während der Umstellung werden die Berichte wöchentlich durchgesehen, danach im festgelegten Rhythmus. Neue Dienste kommen vor dem Start ins Inventar.

Endstand im Modell, nicht veröffentlicht und nicht praktisch getestet:

_dmarc.example.com.           IN  TXT  "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"
_dmarc.news.example.com.      IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
_dmarc.rechnung.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Auch in diesem Endstand ist nicht jede abgelehnte Nachricht ein Angriff, und die Konfiguration schützt weder vor ähnlich geschriebenen Domains noch vor kompromittierten Konten.

Was der E-Mail Security Check dazu zeigt – und was nicht

Der E-Mail Security Check liest öffentlich abrufbare DNS-Daten als Momentaufnahme. Für DMARC zeigt er:

• die gefundene Policy für den eingegebenen Namen, einschließlich der Suche nach einer übergeordneten Policy nach RFC 9989 und der Auswahl von sp oder np; ist die Existenz des Namens nicht geklärt, bleibt die Auswahl offen,
• einen gesetzten Testmodus nach RFC 9989: p=reject; t=y erscheint als angeforderte Quarantäne, p=quarantine; t=y als none,
• ein vorhandenes historisches pct als Hinweis ohne Einfluss auf die Bewertung,
• veröffentlichte rua-Ziele und ob für ein externes Ziel der nach RFC 9990 nötige Autorisierungseintrag im DNS steht,
• als ungewichteten Hinweis, ob zu bekannten SPF-Anbieterzielen passende DKIM-Selektornamen im DNS gefunden wurden.

Nicht geprüft werden Nachrichtensignaturen, SPF- und DKIM-Ergebnisse echter Nachrichten, Alignment, die Behandlung durch Empfänger, Eingang oder Inhalt von Berichten und die Vollständigkeit Ihrer Versandwege. Der Check überwacht Ihre Domain nicht und meldet keine Änderungen.

p=none wertet der Check als gültige Beobachtungspolicy, nicht als gescheitertes Verfahren; eine feste Frist für den Wechsel leitet er daraus nicht ab. Dass reject in der Produktgewichtung mehr Punkte erhält als quarantine, ist keine Empfehlung, jede Domain auf reject zu stellen. Ordnet der Check eine Domain anhand eindeutiger DNS-Daten dem Profil „ohne Versand“ zu – Null MX oder fehlender MX zusammen mit v=spf1 -all, ohne weiteren SPF-Record –, bewertet er einen eigenen, kleineren Härtungsumfang. Diese Einordnung belegt keinen tatsächlich ausbleibenden Versand: SPF -all, eine reject-Policy ohne Testmodus am eingegebenen Namen und Null MX. Eine übergeordnete Policy zieht er in diesem Fall nicht heran.

Der hier beschriebene Domaincheck enthält keine Nachrichtenprüfung. Maßgeblich für den angebotenen Umfang ist die Seite Was der Check prüft.

Anleitungen nach Anbieter und nächste Kapitel

Vorheriges Kapitel: DMARC: Alignment, Policy und Berichte. Nächstes Kapitel: MTA-STS und TLS-RPT. Passend dazu: SPF, DKIM, ARC und E-Mail-Gateways, BIMI – teilnehmende Anbieter setzen dort unter anderem eine durchgesetzte DMARC-Policy voraus, eine Logoanzeige folgt daraus nicht –, Headerbefunde einordnen und E-Mail-Compliance.