Un messaggio può passare DMARC e continuano a non soddisfare i requisiti del mittente del provider di cassette postali. Ciò non è necessariamente una contraddizione. DMARC risponde a una domanda di identità specifica; un destinatario può anche richiedere meccanismi funzionanti, trasporto sicuro, costruzione adeguata del messaggio e comportamento di invio responsabile.
A cominciare dalla decisione sul protocollo
Riferimenti: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, pubblicato nel maggio 2026, rende obsolete le RFC legacy 7489 e 9091. Nella sezione 4.1, DMARC passa quando esiste un record di policy per il dominio dell'autore e tale dominio si allinea con un identificatore autenticato dal messaggio. Rimane il principio del passaggio allineato: deve passare almeno un meccanismo di autenticazione supportato allineamento al dominio Da visibile. Per SPF all'interno di DMARC , l'identità rilevante è SMTP MAIL DA dominio sotto RFC 9989 §4.4.2; un risultato SPF autonomo basato su HELO non sostituisce l'identità DMARC . Per DKIM, è il dominio d= di una firma valida. Un meccanismo di successo senza l'allineamento richiesto non contribuisce al passaggio DMARC . RFC 9989 sezioni 3.2.10 e 4.1–4.3.
L'allineamento ha modalità rigorose e rilassate. Strict confronta esattamente i domini applicabili; rilassato utilizza la loro relazione organizzazione-dominio. La sezione 4.10 RFC 9989 definisce Passeggiata sull'albero DNS scoperta piuttosto che l'approccio legacy dell'elenco dei suffissi pubblici. Verificare la versione implementata del ricevitore o del valutatore prima di assumere il suo comportamento di rilevamento. Non implementare un allineamento rilassato controllando se una stringa di dominio termina semplicemente con un'altra. Un suffisso ingannevole o un calcolo errato del dominio organizzativo possono produrre un risultato sbagliato.
Aggiungi i requisiti del fornitore come livello separato
Le indicazioni di supporto per volumi elevati di Microsoft per i consumatori richiedono il superamento sia SPF che DKIM , oltre DMARC . I requisiti di massa di Yahoo richiedono entrambi i meccanismi e il passaggio DMARC . Queste sono porte operative in aggiunta alla logica del meccanismo di allineamento dell'uno o dell'altro del protocollo. Esamina l'origine corrente per la destinazione anziché dedurre una regola universale da un fornitore. Supporto Microsoft E Requisiti Yahoo.
Crea una colonna per il risultato DMARC e colonne separate per i controlli di autenticazione, DNS , trasporto, formattazione e annullamento dell'iscrizione richiesti. Un indicatore verde generale senza quelle colonne rende difficile capire se il software sta valutando il protocollo, una lista di controllo del provider o solo la sintassi DNS pubblicata.
Utilizza una tabella di verità per evidenziare la differenza
Riferimenti: RFC 9989 §5.3.5.
Il pacchetto di revisione privata include un dispositivo sintetico a due casi. Innanzitutto, SPF e DKIM passano entrambi ma nessuno dei due si allinea: DMARC fallisce. In secondo luogo, SPF fallisce mentre DKIM passa e si allinea: DMARC passa. Il secondo caso può ancora fallire un gate del provider che richiede in modo indipendente il successo SPF .
Questi input sono booleani deliberatamente semplici, non un'implementazione del rilevamento DNS Tree Walk, del rilevamento legacy basato su suffisso pubblico, della valutazione SPF o della crittografia DKIM . Entrambi i casi presuppongono che esista un record di policy DMARC applicabile. Rendono riproducibile la distinzione logica senza pretendere di testare un fornitore. In un'indagine reale, sostituire ciascun valore booleano con un risultato osservato attendibile e la sua identità valutata.
Non confondere la pubblicazione con la valutazione
Riferimenti: RFC 9989 §5.4.
Editoria p=none stabilisce una politica di monitoraggio richiesta, non un risultato positivo dell'autenticazione del messaggio. La pubblicazione di una chiave pubblica DKIM non comporta la firma della posta in uscita. Aggiunta di un Registro SPF non dimostra che la connessione effettiva abbia utilizzato un indirizzo autorizzato. Ogni artefatto di configurazione necessita di un'osservazione corrispondente dal percorso di invio previsto.
Allo stesso modo, passando da p=none a p=reject non ripara l'allineamento. Modifica la gestione richiesta dal proprietario del dominio in caso di errori. Inventariare i percorsi legittimi prima di modificare l'applicazione, preservare un piano di ripristino e valutare l'effetto sui flussi indiretti. Il destinatario continua ad applicare la propria politica di disposizione locale; un'azione DMARC richiesta non è una garanzia di consegna.
Costruisci un utile registro di chiusura
Riferimenti: RFC 8601 §5.
Per ogni campione analizzato, conserva Da, mittente della busta, IP di connessione, firmatario DKIM e selettore, risultati del meccanismo, modalità di allineamento e risposta di ricezione finale. Identificare la fonte attendibile di tali risultati. Non accettare le intestazioni copiate arbitrariamente come autorevoli semplicemente perché contengono la parola “pass”.
Chiudere separatamente la verifica del protocollo e la verifica della conformità del provider. Ciò consente di affermare con precisione che DMARC è stato approvato mentre un altro requisito è rimasto irrisolto e di assegnare la correzione al titolare giusto senza indebolire i controlli non correlati.