Börja med myndigheten och frågan
Ett bibliotek för e-postautentisering bör hjälpa en läsare att välja rätt primära dokument, inte bara samla in länkar. Protokollregler, parameterregister, leverantörskrav och produktobservationer svarar på olika frågor. Den här utvalda guiden registrerar omfattningen och statusen för nyckelkällor som granskades den 8 november 2026. Dess inlägg har stabila läsarankare; de fastställer inte att en hyresgäst, mottagare eller EmailAuth implementering överensstämmer med dessa källor.
För varje operativt krav, behåll utfärdande myndighet, dokumentidentifierare, version eller revisionsdatum, berörda population, ansvarig ägare och godkännandebevis. Ett publiceringsdatum är inte automatiskt ett verkställighetsdatum för leverantören. Ett fungerande bibliotek behöver också underhåll: ändrade länkar, nya uppdateringar och olösta källkonflikter måste vara synliga snarare än gömda bakom ett gammalt granskat märke.
DMARC kärna RFC 9989
RFC 9989 är maj 2026-kärnan DMARC specifikation, som täcker autentiserade identifierare, inriktning, policy upptäckt och bedömning-policy semantik. Dess RFC Editor informationspost identifierar den som föreslagen standard; Dokumentet är Standards Track och är föråldrat RFC 7489 och 9091. Använd det för aktuella kärnregler, samtidigt som du separat testar äldre implementeringsskillnader. Policyversionen förblir DMARC1 , inte en version som uppfunnits från det nya RFC-numret.
Samlad rapportering RFC 9990
RFC 9990 är den separata sammanlagda rapporteringsspecifikationen för maj 2026. De RFC Editor-post identifierar föreslagen standardstatus. Den tar upp rapportstruktur, bearbetning, externa destinationer, dubbletter och integritets-/säkerhetsöverväganden. Det bör stödja en rapportparsers acceptansfall, inte behandlas som bevis på att varje mottagare skickar fullständiga rapporter eller att en instrumentpanels totalsummor är korrekta.
Felrapportering RFC 9991
RFC 9991 är maj 2026 Standards Track felrapporteringsspecifikation, uppdaterar RFC 6591 och deltar med de andra två dokumenten för att ersätta RFC 7489. Dess fokus är meddelandespecifik diagnostik, rapporteringsformat, externa destinationer och integritet. Den separata informationssidan som lästes var hastighetsbegränsad under denna recension; den framgångsrikt lästa RFC-texten stöder den angivna kategorin. Förvirra inte felrapporter med samlad statistik eller anta att publicering av ruf garanterar rapporter.
SPF RFC 7208
RFC 7208, publicerad i april 2014 på Standards Track, definierar SPF identiteter, policyval, utvärdering och resultathantering. Det är den primära utgångspunkten för att förklara en permerror eller gränsen för DNS-frågeperioder. Läs det relevanta avsnittet och dess beroenden istället för att reducera SPF till en lista över tillåtna IP-adresser eller anta att varje DNS operation räknas likadant.
DKIM RFC 6376 och algoritmuppdateringar
RFC 6376, publicerad i september 2011 på Standards Track, definierar DKIM signaturer, väljare, nycklar och verifiering. Läs dess kryptografiska bestämmelser med RFC 8301, januari 2018, och RFC 8463, september 2018. Det förstnämnda förbjuder RSA-SHA1 och stärker RSA-nyckelkraven; den senare definierar Ed25519 använda. Ett äldre basdokument förblir användbart utan att göra alla ursprungliga algoritmrekommendationer aktuella.
SMTP DNS och explicit ingen e-post
RFC 5321, oktober 2008, tillhandahåller regler SMTP -transport och målupplösning. RFC 1034 och RFC 1035, november 1987, tillhandahåller grundläggande DNS koncept och poststruktur. Använda RFC 2308, mars 1998, för distinktioner av negativa svar snarare än en föråldrad negativ-caching-genväg. Dessa referenser är startpunkter med senare uppdateringar, inte en komplett modern DNS implementeringsspecifikation.
RFC 7505, juni 2015, definierar null MX för en domän som uttryckligen inte accepterar e-post. Dess avsändarvägledning varnar för att använda en noll-MX-domän för någondera MAIL FRÅN eller synlig Från identiteter: mottagare kan vägra den trafiken. Håll den avsändarvägledningen åtskild från SPF och från SMTP :s null-omvända sökväg. En avsiktlig post utan e-post är inte en saknad eller felaktig MX .
Autentiseringsresultat härkomst RFC 8601
RFC 8601, maj 2019, definierar Authentication-Results header och dess förtroendehänsyn. Använd den när du utvärderar vem som gjorde ett autentiseringspåstående och om det påståendet hör hemma inom det mottagande systemets betrodda gräns. Den förvandlar inte en godtycklig rubrik som kopierats från ett meddelande till autentiserade bevis, och den etablerar inte heller placering i inkorgen från ett pass-token.
IANA parameterregister
De DMARC -parameterregistret, uppdaterad 22 maj 2026 i den hämtade posten, kopplar taggar till referenser och aktiv eller historisk status. Den markerar pct, rf och ri historiska och inkluderar aktiva taggar som np, psd och t. De DKIM -parameterregistret identifierar registrerade signaturtaggar och tillhörande definitioner. Registrering är en vokabulärreferens, inte ett bevis på att en distribution stöder en parameter korrekt.
Status och implementering är separata bevis
Ett Internet-utkast är ett arbetsdokument, inte en publicerad RFC bara för att den liknar en sådan. RFC 2026 avsnitt 2.2 förklarar den distinktionen; senare processuppdateringar innebär att dess historiska standardtrappa inte bör behandlas som den fullständiga aktuella processen. Skilj även standardspår från informationsdokument, experimentella och bästa aktuella praxisdokument. Citera den faktiska statusposten istället för att anta att varje numrerad RFC har samma behörighet.
För en leverantörsregel, registrera produkten, rutten, molnmiljön, berörda avsändare, meddelanden och verkställighetsdatum separat. En konflikt mellan officiella sidor hör hemma i kravregistret tills en tillämplig aktuell källa eller kontrollerad observation löser den. Ett syntetiskt parserresultat kan testa lokal tolkning men kan inte bevisa fjärrantagande.
Det exakta katalogkravet förblir öppet: Ett kravregister med behörighet, omfattning, ikraftträdandedatum, ägare och godkännandebevis. Den kurerade kartan nedan tillhandahåller källposter och föreslaget ägande, inte fullständigt organisationsspecifikt godkännande. Intaget efterfrågar även fungerande funktionalitet och testning. Statiska ankare och primära länkar levereras, men godkännande av fungerande verktyg, tillämpbarhet, teknisk granskning och publiceringsgodkännande förblir utestående.