Beginnen Sie mit der Autorität und der Frage
Eine E-Mail-Authentifizierungsbibliothek sollte einem Leser helfen, das richtige Primärdokument auszuwählen, und nicht nur das Sammeln von Links. Protokollregeln, Parameterregister, Anbieteranforderungen und Produktbeobachtungen beantworten unterschiedliche Fragen. Dieser kuratierte Leitfaden dokumentiert Umfang und Status der am 8. November 2026 überprüften Schlüsselquellen. Seine Einträge verfügen über stabile Leseranker; Sie stellen nicht sicher, dass ein Mandant, Empfänger oder EmailAuth Implementierung diesen Quellen entspricht.
Bewahren Sie für jede betriebliche Anforderung die ausstellende Behörde, die Dokumentkennung, das Versions- oder Revisionsdatum, die betroffene Bevölkerung, den verantwortlichen Eigentümer und den Akzeptanznachweis auf. Ein Veröffentlichungsdatum ist nicht automatisch ein Durchsetzungsdatum des Anbieters. Eine funktionierende Bibliothek muss auch gewartet werden: Geänderte Links, neue Updates und ungelöste Quellkonflikte müssen sichtbar sein und dürfen nicht hinter einem alten überprüften Abzeichen verborgen sein.
DMARC Kern RFC 9989
RFC 9989 ist der Kern vom Mai 2026 DMARC Spezifikation, die authentifizierte Identifikatoren umfasst, Ausrichtung, Richtlinienfindung und Bewertungsrichtliniensemantik. Es ist RFC-Editor-Informationsdatensatz identifiziert es als vorgeschlagenen Standard; Das Dokument ist „Standards Track“ und ersetzt die RFCs 7489 und 9091. Verwenden Sie es für aktuelle Kernregeln, während Sie die Unterschiede bei der Legacy-Implementierung separat testen. Die Richtlinienversion bleibt DMARC1 und keine Version, die aus der neuen RFC-Nummer erfunden wurde.
Aggregierte Berichterstattung RFC 9990
RFC 9990 ist die separate Spezifikation für die aggregierte Berichterstattung vom Mai 2026. Der RFC-Editor-Datensatz identifiziert den Status des vorgeschlagenen Standards. Es geht um Berichtsstruktur, Verarbeitung, externe Ziele, Duplikate und Datenschutz-/Sicherheitsaspekte. Es sollte die Akzeptanzfälle eines Berichtsparsers unterstützen und nicht als Beweis dafür angesehen werden, dass jeder Empfänger vollständige Berichte sendet oder dass die Gesamtsummen eines Dashboards korrekt sind.
Fehlermeldung RFC 9991
RFC 9991 ist die Standards Track-Fehlerberichtsspezifikation vom Mai 2026, aktualisiert RFC 6591 und beteiligt sich zusammen mit den beiden anderen Dokumenten an der Ersetzung RFC 7489. Der Schwerpunkt liegt auf nachrichtenspezifischer Diagnose, Berichtsformat, externen Zielen und Datenschutz. Die Leserate der separaten Informationsseite war während dieser Überprüfung begrenzt; der erfolgreich gelesene RFC-Text unterstützt die angegebene Kategorie. Nicht verwechseln Fehlerberichte mit aggregierten Statistiken oder gehen Sie davon aus, dass die Veröffentlichung von ruf Berichte garantiert.
SPF RFC 7208
RFC 7208, veröffentlicht im April 2014 auf dem Standards Track, definiert SPF Identitäten, Auswahl von Richtliniendatensätzen, Auswertung und Ergebnisverarbeitung. Es ist der primäre Ausgangspunkt für die Erklärung von a permerror oder das DNS-Abfrage-Begriffslimit. Lesen Sie den entsprechenden Abschnitt und seine Abhängigkeiten, anstatt SPF auf eine Liste zulässiger IP-Adressen zu reduzieren oder davon auszugehen, dass jeder DNS Vorgang gleich zählt.
DKIM RFC 6376 und Algorithmus-Updates
RFC 6376, veröffentlicht im September 2011 auf dem Standards Track, definiert DKIM Signaturen, Selektoren, Schlüssel und Verifizierung. Lesen Sie die kryptografischen Bestimmungen mit RFC 8301, Januar 2018, und RFC 8463, September 2018. Ersteres verbietet RSA-SHA1 und verschärft die RSA-Schlüsselanforderungen; Letzteres definiert Ed25519 verwenden. Ein älteres Basisdokument bleibt nützlich, ohne dass jede ursprüngliche Algorithmusempfehlung aktuell wird.
SMTP DNS und explizit keine E-Mail
RFC 5321, Oktober 2008, stellt SMTP -Transport- und Zielauflösungsregeln bereit. RFC 1034 Und RFC 1035, November 1987, stellen grundlegende DNS Konzepte und Datensatzstrukturen bereit. Verwenden RFC 2308, März 1998, für die Unterscheidung negativer Antworten und nicht für eine veraltete Verknüpfung zum Negativ-Caching. Bei diesen Referenzen handelt es sich um Ausgangspunkte für spätere Updates, nicht um eine vollständige moderne DNS Implementierungsspezifikation.
RFC 7505, Juni 2015, definiert null MX für eine Domain, die ausdrücklich keine E-Mails akzeptiert. In den Absenderrichtlinien wird davor gewarnt, für beides eine Null-MX-Domäne zu verwenden POST VON oder sichtbar Von Identitäten: Empfänger können diesen Datenverkehr ablehnen. Halten Sie diese Absenderanweisung von SPF und dem Null-Reverse-Pfad von SMTP getrennt. Ein absichtlicher No-Mail-Datensatz ist kein fehlender oder fehlerhafter MX .
Herkunft des Authentifizierungsergebnisses RFC 8601
RFC 8601, Mai 2019, definiert die Header Authentication-Results und seine Vertrauensüberlegungen. Verwenden Sie es, wenn Sie bewerten, wer eine Authentifizierungszusicherung gemacht hat und ob diese Zusicherung innerhalb der vertrauenswürdigen Grenze des empfangenden Systems liegt. Es wandelt weder einen willkürlich aus einer Nachricht kopierten Header in einen authentifizierten Beweis um, noch stellt es eine Posteingangsplatzierung anhand eines Pass-Tokens her.
IANA Parameterregister
Der DMARC -Parameterregistrierung, aktualisiert am 22. Mai 2026 im abgerufenen Datensatz, verbindet Tags mit Referenzen und dem aktiven oder historischen Status. Es markiert pct, rf und ri als historisch und enthält aktive Tags wie np, psd und t. Der DKIM -Parameterregistrierung identifiziert registrierte Signatur-Tags und zugehörige Definitionen. Bei der Registrierung handelt es sich um eine Vokabularreferenz und nicht um einen Beweis dafür, dass eine Bereitstellung einen Parameter korrekt unterstützt.
Status und Umsetzung sind getrennte Nachweise
Ein Internet-Entwurf ist ein Arbeitsdokument und kein veröffentlichter RFC, nur weil er einem ähnelt. RFC 2026 Abschnitt 2.2 erklärt diesen Unterschied; Spätere Prozessaktualisierungen bedeuten, dass die historische Standardleiter nicht als vollständiger aktueller Prozess behandelt werden sollte. Unterscheiden Sie außerdem den Standards Track von informativen, experimentellen und Best-Current-Practice-Dokumenten. Zitieren Sie den tatsächlichen Statusdatensatz, anstatt davon auszugehen, dass jeder nummerierte RFC die gleiche Autorität hat.
Erfassen Sie für eine Anbieterregel Produkt, Route, Cloud-Umgebung, betroffene Absender sowie Ankündigungs- und Durchsetzungstermine separat. Ein Konflikt zwischen offiziellen Seiten gehört in das Anforderungsregister, bis eine anwendbare aktuelle Quelle oder kontrollierte Beobachtung ihn löst. Ein synthetisches Parser-Ergebnis kann die lokale Interpretation testen, aber nicht die Remote-Akzeptanz beweisen.
Der genaue Anforderungskatalog bleibt offen: Ein Anforderungsregister mit Befugnis, Geltungsbereich, Gültigkeitsdatum, Eigentümer und Abnahmenachweis. Die kuratierte Karte unten enthält Quelleneinträge und vorgeschlagene Eigentumsverhältnisse, jedoch keine abgeschlossene organisationsspezifische Annahme. Bei der Aufnahme wird auch nach funktionierender Funktionalität und Tests gefragt. Statische Anker und primäre Links werden bereitgestellt, aber die Akzeptanz, Anwendbarkeit, technische Überprüfung und Veröffentlichungsgenehmigung des funktionierenden Tools steht noch aus.