Inizia con l'autorità e la domanda
Una libreria di autenticazione e-mail dovrebbe aiutare il lettore a selezionare il documento principale corretto, non semplicemente a raccogliere collegamenti. Le regole del protocollo, i registri dei parametri, i requisiti dei fornitori e le osservazioni sui prodotti rispondono a domande diverse. Questa guida curata registra la portata e lo stato delle fonti chiave revisionate l'8 novembre 2026. Le sue voci hanno ancoraggi di lettura stabili; non stabiliscono che un tenant, un destinatario o un'implementazione EmailAuth sia conforme a tali fonti.
Per ciascun requisito operativo, conservare l'autorità emittente, l'identificatore del documento, la data della versione o della revisione, la popolazione interessata, il proprietario responsabile e la prova di accettazione. Una data di pubblicazione non è automaticamente una data di applicazione da parte del provider. Una libreria funzionante necessita anche di manutenzione: collegamenti modificati, nuovi aggiornamenti e conflitti di fonti irrisolti devono essere visibili anziché nascosti dietro un vecchio badge revisionato.
Base DMARC RFC 9989
RFC 9989 è il nucleo di maggio 2026 DMARC specifica, che copre gli identificatori autenticati, allineamento, scoperta delle politiche e semantica delle politiche di valutazione. Suo Record di informazioni sull'editor RFC lo identifica come Proposta di Standard; il documento è Standards Track e rende obsoleti gli RFC 7489 e 9091. Usalo per le regole fondamentali attuali, testando separatamente le differenze di implementazione legacy. La versione della policy rimane DMARC1 , non una versione inventata dal nuovo numero RFC.
Rapporti aggregati RFC 9990
RFC 9990 è la specifica separata di rendicontazione aggregata del maggio 2026. IL Record dell'editor RFC identifica lo stato dello standard proposto. Riguarda la struttura del report, l'elaborazione, le destinazioni esterne, i duplicati e le considerazioni sulla privacy/sicurezza. Dovrebbe supportare i casi di accettazione del parser di report e non essere trattato come prova che ogni destinatario invii report completi o che i totali di un dashboard siano corretti.
Segnalazione errori RFC 9991
RFC 9991 è la specifica di segnalazione degli errori Standards Track di maggio 2026, aggiorna RFC 6591 e partecipa con gli altri due documenti alla sostituzione RFC 7489. Il suo focus è la diagnostica specifica del messaggio, il formato di reporting, le destinazioni esterne e la privacy. La lettura della pagina informativa separata è stata limitata durante questa revisione; il testo RFC letto con successo supporta la categoria indicata. Non confondere segnalazioni di guasti con statistiche aggregate o presupporre che la pubblicazione di ruf garantisca i report.
SPF RFC 7208
RFC 7208, pubblicato nell'aprile 2014 su Standards Track, definisce SPF identità, selezione dei dati politici, valutazione e gestione dei risultati. È il punto di partenza principale per spiegare a permerror o il limite dei termini di query DNS. Leggi la sezione pertinente e le sue dipendenze anziché ridurre SPF a un elenco di indirizzi IP consentiti o dare per scontato che ogni operazione DNS conti in modo identico.
DKIM RFC 6376 e aggiornamenti dell'algoritmo
RFC 6376, pubblicato nel settembre 2011 su Standards Track, definisce DKIM firme, selettori, chiavi e verifica. Leggi le sue disposizioni crittografiche con RFC 8301, gennaio 2018 e RFC 8463, settembre 2018. Il primo vieta RSA-SHA1 e rafforza i requisiti chiave RSA; quest'ultimo definisce Ed25519 utilizzo. Un documento di base più vecchio rimane utile senza rendere attuali tutte le raccomandazioni dell'algoritmo originale.
DNS SMTP e nessuna posta esplicita
RFC 5321, ottobre 2008, fornisce le regole di trasporto SMTP e di risoluzione dei target. RFC 1034 E RFC 1035, novembre 1987, forniscono i concetti fondamentali DNS e la struttura dei record. Utilizzo RFC 2308, marzo 1998, per le distinzioni di risposta negativa piuttosto che per un'obsoleta scorciatoia per la memorizzazione nella cache dei negativi. Questi riferimenti sono punti di partenza con aggiornamenti successivi, non una specifica di implementazione DNS moderna e completa.
RFC 7505, giugno 2015, definisce null MX per un dominio che non accetta esplicitamente posta. La guida del mittente mette in guardia dall'utilizzare un dominio null-MX per entrambi MAIL DA o visibile Dalle identità: i ricevitori possono rifiutare quel traffico. Mantieni la guida del mittente distinta da SPF e dal percorso inverso nullo di SMTP . Un record di mancata e-mail intenzionale non è un MX mancante o malfunzionante.
Provenienza del risultato dell'autenticazione RFC 8601
RFC 8601, maggio 2019, definisce il Intestazione Authentication-Results e le sue considerazioni sulla fiducia. Usalo quando valuti chi ha effettuato un'asserzione di autenticazione e se tale asserzione appartiene all'interno del confine attendibile del sistema ricevente. Non trasforma un'intestazione arbitraria copiata da un messaggio in una prova autenticata, né stabilisce il posizionamento della posta in arrivo da un token di passaggio.
Registri dei parametri IANA
IL Registro dei parametri DMARC, aggiornato il 22 maggio 2026 nel record recuperato, collega i tag ai riferimenti e allo stato attivo o storico. Contrassegna pct, rf e ri storici e include tag attivi come np, psd e t. IL Registro dei parametri DKIM identifica i tag della firma registrata e le definizioni associate. La registrazione è un riferimento al vocabolario, non una prova che una distribuzione supporti correttamente un parametro.
Lo stato e l'implementazione sono prove separate
Un Internet-Draft è un documento di lavoro, non una RFC pubblicata semplicemente perché gli somiglia. RFC 2026 sezione 2.2 spiega questa distinzione; i successivi aggiornamenti del processo significano che la sua scala di standard storici non dovrebbe essere trattata come il processo attuale completo. Distinguere inoltre il percorso degli standard dai documenti informativi, sperimentali e sulle migliori pratiche attuali. Citare il record dello stato effettivo anziché dare per scontato che ogni RFC numerata abbia la stessa autorità.
Per una regola del fornitore, registrare separatamente il prodotto, il percorso, l'ambiente cloud, i mittenti interessati, le date di annuncio e di applicazione. Un conflitto tra le pagine ufficiali appartiene al registro dei requisiti finché una fonte attuale applicabile o un'osservazione controllata non lo risolvono. Un risultato del parser sintetico può testare l'interpretazione locale ma non può dimostrare l'adozione remota.
L'esatto requisito del catalogo rimane aperto: un registro dei requisiti con autorità, ambito, data di entrata in vigore, proprietario e prova di accettazione. La mappa curata di seguito fornisce le voci delle fonti e la proprietà proposta, non l'accettazione specifica dell'organizzazione completata. L'assunzione richiede anche funzionalità di funzionamento e collaudo. Vengono forniti ancoraggi statici e collegamenti primari, ma l'accettazione dello strumento funzionante, l'applicabilità, la revisione tecnica e l'approvazione della pubblicazione rimangono in sospeso.