termine · verifica DMARC

Come si esegue una verifica DMARC per le email di un'applicazione?

Una verifica DMARC deve controllare quattro aspetti distinti: che nel DNS sia individuabile una policy valida, che i suoi tag obbligatori vengano analizzati correttamente, che su un messaggio reale almeno un identificatore SPF o DKIM autenticato sia allineato con il dominio From visibile e che ogni mittente legittimo dell'applicazione sia stato considerato prima dell'enforcement. Interroga il nome _dmarc, esamina il record, poi analizza i risultati di autenticazione dei messaggi inviati in modo controllato. Superare DMARC convalida l'uso autorizzato del dominio; non dimostra la consegna né l'arrivo in inbox.

Tratta la verifica DMARC come quattro test, non come un singolo lookup

Una verifica utile ha quattro livelli. Primo, individua la policy che si applica al dominio dell'autore del messaggio. Secondo, convalida il record TXT come policy DMARC invece di accettare qualsiasi testo restituito dal DNS. Terzo, testa l'allineamento degli identificatori su un messaggio reale: il dominio MAIL FROM autenticato da SPF o un dominio di firma DKIM verificato deve essere allineato con il dominio nell'intestazione From visibile. Quarto, conferma la copertura operativa inviando attraverso ogni applicazione, provider, regione e classe di messaggi legittimi che usano il dominio. Un lookup DNS verde copre solo una parte dei primi due livelli. Non può dimostrare che un provider firmi con il dominio previsto, che un return path personalizzato sia attivo, che l'inoltro abbia cambiato il comportamento di SPF o che un sistema trascurato reggerà una policy in enforcement.

Interroga il nome DNS corretto e segui l'individuazione della policy

Parti dal dominio esatto nell'intestazione From RFC5322, spesso chiamato dominio dell'autore. Interroga il record TXT su _dmarc seguito da quel dominio. Per un messaggio da alerts@notify.example.test, parti da _dmarc.notify.example.test e non dall'host del sito web, dall'host MX o dal dominio return-path. L'RFC 9989 definisce un'individuazione della policy che va oltre un singolo lookup: se il dominio dell'autore non ha un record valido, un destinatario può risalire l'albero DNS per trovare la policy applicabile del dominio organizzativo o del suffisso pubblico. La gestione dei sottodomini può derivare dal tag sp, np o p, a seconda di cosa esiste e di dove viene trovata la policy. Per questo uno strumento di verifica dovrebbe riportare sia il nome interrogato sia il dominio della policy effettivamente selezionato. Un risultato che dice solo "record trovato" può nascondere errori di ereditarietà o una policy esplicita per i sottodomini che cambia il trattamento atteso.

Convalida la struttura del record prima di interpretare la policy

Un record di policy DMARC usa una sintassi tag-valore. Secondo RFC 9989, v=DMARC1 è obbligatorio, distingue maiuscole e minuscole e deve comparire per primo; un tag p valido fornisce la policy di valutazione richiesta. I valori di policy comuni sono none, quarantine e reject. I tag facoltativi descrivono le destinazioni dei report, il comportamento dei sottodomini e l'allineamento SPF e DKIM strict o relaxed. Non correggere silenziosamente tag scritti male, un valore p mancante, record duplicati o in conflitto, separatori non validi o un valore copiato con artefatti di virgolette del provider DNS. Considera un errore di valutazione permanente come un risultato da correggere, non come un esito DMARC positivo o negativo. Distingui inoltre un errore transitorio di lookup DNS da un record non valido. Riprova un errore del resolver transitorio attraverso un percorso controllato, ma non affermare che il dominio non abbia alcuna policy finché il DNS autorevole non può essere interrogato in modo affidabile.

Verifica l'allineamento SPF e DKIM su un messaggio reale

DMARC viene valutato sull'autenticazione del messaggio, non sulla sola configurazione DNS. Per SPF, confronta il dominio MAIL FROM autenticato con il dominio From visibile. Per DKIM, confronta il dominio d= di ogni firma verificata correttamente con il dominio From visibile. L'allineamento relaxed accetta domini con lo stesso dominio organizzativo; l'allineamento strict richiede domini identici. Un messaggio supera il controllo quando almeno un identificatore autenticato supera il relativo meccanismo ed è allineato. Ad esempio, il return path di un provider può far risultare SPF pass per il dominio del provider, ma restare non allineato con billing.example.test. Se DKIM verifica con d=example.test con allineamento relaxed, il messaggio può comunque superare DMARC. Acquisisci l'intestazione Authentication-Results grezza da account destinatari controllati, ma interpretala nel contesto, perché riporta il risultato del destinatario che ha eseguito la valutazione e può contenere più hop o firme.

Leggi con precisione i risultati pass, fail, none ed errore

Un esito DMARC positivo significa che si applica un record di policy e che un identificatore SPF o DKIM autenticato è allineato con il dominio autore. Un esito negativo significa che si applica una policy ma non esiste alcun identificatore autenticato e allineato. None significa che non è stata individuata alcuna policy applicabile. Permerror e temperror indicano errori durante la valutazione DMARC; un messaggio con un errore DNS non può essere considerato né con esito DMARC positivo né negativo. Questi risultati non indicano dove il provider della casella ha collocato il messaggio. RFC 9989 limita esplicitamente un esito positivo alla convalida che l'uso del dominio sia autorizzato dal suo proprietario; non afferma che il messaggio sia sicuro, desiderato, affidabile o adatto all'inbox. Mantieni come campi separati nella diagnostica e nelle dashboard l'accettazione del provider, l'accettazione del server ricevente, il risultato DMARC, i segnali di segnalazione di spam e il posizionamento osservato.

Mappa ogni mittente legittimo prima dell'enforcement

Censisci tutti i sistemi che inseriscono il dominio nel From: applicazioni di produzione, email di autenticazione, avvisi di fatturazione, strumenti di supporto, piattaforme di marketing, avvisi di monitoraggio, flussi CRM, account regionali e sistemi di emergenza. Per ogni flusso, registra dominio From visibile, dominio MAIL FROM, dominio DKIM d= e selettore, account del provider, responsabile, classe di messaggi e volume previsto. Invia messaggi controllati attraverso il normale percorso di produzione e verifica sia l'autenticazione sia l'allineamento. I report DMARC aggregati possono rivelare le sorgenti che usano il dominio, ma vanno interpretati e possono includere traffico inoltrato o non autorizzato. Inizia con il monitoraggio finché l'inventario è incompleto, poi correggi i flussi legittimi non allineati prima di richiedere ai destinatari una gestione più severa. Non modificare una policy organizzativa condivisa solo per far diventare verde un'applicazione e non passare all'enforcement sulla base di un singolo messaggio di prova.

Diagnostica gli errori comuni delle email di applicazione

Se non viene trovata alcuna policy, verifica la zona DNS e il nome del record prima di modificarne il valore. Se il record ha un errore permanente, riducilo a un'unica policy valida e controlla ordine e sintassi dei tag. Se DKIM fallisce, controlla che il selettore previsto esista, che il provider abbia effettivamente firmato il messaggio testato, che il corpo o le intestazioni firmate non siano cambiati durante il transito e che il dominio d= verificato sia allineato. Se SPF risulta pass ma DMARC fallisce, confronta il dominio MAIL FROM con il dominio From visibile invece di considerare sufficiente qualsiasi pass di SPF. Se falliscono solo i messaggi inoltrati, ricorda che l'inoltro spesso cambia il percorso della busta e può compromettere SPF, mentre una firma DKIM valida e allineata può sopravvivere. Se un rollout causa rifiuti, conserva le intestazioni dei messaggi falliti e la risposta del destinatario, blocca ulteriori inasprimenti della policy e correggi il flusso responsabile invece di indebolire controlli di autenticazione non correlati.

Applica in modo consapevole le regole di allineamento di ciascun provider

I mittenti di terze parti richiedono una configurazione che leghi i loro identificatori autenticati a un dominio controllato dall'organizzazione. Amazon SES documenta due percorsi: un dominio MAIL FROM personalizzato e allineato per SPF e un dominio di firma DKIM allineato. Il return path predefinito, di proprietà del provider, può autenticarsi con SPF senza allinearsi al dominio From visibile, quindi DKIM è spesso il meccanismo allineato più pratico, a meno che non sia configurato un dominio MAIL FROM personalizzato. Altri provider usano nomi diversi per return path, domini di bounce, autenticazione del dominio e identità di firma. Verifica il messaggio effettivamente prodotto invece di presumere che il badge "verificato" di una dashboard garantisca DMARC. Anche le attuali linee guida di Gmail per i mittenti richiedono autenticazione e allineamento per il traffico interessato e raccomandano il reporting DMARC. I requisiti dei destinatari e le funzionalità dei provider possono cambiare, quindi ricontrolla la loro documentazione ufficiale al lancio e durante l'analisi degli incidenti.

Usa le evidenze del provider senza trattarle come un verdetto DMARC

SendHQ supporta l'invio da domini verificati, gli eventi di consegna, le soppressioni e una dashboard web. Usa le informazioni sul dominio di invio e sulla consegna per indagare un flusso di messaggi, quindi verifica DMARC dall'intestazione Authentication-Results del server ricevente e separa le evidenze SPF, DKIM e di allineamento. L'accettazione del provider e gli eventi di consegna non dimostrano l'arrivo in inbox.

Registra un risultato di verifica DMARC verificabile

Un risultato durevole dovrebbe contenere il dominio dell'autore, l'orario della query, il resolver, il nome _dmarc interrogato, il dominio della policy selezionato, il record esatto normalizzato, le modalità di policy e di allineamento, lo stato DNS e l'esito dell'analisi: sintassi valida, permerror o temperror. Aggiungi una riga per ogni messaggio controllato con un identificatore non sensibile del messaggio, il sistema di invio, il dominio From visibile, il dominio SPF autenticato e il relativo risultato, i domini e i selettori DKIM verificati, le decisioni di allineamento, il risultato DMARC finale e il destinatario. Conserva le intestazioni grezze in uno storage ad accesso limitato, perché possono esporre indirizzi, dettagli di instradamento e identificatori interni. Collega ogni rilievo a un responsabile e a una data di correzione. Ricontrolla dopo la scadenza dei TTL DNS, le modifiche alla configurazione del provider, la rotazione delle chiavi, l'aggiunta di nuovi flussi di messaggi o l'inasprimento della policy. Queste prove rendono la verifica riproducibile e impediscono che uno screenshot o il badge di uno strumento diventino una prova permanente dopo che la configurazione sottostante è cambiata.

Domande frequenti

Dove va verificato un record DMARC?

Parti dal record TXT su _dmarc seguito dal dominio esatto dell'indirizzo From visibile. Identifica anche il dominio della policy selezionato secondo le attuali regole di individuazione DMARC, perché può applicarsi una policy organizzativa o di sottodominio quando il primo nome interrogato non ha un record valido.

Trovare v=DMARC1 significa che DMARC viene superato?

No. Contribuisce solo a un record di policy valido. Un messaggio supera DMARC quando SPF o DKIM lo autenticano con un dominio allineato al dominio From visibile. Testa un messaggio reale ed esamina i risultati di autenticazione del destinatario.

DMARC può essere superato quando SPF non è allineato?

Sì. Una firma DKIM verificata correttamente può fornire l'identificatore autenticato allineato necessario per DMARC. È possibile anche il contrario: un SPF allineato può consentire il pass quando DKIM non lo fa, anche se affidarsi a un solo meccanismo riduce la resilienza.

Superare DMARC dimostra l'arrivo in inbox?

No. Convalida l'uso autorizzato del dominio dell'autore per quel messaggio. Un destinatario può comunque applicare segnali di reputazione, contenuto, destinatario, abuso e policy locali quando accetta, rifiuta, mette in quarantena o classifica il messaggio.

Un'applicazione dovrebbe passare direttamente a p=reject?

Di solito no, senza inventario ed evidenze di monitoraggio. Mappa ogni mittente legittimo, convalida l'allineamento su messaggi controllati, esamina i report aggregati, correggi i fallimenti e coordina le modifiche della policy con il proprietario del dominio prima di richiedere una gestione più rigorosa.

Cosa va ricontrollato dopo aver cambiato provider email?

Ricontrolla la policy individuata per ogni dominio From, i domini MAIL FROM e DKIM del provider, il DNS del selettore, i risultati SPF e DKIM, l'allineamento relaxed o strict, i report aggregati e ogni classe di messaggi dell'applicazione inviata in modo controllato, prima di aumentare il traffico di produzione.

Fonti