DMARCbis ändert, wie Teile von DMARC werden spezifiziert und umgesetzt. Sie werden nicht aufgefordert, Ihren Datensatz in DMARC2 umzubenennen. Die Kernspezifikation, RFC 9989, wurde im Mai 2026 veröffentlicht, während RFC 9990 Und RFC 9991 decken aggregierte Berichte und Fehlerberichte getrennt ab.
Die praktische Aufgabe besteht darin, herauszufinden, welche Änderungen Ihre Domain, Ihre Versanddienste und die Software, die Ihre Authentifizierungsdaten verarbeitet, betreffen. Das beginnt damit, die aktuellen Spezifikationen zu verstehen und sie dann mit der Konfiguration und den bereits verwendeten Prozessen zu vergleichen. Das Ergebnis sollte ein übersichtliches Bereitschaftsregister mit Beweisen, Eigentümern und einer Entscheidung für jeden Befund sein.
Ordnen Sie die drei Spezifikationen Ihren Systemen zu
Nutzen Sie die aktuellen Dokumente für Ihre jeweiligen Aufgaben:
| Dokumentieren | Was Sie überprüfen sollten |
|---|---|
| RFC 9989 | Kern- DMARC Bewertung, Richtlinienfindung, Ausrichtung und Datensatzsemantik |
| RFC 9990 | Aggregiertes Berichtsformat, Generierung und Verarbeitung |
| RFC 9991 | Fehlerberichte und Überlegungen zur Handhabung |
Beginnen Sie mit dem vorhandenen Datensatz und Konfigurationsverlauf. Löschen Sie einen Betriebsdatensatz nicht, nur weil ein älterer Leitfaden darauf verweist RFC 7489. Identifizieren Sie die geänderten Anweisungen und die Software, die sie umsetzt.
Zu den Hauptprüfungsbereichen gehören die folgenden:
- Domänenerkennung: RFC 9989 Abschnitt 4.10 definiert DNS Tree-Walking. Überprüfen Sie Systeme, die ein älteres Erkennungsmodell mit öffentlicher Suffixliste annehmen.
- Richtlinien-Tags: Überprüfen Sie die aktuelle IANA Registrierung. Der
pct,rfUndriTags sind historisch. Bewertent,npUndpsdnach ihrem tatsächlichen Umfang, anstatt sie als Upgrade-Checkliste hinzuzufügen. - Testen: Stellen Sie fest, wie der relevante Evaluator die Binärdatei implementiert
tSignal. Ein erklärter Testzustand und die endgültige Verfügung eines Empfängers sind unterschiedliche Beobachtungen. - Berichterstattung: Stellen Sie sicher, dass Collectors und Parser die von Ihnen erwarteten Berichtsformate und Felder verarbeiten, ohne dass relevante Legacy-Beobachtungen verloren gehen.
Die Versionsmarkierung bleibt erhalten v=DMARC1. Nicht ersetzen DMARC2 oder einen alten Prozentsatz mechanisch durch eine Testflagge ersetzen.
Übersetzen Sie die geänderten Tags in Tests
Der t Flag ist standardmäßig auf nund beantragt die Anwendung der erklärten Bewertung auf DMARC Fehler. Einstellung t=y signalisiert, dass der Eigentümer prüft, anstatt die direkte Anwendung der deklarierten Bewertung zu verlangen. RFC 9989 Abschnitt 4.7 Definiert eine Reduzierung um eine Ebene für fehlerhafte Nachrichten: „Ablehnen“ wird zu „Quarantäne“ und „Quarantäne“ wird zu „Keine“. Implementierungen können auch eine entsprechende Sonderbehandlung haben.
Das Flag ändert das Ergebnis einer fehlgeschlagenen Authentifizierung nicht in ein „Pass“-Ergebnis, verändert die Berichtserstellung nicht und wirkt sich auch nicht auf eine „Keine“-Richtlinie aus. Es ist binär und keine Anforderung, einen beliebigen Prozentsatz der E-Mails abzufragen. Richten Sie Implementierungsunterstützung ein, bevor Sie sich bei echtem Datenverkehr darauf verlassen, und halten Sie die lokale Filterung des Empfängers vom Testergebnis auf Richtlinienebene getrennt.
Zwei weitere Tags beeinflussen den Umfang der Bewertung:
- NP: Gibt die Bewertung für nicht vorhandene Subdomänen der vorherrschenden an Organisationsbereich. Wenn nicht vorhanden, ist der anwendbare Fallback sp, wenn vorhanden, andernfalls p. Ein Vermisster MX Eintrag allein begründet nicht die Nichtexistenz.
- psd: Markiert Domänengrenzeninformationen, die während der Erkennung verwendet werden. Das Standard-u überlässt die Grenzbestimmung den Erkennungsregeln; y identifiziert ein öffentliches Suffix, während n eine nicht-öffentliche Suffix-Organisationsgrenze für sich selbst und seine Unterdomänen identifiziert. Legen Sie keinen expliziten Grenzwert fest, ohne sicherzustellen, dass er die Domäne korrekt beschreibt.
Eine gewöhnliche Organisation sollte ihre Domäne nicht als öffentliches Suffix kennzeichnen, nur um zu behaupten, dass sie bereit sei. Überprüfen Sie die tatsächlichen Erkennungsannahmen und delegierten Namespaces. Der Richtlinienleitfaden für Subdomains deckt die engere Vererbungsfrage ab.
Identifizieren Sie die E-Mails, die weiterhin funktionieren müssen
Eine Domain kann viel mehr darstellen als die E-Mail-Adresse eines Mitarbeiters. Es kann auf Rechnungen, Anmeldelinks, Kundenbenachrichtigungen und von externen Agenturen gesendeten Nachrichten erscheinen. Ein Standard-Update ist eine Gelegenheit, diese Abhängigkeiten zu überprüfen, bevor eine überstürzte Konfigurationsänderung sie stört.
Bitten Sie um drei Ergebnisse: eine Bestandsaufnahme der Dienste, die Ihre Identität nutzen, eine Erläuterung der spezifischen Änderungen, die Sie betreffen, und einen Testplan für kritische Nachrichten. Die Antwort sollte eine veröffentlichte Spezifikation von einer Funktion unterscheiden, die bereits von einem bestimmten Empfänger oder Softwaredienst bereitgestellt wurde.
Weisen Sie Eigentum und Budget zu. Eine Änderung der Berichtsverarbeitung erfordert jemanden, der für die Berichtspipeline verantwortlich ist. Ein Absender, der sich nicht korrekt authentifizieren kann, muss seinen Geschäftsinhaber einbeziehen. Die Bezeichnung beider Elemente als DNS Upgrade verbirgt die Arbeit.
Erstellen Sie ein Bereitschaftsregister
Das Folgende ist ein beispielhaftes Planungsregister, keine Bewertung einer realen Domäne:
| Finden | Arbeit erforderlich | Nachweis der Fertigstellung |
|---|---|---|
| Bei den Rollout-Anweisungen wird von einer prozentualen Stichprobe ausgegangen | Testen Sie das Binär-Flag mit den unten aufgeführten gesteuerten Vorrichtungen | Protokollierte deklarierte Beurteilung, Beurteilung nach der Prüfflagge und unabhängige Empfängerentscheidung |
| Der Berichtsparser geht von einem Legacy-Schema aus | Überprüfen Sie akzeptierte Formate, Felder und Fehlerbehandlung | Versionierte gültige, veraltete und fehlerhafte Fixtures |
| Für die kritische Anwendung ist kein Besitzer bekannt | Richten Sie den Geschäftsdienst und die unterstützten Identitäten ein | Benannter Eigentümer und verifiziertes Beispiel für empfangene Nachrichten |
| Der DNS Editor wird von einem ausgelagerten Team gesteuert | Vereinbaren Sie die Genehmigungs- und Wiederherstellungsverantwortung | Genaue Änderungsvorschau, Genehmigung und Wiederherstellungsmaterial |
Die folgenden synthetischen Vorrichtungen geben die erwarteten Ergebnisse für einen kontrollierten Evaluator an, RFC 9989 implementiert. Dabei handelt es sich um Testeingaben, nicht um Produktionsdatensatzvorlagen oder bereits durchgeführte Tests. Gehen Sie davon aus, dass eine gültige anwendbare Richtlinie erkannt wird und die Testnachricht DMARC nicht besteht.
| Vorrichtung | Eingang | Erwartete Beobachtung auf politischer Ebene |
|---|---|---|
| Testflagge | p=reject; t=y | Die Validierung ist weiterhin fehlgeschlagen. Die Bewertung nach t=y ist Quarantäne und nicht die erklärte Ablehnung |
| Flagge auf Null | p=none; t=y | Das Flag lässt das Keine-Bewertungs- und Berichtserstellungsverhalten unverändert |
| Nicht existierendes Kind | Eine vorherrschende Organisationsdomänenrichtlinie hat p=none; sp=quarantine; np=reject, mit Standard t=n; Es wird festgestellt, dass das Kind nicht existiert und keine direkte Richtlinie besteht | Die anwendbare untergeordnete Bewertung ist „Ablehnen“ und nicht der sp-Wert des vorhandenen untergeordneten Elements |
Erfassen Sie die Evaluatorversion, die Eingabe, die beobachtete Validierung, die ausgewählte Bewertung und alle abschließenden Bearbeitungen separat. Eine kontrollierte Vorrichtung stellt das getestete Verhalten her; es beweist nicht, dass jeder Internetempfänger die gleichen Regeln anwendet. Eine Quarantänebeobachtung auf Richtlinienebene ist kein allgemeingültiges Versprechen für die Platzierung im Spam-Ordner.
Überprüfen Sie auch die Eignung der Richtlinien. RFC 9989 Abschnitt 7.4 rät von der Ablehnung für allgemeine E-Mail-Domänen ab, da legitime indirekte Routen, einschließlich Mailinglisten, unterbrochen werden können. Eine Bereitschaftsprüfung sollte diese Routen identifizieren und die geltenden Interoperabilitätsleitlinien bewerten, bevor strengere Richtlinien vorgeschlagen werden.
Halten Sie Konfigurationsänderungen getrennt von Software- oder Prozessänderungen. Für einige Ergebnisse ist keine sofortige DNS Bearbeitung erforderlich. Andere erfordern ein Provider-Update, einen Parser-Fix oder einen kontrollierten Implementierungstest.
Überprüfen Sie die Interoperabilität und die Grenzen eines Bereitschaftsanspruchs
Ein Bereitschaftsanspruch sollte seinen Umfang benennen. Deckt es das Domänenportfolio, den Richtlinienauswerter, den Berichtsprozessor oder nur ab? ein Rekord überprüfen? Das sind unterschiedliche Einschätzungen.
Verwenden Sie das Register, um Implementierungsversionen und ungelöste Unterschiede zu verfolgen. Wählen Sie anwendbare Fälle aus vorhandenen und nicht vorhandenen Subdomains, Ausrichtungsmodi, indirekter E-Mail und DNS Fehlern aus.
Behandeln Sie die Diskretion des Empfängers als Teil des Betriebsmodells. Die Veröffentlichung einer Spezifikation führt nicht dazu, dass sich jeder Empfänger gleich verhält. Eine veröffentlichte Ablehnungspräferenz ist auch kein Beweis dafür, dass jeder Empfänger jede fehlgeschlagene Nachricht abgelehnt hat.
Behalten Sie unabhängige Kontrollen für kompromittierte Konten, irreführende Anzeigenamen, ähnliche Domänen und vertrauliche Geschäftsgenehmigungen bei. DMARC Bereitschaft macht die Domänenauthentifizierung nicht zu einem Urteil über die Sicherheit des Inhalts einer Nachricht.
Nehmen Sie die erforderlichen Änderungen vor und überprüfen Sie sie
Bewahren Sie vor einer Produktionsänderung den vorherigen Zustand, identifizieren Sie betroffene Abläufe, holen Sie die entsprechende Genehmigung ein und definieren Sie Wiederherstellungsbedingungen. Überprüfen Sie dann sowohl die veröffentlichte Konfiguration als auch die repräsentativen Nachrichten über die gesamte Senderoute.
Wenn ein Ergebnis nicht mit dem erwarteten Verhalten übereinstimmt, pausieren Sie die Erweiterung auf andere Domänen und beheben Sie den Kompatibilitätsbefund oder akzeptieren Sie ihn ausdrücklich.
Verwenden Sie für die zugrunde liegenden Identitäten die Leitfaden zur Ausrichtungsdiagnose. Folgen Sie für eine Erstkonfiguration der DMARC Erstellungs- und Verifizierungsworkflow. Verwenden Sie für die Berichtsebene die exemplarische Vorgehensweise für den aggregierten Bericht.
Der praktische Imbiss
Schließen Sie die Bewertung ab, wenn für jeden zutreffenden Befund ein Eigentümer, eine unterstützte Entscheidung und reproduzierbare Beweise vorliegen. Halten Sie ungelöste Implementierungsunterschiede sichtbar, überprüfen Sie kritische Nachrichten und Berichtsverarbeitung und behalten Sie die genehmigten Wiederherstellungsbedingungen bei. Ein Bereitschaftsetikett sollte auf diesen Datensatz verweisen und ihn nicht ersetzen.