Come si verifica un record SPF per le email applicative?

Parti dall'identità che SPF controlla davvero

Un controllo SPF richiede tre input: l'indirizzo IP del client SMTP, il dominio di cui si valuta la policy di autorizzazione e l'identità del mittente. Per la normale posta applicativa, quel dominio viene preso dall'indirizzo SMTP MAIL FROM, chiamato anche mittente di busta o return path. Può essere diverso dall'indirizzo che le persone vedono nell'intestazione From del messaggio. Se MAIL FROM è vuoto, come avviene di norma per una notifica sullo stato di consegna, SPF usa l'identità HELO per il controllo MAIL FROM. Prima di consultare il DNS, annota l'IP di connessione reale e l'identità di busta da un messaggio di test ricevuto o dalla configurazione del provider di invio. Controllare example.test solo perché compare nel From non porta a nessuna conclusione se l'applicazione invia in realtà con MAIL FROM su bounce.provider.test o bounces.example.test.

Interroga il TXT sul dominio MAIL FROM esatto

Interroga i record DNS TXT sul dominio esatto individuato nel primo passaggio. RFC 7208 richiede che le policy SPF versione 1 siano pubblicate come record TXT sul nome proprietario a cui si applicano. Ignora i valori TXT non pertinenti e seleziona i record la cui sezione di versione è esattamente v=spf1. Se non viene selezionato alcun record, il risultato SPF è none. Se ne vengono selezionati più di uno, il risultato è permerror: pubblicare record separati per fornitori diversi non è un modo valido per combinarli. Gli strumenti DNS possono mostrare un singolo resource record TXT suddiviso in più stringhe tra virgolette, ma queste vengono concatenate senza spazi aggiuntivi prima dell'analisi SPF. Salva la risposta completa, il resolver, l'ora della query e il TTL, così potrai ripetere il controllo dopo una modifica.

Convalida la sintassi e valuta i termini da sinistra a destra

Un record SPF è una policy ordinata, non un elenco non ordinato di provider. Dopo v=spf1, i meccanismi vengono valutati da sinistra a destra finché uno corrisponde. Un qualificatore iniziale determina il risultato: + significa pass ed è il valore predefinito, - significa fail, ~ significa softfail e ? significa neutral. I meccanismi ip4 e ip6 confrontano l'indirizzo del client con un indirizzo o una rete. I meccanismi a e mx eseguono risoluzioni DNS, mentre include valuta la policy SPF di un altro dominio e corrisponde solo secondo le regole di include. exists esegue un test basato sul DNS. all corrisponde sempre e di solito chiude il record. Un errore di sintassi in qualsiasi punto produce permerror prima della valutazione normale. Uno strumento di verifica utile dovrebbe indicare quale meccanismo ha trovato corrispondenza, il suo qualificatore e ogni dominio espanso, invece di restituire solo un badge colorato.

Segui include e redirect senza trattarli come alias

Segui ogni include e redirect mantenendo lo stesso contesto di valutazione. include è un meccanismo: chiede se la policy inclusa restituisce pass per il client e il mittente correnti e, se non c'è corrispondenza, prosegue nel record originale. redirect è un modificatore che entra in gioco dopo che nessun meccanismo del record corrente ha trovato corrispondenza; trasferisce la valutazione a un'altra policy mantenendo IP del client e mittente. Un redirect viene ignorato se all compare in un punto qualsiasi del record. Queste differenze contano durante le migrazioni. Sostituire include:vendor.test con redirect=vendor.test può rimpiazzare l'intera policy di fallback del proprietario del dominio, invece di aggiungere semplicemente un fornitore. Rileva cicli, destinazioni mancanti o non valide ed errori annidati permanenti o temporanei, e conserva nel risultato la catena di dipendenze, così che una modifica alla policy lato provider sia visibile.

Conta l'intero budget di query DNS

Conta i termini che generano query DNS nell'intera valutazione ricorsiva, non solo nel record di primo livello. RFC 7208 limita a dieci i termini include, a, mx, ptr, exists e redirect in una singola valutazione SPF; il superamento del limite deve produrre permerror. I meccanismi all, ip4 e ip6 non consumano questo budget. L'elaborazione di MX e PTR ha limiti aggiuntivi sulle query di indirizzo. La RFC raccomanda inoltre di limitare a due i void lookup, cioè le risposte vuote riuscite o gli errori di nome, e di produrre permerror quando si supera quel limite. Il meccanismo ptr è sconsigliato perché lento e inaffidabile. Un record può sembrare breve mentre gli include dei provider si espandono in abbastanza termini annidati da fallire: riporta quindi il totale, ogni termine che contribuisce, i void lookup e il ramo esatto seguito per l'IP testato.

Interpreta il risultato SPF senza sopravvalutarlo

Usa il vocabolario standard dei risultati. Pass significa che il client testato è autorizzato a usare l'identità SMTP controllata. Fail significa che è stata trovata un'autorizzazione negativa corrispondente. Softfail è un'indicazione negativa debole, mentre neutral indica che il dominio non si esprime su quel client. None significa che non è stato selezionato alcun record SPF. Temperror indica un problema di valutazione temporaneo, di solito DNS; permerror indica una policy che non può essere valutata correttamente. Se nessun meccanismo corrisponde e non si applica alcun redirect, il risultato è neutral, equivalente a un ?all implicito. Riporta il risultato insieme a identità, IP del client, termine corrispondente, traccia DNS e orario. Non tradurre pass in messaggio sicuro, posta desiderata, accettazione da parte del provider, consegna nella casella o arrivo in inbox, perché SPF non decide nessuno di questi esiti.

Controlla un messaggio reale, non solo il record pubblicato

Un controllo statico del record dice se una policy può essere trovata e analizzata. Non dimostra che l'applicazione abbia usato il dominio MAIL FROM o l'IP in uscita previsti. Invia un messaggio controllato attraverso ogni percorso di produzione reale a un account destinatario che amministri, poi esamina le intestazioni ricevute. Confronta l'IP di connessione, il mittente di busta e la voce Authentication-Results del destinatario con la valutazione DNS. Ripeti per ogni provider, regione, pool dedicato o condiviso, percorso di fallback e classe di messaggi che può cambiare il return path. Conserva le intestazioni in uno storage ad accesso limitato, perché indirizzi e dettagli di instradamento possono essere sensibili. Se la dashboard di un provider e il messaggio ricevuto non concordano, il messaggio è una prova più solida del percorso effettivamente seguito, anche se il risultato di un singolo destinatario non va comunque generalizzato a un comportamento di consegna universale.

Valuta l'allineamento DMARC come passaggio separato

SPF può dare pass per un dominio di return path di proprietà del provider mentre DMARC non riesce comunque a usare quel risultato. Le regole DMARC attuali confrontano il dominio RFC5321.MailFrom autenticato con successo da SPF con il dominio dell'autore nel campo RFC5322.From visibile. L'allineamento strict richiede lo stesso dominio DNS. L'allineamento relaxed ammette domini che risalgono allo stesso dominio organizzativo secondo le regole di individuazione di DMARC. Per esempio, bounces.example.test ed example.test possono essere allineati in modalità relaxed, mentre bounce.provider.test ed example.test no. Un risultato DMARC può invece basarsi su una firma DKIM allineata e verificata, quindi un risultato SPF non allineato non significa di per sé che DMARC fallisca. Riporta autenticazione e allineamento separatamente e usa l'attuale procedura di individuazione del dominio invece di un confronto fisso sulle ultime due etichette.

Testa la configurazione MAIL FROM specifica del provider

La configurazione del provider determina quale identità SPF appare effettivamente in trasmissione. Amazon SES, per esempio, documenta un dominio MAIL FROM personalizzato che richiede un proprio record MX e un proprio record TXT SPF. Se l'MX del dominio personalizzato è configurato male, SES può ripiegare su un dominio MAIL FROM amazonses.com che dipende dalla regione, oppure rifiutare l'invio, a seconda del comportamento configurato. Questo fallback può cambiare l'allineamento DMARC anche quando l'indirizzo From visibile resta invariato. Per qualsiasi provider, annota il dominio di return path configurato, i valori DNS richiesti, il comportamento di fallback, le regioni di invio e i responsabili. Dopo una modifica al DNS o al provider, attendi che le risposte in cache pertinenti scadano, poi ripeti la valutazione DNS e gli invii controllati. Non copiare l'include di un fornitore nel dominio From visibile, a meno che quella non sia l'identità effettiva e l'inventario completo dei mittenti del dominio lo giustifichi.

Usa un audit SPF riproducibile durante le modifiche

Tieni una riga per ogni percorso di invio con responsabile, applicazione, classe di messaggi, dominio From visibile, dominio MAIL FROM, dominio HELO, intervalli di origine previsti, dipendenza dal provider e data dell'ultimo test controllato. Salva ogni controllo SPF con il record selezionato, la traccia ricorsiva, il numero di query DNS, il meccanismo corrispondente, il risultato, la decisione sull'allineamento e un identificatore di test non sensibile. Durante una migrazione, mantieni autorizzate sia le vecchie sia le nuove origini legittime solo per la finestra di transizione necessaria, verifica il nuovo percorso, poi rimuovi deliberatamente le autorizzazioni obsolete. Monitora gli errori di autenticazione permanenti e temporanei invece di reagire solo ai rifiuti. Ripeti l'audit dopo cambi di provider, spostamenti di pool IP, modifiche ai domini, interventi sul DNS o nuove applicazioni. Questo flusso intercetta sia le policy troppo restrittive, che bloccano percorsi legittimi, sia quelle troppo ampie, che mantengono autorizzazioni inutilizzate.

Verifica SendHQ con lo stesso standard di evidenza

SendHQ documenta che un invio diretto deve usare un indirizzo su un dominio del workspace verificato. Questo verifica l'identità del mittente, ma non sostituisce una valutazione SPF. Un messaggio SendHQ controllato richiede comunque la stessa traccia DNS, l'ispezione delle intestazioni ricevute, il risultato SPF e il controllo dell'allineamento DMARC descritti sopra.

Domande frequenti

Fonti

• RFC 7208: Sender Policy Framework (SPF) — IETF
• RFC 5321: Simple Mail Transfer Protocol (SMTP) — IETF
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
• Usare un dominio MAIL FROM personalizzato in Amazon SES — Amazon Web Services
• Contratto OpenAPI di SendHQ — SendHQ