Dieses Kapitel hilft Ihnen, einen DMARC-Record zu verstehen, Fehler an Nachrichten von DNS-Befunden zu unterscheiden und eine zum Versandbetrieb passende Policy zu wählen.
Was DMARC leistet
Domain-based Message Authentication, Reporting and Conformance ergänzt SPF und DKIM um drei zusammengehörige Aufgaben:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Aufgabe | Bedeutung |
|---|---|
| Alignment | Die erfolgreich authentifizierte Domain wird mit der sichtbaren Absenderdomain verbunden. |
| Policy | Der Domainbetreiber veröffentlicht seine gewünschte Behandlung bei DMARC-Fehlschlägen. Die tatsächliche Behandlung erfolgt beim Empfänger. |
| Reporting | Teilnehmende Empfänger können Berichte über ihre Beobachtungen an angegebene Ziele senden. |
Ohne DMARC kann SPF für eine fremde SMTP-Absenderdomain bestehen und DKIM für eine fremde Signierdomain gültig sein, ohne dass damit die sichtbare From:-Domain bestätigt wird. Beide Prüfungen und andere Filter sind auch ohne DMARC möglich. Es fehlt dann jedoch diese veröffentlichte Verbindung einschließlich der DMARC-Policy und der angeforderten Berichte.
DMARC betrifft die autorisierte Verwendung einer Domain. Es bestätigt keine natürliche Person und keine Berechtigung zu einer Überweisung. Ähnliche Domains, frei gewählte Anzeigenamen, missbrauchte legitime Konten und schädliche Inhalte bleiben andere Probleme. Ein DMARC-Pass ist weder eine allgemeine Sicherheitsbewertung noch eine Zusage für die Zustellung in den Posteingang.
Die aktuelle Grundlage ist RFC 9989, veröffentlicht im Mai 2026 als Proposed Standard. Er ersetzt RFC 7489 und RFC 9091. Aggregate Reports sind in RFC 9990, Failure Reports in RFC 9991 beschrieben. Ältere Anleitungen und Empfänger können noch abweichende Details verwenden.
Alignment: welcher Domainvergleich zählt?
Der Ausgangspunkt ist die Domain im sichtbaren From:-Header, im Standard Author Domain genannt. Verglichen wird sie mit einer erfolgreich authentifizierten Domain:
- Bei SPF zählt die geprüfte
MAIL FROM-Identität. Eine separate HELO-Prüfung genügt nicht. Für einen leeren SMTP-Rückpfad definiert SPF eine Ersatzidentität auspostmasterund der HELO-Domain. - Bei DKIM zählt
d=einer gültigen Signatur. Eine Nachricht kann mehrere DKIM-Signaturen haben; für den DKIM-Pfad genügt eine bestandene und ausgerichtete Signatur.
Return-Path im Header kann die bei der Zustellung festgehaltene SMTP-Rückadresse zeigen. Die SPF-Identität entsteht aber in der SMTP-Transaktion. Ein beliebig vorgefundenes Headerfeld ist kein Ersatz für vertrauenswürdige Empfangsdaten. Der Abschnitt zu Headerbefunden erklärt diese Grenze.
Schematischer Vergleich · keine Messwerte
Gleiche Domain oder gleiche Organisationsdomain
Relaxed Alignment, mit aspf=r beziehungsweise adkim=r, ist der Standardmodus. Es verlangt dieselbe Organisationsdomain. Strict Alignment, mit aspf=s beziehungsweise adkim=s, verlangt identische Domains. Die Organisationsdomain wird nach den DMARC-Regeln bestimmt; sie lässt sich nicht für alle Domains durch Abschneiden auf die letzten zwei Namensteile ermitteln.
Die folgende Tabelle zeigt ausschließlich schematische Domainvergleiche. Für jede SPF-Zeile wird ein tatsächlicher SPF-Pass und für jede DKIM-Zeile eine gültige Signatur vorausgesetzt. Die sichtbare Adresse lautet jeweils From: info@example.com; als Organisationsdomains werden hier example.com und example.net angenommen.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Pfad und authentifizierte Identität | Relaxed | Strict |
|---|---|---|
SPF: MAIL FROM:<bounce@example.com> | Ausgerichtet | Ausgerichtet |
SPF: MAIL FROM:<bounce@sender.example.net> | Nicht ausgerichtet | Nicht ausgerichtet |
DKIM: d=example.com | Ausgerichtet | Ausgerichtet |
DKIM: d=sender.example.net | Nicht ausgerichtet | Nicht ausgerichtet |
SPF: MAIL FROM:<bounce@mail.example.com> | Ausgerichtet | Nicht ausgerichtet |
DKIM: d=mail.example.com | Ausgerichtet | Nicht ausgerichtet |
Bei einer anwendbaren DMARC-Prüfung lässt sich das Pass-Kriterium so ausdrücken:
DMARC PASS = (SPF pass AND SPF aligned) OR (DKIM pass AND DKIM aligned)Das ODER ist entscheidend. Eine Nachricht kann DMARC bestehen, obwohl SPF fehlschlägt, wenn eine gültige DKIM-Signatur ausgerichtet ist. Umgekehrt genügt im allgemeinen Pass-Kriterium ein ausgerichteter SPF-Pass. Das ist von zusätzlichen Betriebsanforderungen bei p=reject zu unterscheiden. RFC 9989, Abschnitte 3.2.4 und 4.4
Bei Weiterleitungen kann SPF an der neuen Verbindungs-IP scheitern. DKIM kann erhalten bleiben, solange die erfassten Nachrichtenteile unter der verwendeten Kanonisierung nicht ungültig verändert werden. ARC kann frühere Prüfergebnisse weiterreichen; Vertrauen in die Zwischenstationen und die Regeln des Empfängers bestimmen den Umgang damit. ARC repariert keine Signatur.
Eine Alias-Strategie trennt Adressen für unterschiedliche Dienste; das ist eine eigenständige Maßnahme. BIMI baut auf weiteren Voraussetzungen einschließlich einer durchgesetzten DMARC-Policy auf. Eine solche Policy allein garantiert keine Logoanzeige; die BIMI Group weist auf zusätzliche Empfängerkriterien hin.
DMARC-Record: aktuelle Tags und historische Parameter
Für example.com wird ein expliziter DMARC-TXT-Record unter _dmarc.example.com gesucht. Die Versionskennung v=DMARC1 muss zuerst stehen. Eine explizite Policy p= ist empfohlen. Fehlt sie in einem ansonsten gültigen Record, gilt nach RFC 9989 p=none. Das folgende Beispiel fordert zusätzlich Aggregate Reports an; die Adresse ist ein Platzhalter und muss für einen tatsächlichen Einsatz eingerichtet sein:
v=DMARC1; p=none; rua=mailto:dmarc@example.comBei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Tag | Werte oder Beispiel | Bedeutung nach RFC 9989 |
|---|---|---|
v | v=DMARC1 | Erforderliche Versionskennung, erster Tag. |
p | none, quarantine, reject | Empfohlene explizite Policy für Fehlschläge. Ohne diesen Tag gilt im sonst gültigen Record none. |
sp | none, quarantine, reject | Policy für bestehende Subdomains bei Anwendung der entsprechenden übergeordneten Policy. Ohne passenden Sonderwert greift p; eine eigene vorrangige Policy ist zu beachten. |
np | none, quarantine, reject | Policy für nicht existierende Subdomains. Ohne np greift das passende sp, sonst p. |
rua | mailto:adresse@example.com | Optionales Ziel für angeforderte Aggregate Reports. Für eine Einführung mit Berichtsauswertung sinnvoll, aber keine Voraussetzung für eine DMARC-Policy. |
ruf | mailto:adresse@example.com | Optionales Ziel für Failure Reports zu einzelnen Fehlerfällen. |
aspf | r oder s | SPF-Alignment: relaxed ist der Standardwert, strict verlangt identische Domains. |
adkim | r oder s | Entsprechender Modus für DKIM-Alignment. |
fo | 0, 1, d, s | Optionen für Failure Reports; ohne ruf zu ignorieren. 0 ist der Standardwert. |
psd | y, n, u | Kennzeichnet die Rolle einer Domain bei der Suche nach Policy und Organisationsdomain. y steht für eine Public Suffix Domain, n für eine Organisationsdomain; u ist der Standard ohne diese Festlegung. |
t | y oder n | Testsignal. Standard n; y fordert für Fehlschläge eine um eine Stufe mildere Policy-Behandlung an. |
Bei fo=0 wird ein Failure Report angefordert, wenn kein Verfahren einen ausgerichteten Pass liefert. fo=1 fordert ihn bereits an, wenn mindestens ein Verfahren keinen ausgerichteten Pass liefert – auch wenn die Nachricht über den anderen Pfad DMARC besteht. fo=d beziehungsweise fo=s betrifft DKIM- beziehungsweise SPF-Fehler unabhängig vom Alignment. Mehrere zulässige Werte werden mit Doppelpunkt getrennt; 0 und 1 dürfen nicht gemeinsam verwendet werden. Empfänger müssen nicht jede Berichtsanforderung erfüllen.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Historischer Tag | Frühere Bedeutung | Heutige Grenze |
|---|---|---|
pct | Anteil von 0 bis 100 für die damalige Policy-Anwendung | In RFC 9989 entfernt beziehungsweise als historisch registriert. Bei Empfängern nach diesem Standard begrenzt pct die Policy nicht. |
rf | Formatwahl für Failure Reports | In RFC 9989 entfernt; maßgeblich ist die Beschreibung in RFC 9991. |
ri | Gewünschtes Berichtsintervall in Sekunden | In RFC 9989 entfernt; kein verlässlicher Zeitplan für aktuelle Berichte. |
t=y ersetzt keinen universellen Rollback-Schalter. Nach dem neuen Standard wird reject dabei wie quarantine und quarantine wie none behandelt; none bleibt unverändert. Die Berichterzeugung wird dadurch nicht abgeschaltet. Ältere Empfänger können den Tag ignorieren, und DNS-Caches können Änderungen verzögern. Die Definitionen stehen in RFC 9989, Abschnitt 4.7 und Anhang C.5.
Die drei Policy-Werte
p=none: beobachten, ohne besondere DMARC-Behandlung anzufordern. Andere Filter können Nachrichten weiterhin ablehnen oder als Spam behandeln. Mit einem geeigneten rua-Ziel können Sie Berichte anfordern.
p=quarantine: Fehlschläge als verdächtig einstufen. Das kann beim Empfänger etwa eine Quarantäne oder einen Spamordner bedeuten. Ein bestimmter Ordner oder ein bestimmter Zugang zur Nachricht ist damit nicht garantiert.
p=reject: Ablehnung anfordern. Das kann auch legitime indirekte Versandwege treffen. Es ist kein universelles Ziel für jede Domain. RFC 9989 rät für Domains mit allgemeiner E-Mail-Nutzung und möglichen Mailinglistenbeiträgen von dieser Policy ab.
Domain ohne Versand und Empfang
Eine Domain, die weder sendet noch empfängt, ist ein anderer Anwendungsfall als eine Domain mit Benutzerpostfächern. Das folgende schematische Zonenbeispiel dokumentiert diesen beabsichtigten Nichtgebrauch:
_dmarc.parked.example. TXT "v=DMARC1; p=reject; sp=reject"
parked.example. TXT "v=spf1 -all"
parked.example. MX 0 .Die abschließenden Punkte kennzeichnen hier vollständige DNS-Namen. DNS-Oberflächen können andere Eingabeformen erwarten. Das Beispiel wurde nicht veröffentlicht oder praktisch getestet.
Aggregate Reports und Failure Reports unterscheiden
Aggregate Reports: welche Versandmuster Empfänger beobachten
Aggregate Reports nach RFC 9990 fassen die Beobachtungen eines berichtenden Empfängers für einen Zeitraum in XML zusammen. Häufig umfasst dieser Zeitraum einen Tag. Enthalten sind unter anderem Quell-IPs, Nachrichtenanzahlen, veröffentlichte Policy, Authentifizierung, Alignment und Behandlung. rua= nennt die gewünschten Empfänger dieser Berichte.
Das folgende XML ist ein erfundenes, unvollständiges Anschauungsbeispiel mit zwei Gruppen, kein empfangener Bericht und keine vollständige gültige Berichtdatei. Unter anderem fehlen Berichtsmetadaten, Zeitraum, veröffentlichte Policy und weitere Record-Felder.
<record>
<row>
<source_ip>203.0.113.1</source_ip>
<count>1524</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
<record>
<row>
<source_ip>198.51.100.42</source_ip>
<count>3</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>Die erste Gruppe zeigt im Modell 1524 Nachrichten mit bestandenen, ausgerichteten Prüfpfaden. Das ist kein Urteil, dass diese Nachrichten inhaltlich legitim oder harmlos wären. Die zweite Gruppe zeigt drei Fehlschläge; das können missbräuchliche Nachrichten, ein vergessener legitimer Dienst oder ein indirekter Versandweg sein. disposition=none weist hier keine besondere DMARC-Policy-Maßnahme aus; es belegt weder die Ablage im Posteingang noch die Zustimmung des Empfängers zum Inhalt.
Prüfen Sie bei echten Berichten stets Quelle, Zeitraum, berichtete Policy, Anzahl und mögliche Policy-Ausnahmen gemeinsam. Separate Rohresultate unter auth_results sind von den für DMARC ausgewerteten Angaben unter policy_evaluated zu unterscheiden. Berichte decken nur meldende Empfänger und deren Beobachtungen ab. Fehlende Berichte beweisen deshalb weder fehlenden Versand noch fehlerfreie Authentifizierung. RFC 9990, Abschnitt 3.1
Externe Berichtsziele benötigen eine Autorisierung
Liegt das Berichtsziel außerhalb der betreffenden Organisationsdomain, sieht DMARC eine DNS-Autorisierung auf der Seite des Berichtsempfängers vor. Maßgeblich ist dabei auch die Domain, von der die Policy tatsächlich stammt; sie muss bei geerbten Policies nicht die sichtbare Absenderdomain sein. Eine fremde Adresse in rua einzutragen, genügt nicht für ein zulässiges externes Berichtsziel im Protokoll. Der Ablauf ist in RFC 9990, Abschnitt 4 beschrieben und wird für ruf entsprechend verwendet.
Failure Reports: gezielte Diagnose mit mehr Inhalt
Failure Reports nach RFC 9991, häufig auch Forensic Reports genannt, können Details einzelner Fehlerfälle enthalten. Je nach Bericht können dazu Headerfelder, Adressen und Nachrichteninhalte gehören. Sie sind keine vollständige Rohmailarchivierung und werden nicht von allen Empfängern bereitgestellt.
Auch Aggregate Reports enthalten Betriebsdaten und müssen zum gewählten Verarbeitungszweck passen. Aus der technischen Möglichkeit zum Reporting folgt keine pauschale rechtliche Erlaubnis und kein pauschales Verbot.
Welches Werkzeug beantwortet welche Frage?
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Werkzeugart und vorhandenes Beispiel | Aufgabe | Grenze |
|---|---|---|
| XML-Auswertung, etwa dmarcian | Vorliegende Aggregate Reports lesbar auswerten. | Benötigt die entsprechenden Berichte; keine vollständige Sicht auf alle Empfänger. |
| Berichtsübersichten, etwa Postmark DMARC | Eingehende Berichte zusammenfassen. | Angezeigte Zusammenfassungen sind von Einzelbelegen und Produktumfang abhängig. |
| Google Postmaster Tools | Anbieterbezogene Angaben zu Authentifizierung, Reputation und Fehlern. | Betrifft Versand an persönliche Gmail-Konten; bei zu geringem Volumen können Daten fehlen. |
| Wolf-Agents E-Mail Security Check | Öffentlich erreichbare DNS-Konfiguration untersuchen. | Nimmt hier keine DMARC-XML-Berichte oder echten Nachrichten zur Prüfung entgegen. |
Die Beispiele beschreiben verschiedene Aufgaben. Eine DNS-Momentaufnahme ist kein DMARC-Berichtsarchiv, und ein DMARC-Aggregatbericht ist kein von Wolf-Agents erstellter Domainreport.
Eine Policy nach dem tatsächlichen Versandbetrieb einführen
Klären Sie zuerst Ihren Versandbetrieb: Welche Dienste dürfen senden? Welche Domains verwenden sie tatsächlich in MAIL FROM, d= und From:? Welche Weiterleitungen und Mailinglisten sind relevant? Erst daraus ergibt sich, welche Policy zum Betrieb passt.
Betriebliche Entscheidungen · keine automatische Verschärfung
Die Policy anhand der Versandwege wählen
Beobachten und Versandwege zuordnen
Schritt 1 · Beispielrecord mit p=nonev=DMARC1; p=none; rua=mailto:dmarc@example.comRichten Sie die vorgesehene Berichtsadresse ein und ordnen Sie die beobachteten Quellen Ihren Anwendungen zu. Konfigurieren und prüfen Sie SPF und DKIM für legitime Dienste; das ist eine betriebliche Empfehlung, keine Änderung des allgemeinen ODER-Kriteriums für eine Nachricht. Berücksichtigen Sie alle relevanten Versandzyklen, auch seltene Aussendungen. Eine bestimmte Pass-Quote oder eine allgemein festgelegte Zahl von Wochen ersetzt diese Untersuchung nicht.
Auswirkungen von
quarantineuntersuchenSchritt 2 · Beispielrecord mit p=quarantinev=DMARC1; p=quarantine; rua=mailto:dmarc@example.comWenn die bisherige Prüfung eine Verschärfung trägt, beobachten Sie nach der Änderung Berichte und Rückmeldungen betroffener Empfänger. Untersuchen Sie verbleibende Fehlschläge. Ein DNS-Record allein zeigt nicht, ob jede legitime Anwendung weiter korrekt versendet.
rejectnur bei passendem Einsatz entscheidenSchritt 3 · Beispielrecord mit p=rejectv=DMARC1; p=reject; rua=mailto:dmarc@example.comFür geeignete Domains kann diese Policy nach der Untersuchung aller relevanten Wege sinnvoll sein. Domains mit
p=rejectdürfen sich nach RFC 9989 nicht allein auf SPF für einen DMARC-Pass verlassen und müssen ihre Nachrichten mit gültigen DKIM-Signaturen versehen. Für den DKIM-Pfad zu DMARC muss eine bestandene Signatur zusätzlich ausgerichtet sein.Für Domains mit Benutzern, die an Internet-Mailinglisten teilnehmen könnten, rät RFC 9989 Abschnitt 7.4 von
p=rejectab. Wird es in diesem Fall trotzdem erwogen, empfiehlt der RFC zunächst mindestens einen Monatp=none, anschließend einen ebenso langen Zeitraump=quarantineund einen Vergleich der Auswirkungen. Diese auf den genannten Fall bezogene Empfehlung ist keine allgemeine Freigabe nach Ablauf von zwei Monaten. Relevante seltene Versandwege und verbleibende Probleme müssen weiterhin geklärt sein.Gewählte Policy und Versandwege weiter pflegen
Schritt 4 · Beispielrecord der gewählten Dauerpolicyv=DMARC1; p=quarantine; rua=mailto:dmarc@example.comDies ist das Beispiel einer bewusst gewählten Dauerpolicy, kein vorgeschriebener Rückschritt nach
reject. Neue Versanddienste, geänderte Domains und Schlüsselwechsel müssen erneut eingeordnet werden. Relaxed und strict sind beide standardkonform; strict ist kein universelles Abschlussziel. Planen Sie bei Änderungen auch die Rücknahme und ihre DNS-Cachegrenzen. Die Enforcement-Anleitung vertieft Berichte, Subdomains und Rollback.
Häufige DMARC-Fehler eingrenzen
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Befund | Was Sie prüfen sollten |
|---|---|
Kein rua | Es werden keine Aggregate Reports angefordert. Die Policy und die Nachrichtenprüfung werden dadurch nicht aufgehoben. Für fehlende Berichte auch Erreichbarkeit und gegebenenfalls externe Autorisierung prüfen. |
Direkt auf p=reject gewechselt | Legitime Drittanbieter oder indirekte Versandwege können scheitern. Untersuchen Sie betroffene Nachrichten, Berichte und die verwendeten Identitäten. |
| Subdomain-Policy falsch eingeschätzt | Ohne sp kann p der ermittelten Organisationsdomain greifen, soweit keine eigene vorrangige Policy oder ein passendes np greift. Fehlendes sp=reject ist bei p=reject nicht allein eine weitere Lücke. |
| Mehrere DMARC-Records am selben Namen | Die Records an diesem Abfragepunkt werden nach RFC 9989 verworfen; die Policy-Suche kann weitergehen. Das Verhalten ist definiert, aber der beabsichtigte Record fällt aus. Teilstrings innerhalb eines einzigen TXT-Records sind keine mehreren Records. |
| SPF oder DKIM besteht, DMARC nicht | Prüfen Sie zusätzlich das Alignment. Eine eigene Bounce-Domain für SPF oder Custom-DKIM mit ausgerichtetem d= kann helfen, wenn der Dienst den jeweiligen Weg unterstützt. Ein bloßer Authentifizierungs-Pass für eine nicht ausgerichtete Domain reicht nicht. |
Record unter dmarc.example.com statt _dmarc.example.com | Der Unterstrich gehört zum Namen. Unterscheiden Sie den fehlenden expliziten Record von DNS-Zeitüberschreitungen; außerdem kann eine geerbte Policy greifen. |
Für die Suche nach Policy und Organisationsdomain ist RFC 9989, Abschnitt 4.10 maßgeblich. Eine Subdomain-Policy verhindert nicht den Missbrauch eines bereits legitim autorisierten oder kompromittierten Versanddienstes.
Der E-Mail Security Check kann die öffentlich abfragbare Konfiguration als Momentaufnahme zeigen. Für eine erste DNS-Frage kann das genügen. Er bestätigt damit keine echte Nachricht, keine vollständige Senderliste, keine Reportzustellung und keine einheitliche Umsetzung des neuen Standards bei allen Empfängern.
Technische und rechtliche Aussagegrenzen
Dokumentieren Sie die gewählte Policy, ihre Begründung, die betrachteten Versandwege und die Zuständigkeit für Berichte. Ein DMARC-Record oder eine hohe Pass-Quote belegt keine umfassende Sicherheit oder Compliance.
Die folgenden rechtlichen Bezüge betreffen Deutschland und die EU:
- § 30 BSIG verlangt für erfasste Einrichtungen angemessene und verhältnismäßige Risikomanagementmaßnahmen, nicht pauschal eine bestimmte DMARC-Policy für jede Domain.
- BSI TR-03182 behandelt E-Mail-Authentifizierung; TR-03108 ergänzt den Transportbereich. Ein DNS-Check ersetzt keine Prüfung einer ganzen Richtlinie und ihrer Betriebsanforderungen.
- Artikel 32 DSGVO betrifft risikogerechte technische und organisatorische Maßnahmen. DMARC verschlüsselt keine Kommunikation. Bei Berichten sind Zweck, enthaltene Daten, Empfänger und Zugriff gesondert zu beurteilen.
Anleitung für Ihren Versanddienst
Nutzen Sie die vorhandene Anleitung für Ihren tatsächlichen Dienst. Die DMARC-Policy wird per DNS veröffentlicht; die für einen Pass benötigten Identitäten und Signaturen müssen außerdem zum jeweiligen Versandweg passen.
Häufige Fragen
Was ist DMARC und wozu brauche ich es?
DMARC verbindet die sichtbare Absenderdomain mit einem erfolgreichen und ausgerichteten SPF- oder DKIM-Prüfpfad. Es ergänzt eine veröffentlichte Policy für Fehlschläge und optionale Berichte. Seit Mai 2026 ist RFC 9989 die maßgebliche DMARC-Spezifikation; RFC 9990 und RFC 9991 regeln die Berichte. Die tatsächliche Behandlung einer Nachricht bleibt beim Empfänger.
Was ist DMARC-Alignment?
Alignment vergleicht die authentifizierte SMTP-MAIL FROM-Domain oder d= einer gültigen DKIM-Signatur mit der sichtbaren From:-Domain. Relaxed verlangt dieselbe Organisationsdomain, strict identische Domains. Ein erfolgreicher und ausgerichteter Pfad genügt für das allgemeine DMARC-Pass-Kriterium; ein DNS-Record allein beweist ihn nicht.
Worin unterscheiden sich none, quarantine und reject?
p=none fordert keine besondere Behandlung von DMARC-Fehlschlägen an, p=quarantine ihre Behandlung als verdächtig und p=reject ihre Ablehnung. Andere Filter und die Regeln des Empfängers bleiben relevant. Ein bestimmter Ordner oder eine bestimmte Zustellung ist nicht garantiert.
Wie lange sollte ich p=none verwenden?
Bis die relevanten Versandzyklen, Dienste und indirekten Wege ausreichend untersucht sind. Es gibt keine allgemeine Pass-Quote oder Wochenfrist für alle Domains. Für mögliche Mailinglistennutzung rät RFC 9989 von p=reject ab und nennt bei dennoch erwogener Einführung gesonderte Beobachtungszeiträume. Diese sind kein Ersatz für die Untersuchung Ihres Betriebs.
Was sind DMARC Aggregate Reports?
Es sind XML-Zusammenfassungen berichtender Empfänger für einen angegebenen Zeitraum. Sie können Quell-IPs, Anzahl, Authentifizierung, Alignment und Behandlung enthalten. rua fordert sie an. Sie sind kein vollständiges Versandprotokoll und kein Wolf-Agents-Domainreport; der DNS-Check nimmt diese XML-Dateien nicht zur Auswertung entgegen.
Wie funktioniert DMARC mit Drittanbietern?
Untersuchen Sie jeden tatsächlichen Versandweg. Ein SPF-Pass mit ausgerichteter MAIL FROM-Domain oder eine gültige DKIM-Signatur mit ausgerichtetem d= kann das Pass-Kriterium erfüllen. Eine eigene Bounce-Domain oder Custom-DKIM kann dies ermöglichen. Weiterleitungen können die Ergebnisse verändern; DNS allein bestätigt den Nachrichtenpfad nicht.
Brauche ich SPF und DKIM, bevor ich DMARC veröffentliche?
Für das allgemeine Pass-Kriterium einer Nachricht reicht einer der beiden erfolgreichen, ausgerichteten Pfade. Beide passend einzurichten kann die Robustheit verbessern. Bei p=reject verlangt RFC 9989 zusätzlich gültige DKIM-Signaturen und verbietet das alleinige Verlassen auf SPF. Eine nicht sendende Domain kann dagegen eine DMARC-Policy ohne aktive DKIM-Signierung veröffentlichen. Prüfen Sie reale Versandwege, bevor Sie die Policy einer sendenden Domain verschärfen.
Quellen und Anschluss
Quellenstand: 12. September 2026. Die Statusseite zu RFC 9989, RFC 9990 und RFC 9991 sowie ihre Errata wurden gezielt geprüft. Das verifizierte Erratum 9150 zu RFC 9989 korrigiert den Verweis für die Autorisierung externer Berichtsziele auf Abschnitt 4 von RFC 9990. Ein nur gemeldetes Erratum ist keine bereits angenommene Änderung des Standards.
Vorheriges Kapitel: DKIM. Nächstes Kapitel: DMARC-Enforcement. Für den Zusammenhang: E-Mail-Sicherheit im Überblick.