SPF, DKIM o DMARC hanno smesso di funzionare? Come trovare la causa

Un'autenticazione che ha passato i controlli per due anni può fallire un martedì qualsiasi, senza messaggi di errore e senza alcuna modifica che ricordi di aver fatto. La posta lascia comunque i tuoi server. Semplicemente arriva nello spam, o come fallimento DMARC in un report che non hai ancora aperto, o non arriva affatto. Questa guida spiega cosa di solito rompe SPF, DKIM e DMARC dopo che funzionavano, come trovare la causa in pochi minuti con qualche interrogazione DNS e come scoprire la prossima regressione prima che lo faccia il tuo tasso di rimbalzo.

La risposta breve#

Quando un'autenticazione che funzionava inizia a fallire, o è cambiato qualcosa nel DNS o è cambiato qualcosa nel mittente. Controlla in quest'ordine: è stato cambiato di recente un host DNS o un nameserver, c'è esattamente un record SPF, il selettore DKIM del messaggio che fallisce restituisce ancora una chiave, c'è esattamente un record DMARC su _dmarc e un nuovo strumento di invio ha iniziato a inviare a nome del tuo dominio? Queste cinque domande spiegano la maggior parte delle regressioni. Leggi per prima l'intestazione Authentication-Results di un messaggio che fallisce, perché ti dice quale tra SPF, DKIM o DMARC è fallito e per quale dominio. L'analizzatore di intestazioni email mostra quei verdetti e il verificatore SPF, DKIM e DMARC mostra cosa dice il DNS in questo momento.

Leggi prima il messaggio che fallisce#

Non tirare a indovinare quale protocollo si sia rotto. Apri le intestazioni complete di un messaggio fallito e trova la riga Authentication-Results aggiunta dal server ricevente.

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.example.com;
  dkim=fail header.d=example.com header.s=mail;
  dmarc=fail header.from=example.com

Contano tre dettagli. spf= e dkim= indicano quale controllo è fallito. header.s è il selettore DKIM usato, che ti dice l'esatto nome DNS da interrogare. E smtp.mailfrom o header.d mostrano quale dominio ha valutato ciascun controllo, il che conta quando il messaggio supera SPF per un dominio diverso da quello nell'intestazione From.

Poi interroga i record dalla riga di comando. Funzionano su macOS e Linux.

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Sostituisci mail con il selettore preso dall'intestazione. Se non lo conosci, come trovare un selettore DKIM ti guida passo passo. Se l'interrogazione non restituisce nulla, il record non c'è più. Se restituisce qualcosa, leggilo con attenzione, perché la sezione successiva spiega come un record può esistere ed essere comunque rotto.

Causa 1: una migrazione DNS ha perso o rovinato dei record#

Passare a un nuovo host DNS, a un nuovo registrar o a una nuova piattaforma per il sito è in assoluto il fattore scatenante più comune. Lo strumento di importazione copia ciò che capisce, di solito record A, CNAME e MX, e salta o riscrive in silenzio i record TXT. I sintomi sono un dominio senza SPF, senza DMARC o con un selettore DKIM che non si risolve più, tutto a partire dalla data della migrazione.

Dopo qualsiasi trasferimento controlla tre cose: che i nameserver puntino davvero dove pensi, che ogni record di autenticazione esista sul nuovo host e che i valori TXT lunghi siano arrivati interi. Le chiavi DKIM lunghe sono la vittima abituale: alcuni host le troncano o aggiungono spazi di troppo, e una chiave tagliata non supera la verifica anche se il record "esiste" (perché le chiavi lunghe vanno divise). Le guide specifiche per Cloudflare e Route 53 mostrano come ciascuno le gestisce, e cambiare provider di posta affronta la stessa trappola dal lato della posta.

Causa 2: due record SPF, o due record DMARC#

Un dominio può pubblicare esattamente un record SPF ed esattamente un record DMARC. Si rompe in silenzio quando la pagina di configurazione di un nuovo strumento dice "aggiungi questo record TXT" e qualcuno aggiunge una seconda voce v=spf1 invece di modificare la prima.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

Con due record come questi, i riceventi restituiscono un errore permanente per SPF, quindi SPF fallisce per ogni messaggio, compresa la posta degli strumenti elencati. La soluzione è unirli in un unico record con entrambi gli include prima di ~all. La stessa regola vale su _dmarc: due record DMARC significano che i riceventi li ignorano entrambi. Tieni d'occhio il budget di query durante l'unione, perché ogni include: aggiunto costa query DNS e il limite è 10. SPF: troppe query DNS spiega come contarle.

Causa 3: una chiave DKIM è stata ruotata, spostata o rimossa#

DKIM firma ogni messaggio con una chiave privata e pubblica la metà pubblica su selector._domainkey.yourdomain.com. Se il record DNS scompare mentre il mittente firma ancora con quel selettore, ogni messaggio fallisce DKIM.

Succede in diversi modi. Un provider passa a un nuovo selettore e tu ripulisci troppo presto il vecchio record. Qualcuno elimina voci _domainkey "inutilizzate" durante un riordino del DNS. Un CNAME che punta a una chiave ospitata dal provider smette di risolversi perché il provider l'ha cambiata o perché hai lasciato il servizio. Oppure la chiave è stata revocata, cosa che si pubblica come valore p= vuoto.

Il test è semplice: prendi il selettore da header.s del messaggio che fallisce, interroga selector._domainkey.yourdomain.com e verifica che ci sia un valore p= con dati di chiave veri. Se il selettore è sbagliato perché il mittente è passato a uno nuovo, pubblica il nuovo record fornito dal provider. Una rotazione fatta bene sovrappone la chiave vecchia e quella nuova, come descrive la guida ai selettori.

Causa 4: un nuovo mittente ha iniziato a inviare a nome del tuo dominio#

A volte i tuoi record vanno bene ed è cambiato il mittente. Un team attiva un CRM, un helpdesk, uno strumento di fatturazione o una piattaforma di newsletter, e ognuno comincia a inviare con il tuo dominio nell'indirizzo From. Se nessuno ha aggiunto quel servizio a SPF e configurato la sua chiave DKIM, la sua posta fallisce l'allineamento SPF, può non superare alcun controllo e compare come fallimento nei report DMARC.

Non te ne accorgi guardando il DNS, perché il DNS non è cambiato. Te ne accorgi guardando chi sta davvero inviando. Per questo servono i report aggregati DMARC: una nuova sorgente con un basso tasso di superamento è la firma tipica. Per ciascuna di queste sorgenti, o la autentichi correttamente (includila in SPF dove opportuno e, soprattutto, firma DKIM con il tuo dominio) oppure le impedisci di inviare a tuo nome.

Causa 5: un record di supporto scaduto o modificato#

Alcuni guasti stanno accanto all'autenticazione anziché al suo interno.

• È cambiata la destinazione di un CNAME. Molti provider ti chiedono di puntare un record al loro hostname. Se lo ritirano o se elimini il CNAME, la chiave o il dominio del return-path smette di risolversi.
• Un host MX ha perso il suo indirizzo. La posta verso il tuo dominio inizia a rimbalzare anche se l'autenticazione in uscita è perfetta, perché l'host indicato nell'MX non ha un record A o AAAA.
• Policy MTA-STS e DNS non sono più allineate. Il record TXT _mta-sts c'è ancora, ma il file della policy via HTTPS non elenca più i tuoi host MX attuali, oppure è scaduto il certificato di un server di posta. I mittenti con una policy in modalità enforce rimandano o rifiutano la posta, mentre quelli senza policy in cache ripiegano semplicemente sulla consegna in chiaro, quindi il danno è a macchia di leopardo. Vedi MTA-STS e TLS-RPT.
• DMARC è stato irrigidito. Qualcuno è passato da p=none a quarantine o reject. I fallimenti che c'erano da sempre, come uno strumento non autenticato o la posta inoltrata, ora ti costano recapito. Il fallimento non era nuovo. La conseguenza sì.

Individuare per tempo la prossima regressione#

La maggior parte di questi problemi si rileva dal solo DNS, prima di un singolo rimbalzo, perché lo stato rotto è un record mancante o malformato. L'eccezione è tutto ciò che sta dietro il record DNS, come un file di policy MTA-STS. Controlla, in quest'ordine di urgenza:

1. L'MX è presente e ogni host si risolve.
2. Esattamente un record SPF, sintassi valida, 10 query o meno.
3. Ogni selettore DKIM su cui fai affidamento restituisce una chiave con un valore p=.
4. Esattamente un record DMARC con una policy valida e un indirizzo rua=.

Puoi eseguire questi controlli a mano dopo ogni modifica al DNS, e dovresti. Il punto debole di un controllo manuale è che la regressione che ti interessa avviene quando nessuno guarda. Il monitoraggio check-up del dominio ripete questi controlli su ogni dominio coperto una volta al giorno e ti invia un'email quando un problema compare e di nuovo quando rientra. I codici di problema corrispondono a questo elenco: SPF mancante o multiplo, SPF oltre il limite di query, un include SPF che non pubblica alcun record, un selettore DKIM configurato senza chiave o con chiave revocata, DMARC mancante o non valido e problemi MX. Un articolo di riferimento, monitoraggio della salute del dominio email, spiega il quadro più ampio e con quale frequenza controllare.

Vale la pena conoscere due dettagli. Sei tu a indicare quali selettori DKIM tenere d'occhio, perché un selettore mancante può essere segnalato solo se lo hai nominato. E un timeout DNS produce "impossibile da controllare", non un avviso, così non vieni svegliato da un resolver instabile.

Cosa il monitoraggio non rileva#

Il monitoraggio DNS legge solo il DNS pubblico. Non può sapere che un nuovo CRM ha iniziato a inviare a tuo nome, che un record SPF valido non include un mittente o che un provider ha ruotato una chiave che non gli hai mai comunicato. I report aggregati DMARC mostrano chi invia davvero a tuo nome e il test di recapito email mostra come si autentica un messaggio reale. L'elenco completo dei limiti è nella guida al monitoraggio della salute del dominio.

Un'autenticazione funzionante dimostra che la tua posta è davvero tua, non che la tua lista valga l'invio. Quando sei pronto a guardare la lista, il piano gratuito nella pagina dei prezzi ti dà 100 crediti che eseguono la verifica completa. Dei record corretti hanno comunque bisogno di una lista in salute alle spalle.