Start med autoriteten og spørgsmålet
Et e-mail-godkendelsesbibliotek skal hjælpe en læser med at vælge det rigtige primære dokument, ikke blot samle links. Protokolregler, parameterregistre, udbyderkrav og produktobservationer besvarer forskellige spørgsmål. Denne kuraterede vejledning registrerer omfanget og status for nøglekilder, der blev gennemgået den 8. november 2026. Dens indgange har stabile læseankre; de fastslår ikke, at en lejer, modtager eller EmailAuth implementering er i overensstemmelse med disse kilder.
For hvert operationelle krav skal du beholde den udstedende myndighed, dokumentidentifikation, version eller revisionsdato, berørt population, ansvarlig ejer og acceptbevis. En offentliggørelsesdato er ikke automatisk en udbyders håndhævelsesdato. Et fungerende bibliotek har også brug for vedligeholdelse: ændrede links, nye opdateringer og uløste kildekonflikter skal være synlige i stedet for skjult bag et gammelt anmeldt badge.
DMARC kerne RFC 9989
RFC 9989 er maj 2026-kernen DMARC specifikation, der dækker godkendte identifikatorer, justering, policy discovery og assessment-policy semantik. Dens RFC Editor informationspost identificerer det som foreslået standard; dokumentet er Standards Track og forælder RFC'erne 7489 og 9091. Brug det til aktuelle kerneregler, mens du separat tester forskelle i ældre implementeringer. Politikversionen forbliver DMARC1 , ikke en version opfundet ud fra det nye RFC-nummer.
Samlet rapportering RFC 9990
RFC 9990 er den særskilte specifikation for aggregatrapportering for maj 2026. De RFC Editor rekord identificerer foreslået standardstatus. Den omhandler rapportstruktur, behandling, eksterne destinationer, dubletter og privatlivs-/sikkerhedshensyn. Det bør understøtte en rapportparsers acceptsager, ikke behandles som bevis på, at hver modtager sender komplette rapporter, eller at et dashboards totaler er korrekte.
Fejlrapportering RFC 9991
RFC 9991 er maj 2026 Standards Track fejlrapporteringsspecifikation, opdaterer RFC 6591 og deltager sammen med de to andre dokumenter i at erstatte RFC 7489. Dens fokus er meddelelsesspecifik diagnostik, rapporteringsformat, eksterne destinationer og privatliv. Den separate informationsside blev læst var hastighedsbegrænset under denne anmeldelse; den korrekt læste RFC-tekst understøtter den angivne kategori. Må ikke forvirre fejlrapporter med aggregerede statistikker eller antage, at udgivelse af ruf garanterer rapporter.
SPF RFC 7208
RFC 7208, udgivet i april 2014 på Standards Track, definerer SPF identiteter, politikpostvalg, evaluering og resultathåndtering. Det er det primære udgangspunkt for at forklare en permerror eller grænsen for DNS-forespørgsler. Læs det relevante afsnit og dets afhængigheder i stedet for at reducere SPF til en liste over tilladte IP-adresser eller antage, at hver DNS handling tæller identisk.
DKIM RFC 6376 og algoritmeopdateringer
RFC 6376, udgivet i september 2011 på Standards Track, definerer DKIM signaturer, vælgere, nøgler og verifikation. Læs dens kryptografiske bestemmelser med RFC 8301januar 2018, og RFC 8463, september 2018. Førstnævnte forbyder RSA-SHA1 og styrker RSA-nøglekrav; sidstnævnte definerer Ed25519 bruge. Et ældre basisdokument forbliver nyttigt uden at gøre enhver original algoritmeanbefaling aktuel.
SMTP DNS og eksplicit ingen mail
RFC 5321, oktober 2008, leverer SMTP -transport og målopløsningsregler. RFC 1034 og RFC 1035, november 1987, giver grundlæggende DNS koncepter og registreringsstruktur. Bruge RFC 2308, marts 1998, for forskelle i negative svar snarere end en forældet negativ-caching-genvej. Disse referencer er udgangspunkter med senere opdateringer, ikke en komplet moderne DNS implementeringsspecifikation.
RFC 7505, juni 2015, definerer null MX for et domæne, der eksplicit ikke accepterer mail. Dens afsendervejledning advarer mod at bruge et null-MX-domæne til nogen af dem MAIL FRA eller synlig fra identiteter: modtagere kan afvise denne trafik. Hold denne afsendervejledning adskilt fra SPF og SMTP 's nul-omvendte sti. En bevidst no-mail-post er ikke en manglende eller funktionsfejl MX .
Godkendelsesresultat herkomst RFC 8601
RFC 8601, maj 2019, definerer Authentication-Results header og dens tillidsovervejelser. Brug den, når du vurderer, hvem der har lavet en godkendelsespåstand, og om den påstand hører til inden for det modtagende systems betroede grænse. Det gør ikke en vilkårlig overskrift kopieret fra en meddelelse til autentificeret bevis, og den etablerer heller ikke indbakkeplacering fra et pass-token.
IANA -parameterregistre
De DMARC parameterregistrering, opdateret 22. maj 2026 i den hentede post, forbinder tags til referencer og aktiv eller historisk status. Det markerer pct, rf og ri historisk og inkluderer aktive tags såsom np, psd og t. De DKIM parameterregistrering identificerer registrerede signaturmærker og tilhørende definitioner. Registrering er en ordforrådsreference, ikke et bevis på, at en implementering understøtter en parameter korrekt.
Status og implementering er separate beviser
Et internetudkast er et arbejdsdokument, ikke en offentliggjort RFC, blot fordi det ligner en. RFC 2026 afsnit 2.2 forklarer denne sondring; senere procesopdateringer betyder, at dens historiske standardstige ikke skal behandles som den komplette nuværende proces. Skeln også standardspor fra informations-, eksperimentelle og bedste nuværende praksis-dokumenter. Angiv den faktiske statuspost i stedet for at antage, at hver nummererede RFC har samme autoritet.
For en udbyderregel skal du registrere produktet, ruten, skymiljøet, berørte afsendere, annoncerings- og håndhævelsesdatoer separat. En konflikt mellem officielle sider hører hjemme i kravregistret, indtil en gældende aktuel kilde eller kontrolleret observation løser den. Et syntetisk parserresultat kan teste lokal fortolkning, men kan ikke bevise fjernadoption.
Det nøjagtige katalogkrav forbliver åbent: Et kravregister med autoritet, omfang, ikrafttrædelsesdato, ejer- og acceptbevis. Det kurerede kort nedenfor leverer kildeposter og foreslået ejerskab, ikke gennemført organisationsspecifik accept. Indtaget beder også om fungerende funktionalitet og test. Statiske ankre og primære links leveres, men accept af fungerende værktøj, anvendelighed, teknisk gennemgang og publiceringsgodkendelse forbliver udestående.