termine · sintassi del record spf
Cos'è la sintassi del record SPF e come influisce sulle email dell'applicazione?
La sintassi del record SPF è una policy DNS TXT con termini separati da spazi che inizia con v=spf1, seguita da meccanismi che corrispondono alle sorgenti di invio autorizzate e da un eventuale modificatore redirect o di spiegazione. Un meccanismo può avere +, -, ~ o ? come qualificatore del risultato; tra i meccanismi comuni ci sono ip4, ip6, a, mx, include, exists e all. L'ordine conta, perché la valutazione si ferma al primo meccanismo corrispondente. Pubblica una sola policy SPF per ogni dominio esatto, mantieni i termini che generano query DNS entro il limite del protocollo, testa ogni mittente di busta reale e ricorda che SPF autentica l'identità SMTP, non automaticamente il dominio From visibile né l'arrivo in inbox.
Un record SPF è un'espressione di policy ordinata
L'RFC 7208 definisce un record SPF come una stringa DNS TXT il cui primo termine è v=spf1. I termini successivi, separati da spazi, sono meccanismi, che possono corrispondere, e modificatori, che cambiano l'elaborazione. La valutazione procede da sinistra a destra e si ferma al primo meccanismo corrispondente, quindi l'ordine esprime la policy. Un record tipico potrebbe autorizzare due intervalli di indirizzi fissi, includere la policy di un provider e terminare con -all. Non incollare questo schema senza modifiche: il record corretto dipende dalle identità SMTP MAIL FROM o HELO esatte e dalle sorgenti di invio reali. Censisci prima provider applicativi, server di posta, strumenti di supporto, piattaforme di identità, sistemi di marketing, percorsi di inoltro e mittenti di disaster recovery. Pubblica la policy sul dominio valutato, non automaticamente sul dominio From visibile. Un record sintatticamente valido può comunque autorizzare le sorgenti sbagliate, omettere un flusso di produzione o superare i limiti di valutazione DNS.
I qualificatori associano la corrispondenza di un meccanismo a un risultato SPF
Un meccanismo può iniziare con un qualificatore: + per pass, - per fail, ~ per softfail o ? per neutral. Se non compare alcun qualificatore, è implicito +. Il qualificatore si applica solo quando quel meccanismo corrisponde. Non cambia il fatto che i termini successivi vengano valutati quando il meccanismo non corrisponde. I team si concentrano spesso sul termine all finale, ma anche ogni meccanismo include, indirizzo, a, mx o exists precedente ha un qualificatore e può terminare la valutazione. Esegui una revisione esplicita invece di presumere che ~all significhi modalità di test o che -all dimostri che ogni sorgente è nota. Un risultato fail è una prova per il destinatario sull'identità SMTP e sull'IP valutati, non un ordine universale di eliminare la posta. I destinatari applicano policy locali. Neutral e softfail non sono esiti di autorizzazione. Registra il risultato previsto per le sorgenti autorizzate, non autorizzate e temporaneamente non risolte e verificalo con fixture controllate di IP e identità.
I meccanismi basati su indirizzi sono diretti ma richiedono una titolarità
I meccanismi ip4 e ip6 autorizzano gli intervalli di rete corrispondenti, espressi con la sintassi specifica del protocollo e una lunghezza di prefisso facoltativa. Evitano lookup di indirizzi aggiuntivi durante la valutazione, ma possono diventare obsoleti quando le reti di uscita cambiano. Usa indirizzi di invio pubblici, mai indirizzi privati del runtime, e mantieni gli intervalli ristretti quanto consentito dal failover operativo. Ogni intervallo dovrebbe avere un responsabile, un sistema di origine, un ambiente, una procedura di modifica e una data di revisione. Il meccanismo a risolve un nome A o AAAA, per impostazione predefinita il dominio SPF corrente, a meno che non venga indicato un altro domain-spec. Il meccanismo mx risolve gli host MX e i loro indirizzi. Questi meccanismi aggiungono lavoro DNS e possono autorizzare infrastruttura che cambia al di fuori dei rilasci dell'applicazione. Non usare a o mx come scorciatoia, a meno che tutti gli indirizzi risolti siano intenzionalmente autorizzati a inviare con quella esatta identità SMTP. Monitora le modifiche e testa sia i percorsi IPv4 sia quelli IPv6.
Include valuta un'altra policy, non un frammento di testo
Il meccanismo include valuta la policy SPF del dominio indicato e corrisponde quando questa valutazione annidata restituisce pass. Non incolla meccanicamente i termini nella stringa corrente, e gli altri esiti annidati hanno effetti definiti. Usa include solo quando l'organizzazione a cui fai riferimento documenta esplicitamente quel dominio per il tuo rapporto di invio. Il dominio del sito web di un provider, il suo dominio MX o il dominio From visibile non sono automaticamente il suo include SPF. Gli include creano dipendenze operative: una modifica al record del provider può alterare l'autorizzazione, aggiungere lookup DNS annidati o produrre errori temporanei e permanenti. Registra vendor, servizio, dominio include esatto, fonte contrattuale, responsabile e piano di rimozione. Testa la policy risultante dall'IP di invio effettivo del provider e dal tuo dominio di busta. Non appiattire mai gli include dei provider in elenchi di IP copiati, a meno che tu non accetti anche la responsabilità di seguire ogni modifica degli indirizzi del provider e di preservare la semantica originale.
All, redirect ed explanation hanno ruoli diversi
Il meccanismo all corrisponde sempre e di norma si trova in fondo; i termini successivi non possono influire sulla valutazione. Il suo qualificatore determina il risultato per le sorgenti non corrisposte in precedenza. Il modificatore redirect indica a SPF di usare la policy di un altro dominio quando nessun meccanismo del record corrente ha trovato corrispondenza. Redirect non equivale a include: include è un meccanismo nell'ordine, mentre redirect sostituisce la decisione finale di policy alle condizioni previste. Un record non dovrebbe contenere più modificatori redirect. Il modificatore exp può fare riferimento a una spiegazione per un risultato fail, ma non autorizza la posta e introduce ulteriori considerazioni operative e di privacy. Mantieni le spiegazioni generiche ed evita dati su mittenti o destinatari. Scegli redirect quando più domini condividono intenzionalmente un'intera policy con una gestione coordinata. Scegli include quando aggiungi le sorgenti autorizzate di un provider all'interno di una policy locale più ampia. Testa i percorsi senza corrispondenza, non solo i pass attesi.
Evita ptr e tratta exists e le macro come strumenti avanzati
L'RFC 7208 afferma che il meccanismo ptr non dovrebbe essere usato perché è lento, inaffidabile e oneroso. Non aggiungere ptr per far superare il controllo a un IP sconosciuto. Il meccanismo exists può eseguire un test di esistenza DNS usando un domain-spec, e le macro SPF possono espandere componenti dell'identità e della connessione nei campi supportati. Questi strumenti possono esprimere autorizzazioni delegate o per singolo cliente, ma aumentano complessità, lavoro DNS, esposizione della privacy e modalità di errore. La sintassi delle macro non è un templating arbitrario di stringhe: sono validi solo lettere, trasformatori, delimitatori e contesti definiti. Non inserire mai indirizzi completi dei destinatari, segreti o input illimitati dei tenant nelle query DNS. Se un semplice insieme di intervalli IP di proprietà e di include documentati dei provider può esprimere la policy, preferiscilo. Per le policy avanzate, costruisci fixture deterministiche per più domini, mittenti, famiglie di IP, reverse path nulli, escape delle macro, NXDOMAIN, timeout e risposte DNS inattese prima della produzione.
Rispetta il limite di dieci termini con lookup DNS
L'RFC 7208 limita le implementazioni SPF a dieci termini che generano query DNS durante un singolo controllo, inclusa l'elaborazione pertinente di include, a, mx, ptr, exists e redirect. Gli include annidati contano. La specifica raccomanda anche di limitare a due i void lookup, in cui il DNS restituisce una risposta vuota o un errore di nome. Superare i limiti di elaborazione può produrre un errore permanente invece di un pass. Conta il grafo di valutazione espanso, non solo i termini visibili nella stringa TXT di primo livello. Un solo include di un provider può portare più dipendenze annidate, e un meccanismo mx può attivare lookup di indirizzi per più host. Usa un valutatore conforme agli standard con fixture DNS acquisite, ma esamina anche tu l'albero delle dipendenze. Rimuovi i provider inutilizzati e i meccanismi ridondanti. Evita appiattimenti non sicuri che perdono silenziosamente gli aggiornamenti dei provider. Monitora le modifiche alla policy e lascia margine di lookup per l'evoluzione dei provider invece di andare in produzione esattamente al massimo.
Pubblica esattamente una policy SPF per dominio
L'RFC 7208 usa record DNS TXT per SPF e richiede di selezionare il record che inizia con v=spf1. Più record SPF sullo stesso nome esatto causano un errore permanente invece di combinare le autorizzazioni. Modifica la policy esistente con una gestione coordinata; non aggiungere un secondo record TXT perché un'altra applicazione ha bisogno di accesso. Altri record TXT non correlati possono coesistere sullo stesso nome, ma dovrebbe esistere una sola policy SPF selezionata. Conferma il comportamento del pannello DNS riguardo a virgolette e suddivisione delle stringhe, interroga i server autoritativi, poi resolver ricorsivi indipendenti. Conserva il valore e il TTL precedenti per il rollback. La propagazione DNS non è istantanea e le cache negative possono persistere. Un segno di spunta verde in una dashboard dimostra solo la query osservata e il comportamento del suo parser. Verifica il dominio di busta di produzione esatto dalle intestazioni grezze dei messaggi ricevuti e dai log del provider, inclusi sottodomini e indirizzi di bounce che possono pubblicare policy separate.
Collega la sintassi SPF a DMARC senza confonderli
SPF valuta normalmente il dominio MAIL FROM o l'identità HELO secondo le regole del protocollo. DMARC usa il dominio From RFC 5322 visibile e accetta SPF come uno dei percorsi solo quando il dominio SPF autenticato è allineato con quel dominio visibile. Il return-path di un provider può quindi superare SPF pur restando non allineato per DMARC. Al contrario, un pass DKIM allineato può soddisfare DMARC quando SPF fallisce o non è allineato. Registra separatamente risultato SPF, dominio valutato, IP di connessione, From visibile, risultati DKIM, allineamento ed esito DMARC. L'inoltro cambia spesso l'IP di connessione e può compromettere SPF anche quando il mittente originale era autorizzato. Non ampliare SPF per includere inoltri arbitrari. Usa DKIM e, dove opportuno, meccanismi di catena autenticata e prove dei destinatari. Un pass SPF non dimostra integrità del messaggio, sicurezza del contenuto, consenso del destinatario, accettazione da parte del server o arrivo in inbox.
Convalida le modifiche con un flusso deterministico
Prima di modificare il DNS, esporta il record attuale ed elenca ogni meccanismo o modificatore con il relativo responsabile e scopo. Analizza il candidato secondo la grammatica dell'RFC 7208, espandi le dipendenze DNS da snapshot controllati, conta i termini che generano lookup e testa fixture IPv4 e IPv6 autorizzate e non autorizzate. Controlla il comportamento degli include annidati per pass, fail, neutral, softfail, errore temporaneo ed errore permanente. Testa la gestione del reverse path nullo tramite HELO, i sottodomini, i return path dei provider e una sorgente che dovrebbe arrivare fino ad all. Pubblica con le normali procedure di gestione delle modifiche, interroga DNS autoritativi e ricorsivi, poi invia messaggi controllati attraverso ogni flusso reale. Conserva l'intestazione Authentication-Results grezza di destinatari attendibili e confrontala con le identità attese. Esegui il rollback in caso di sorgenti di produzione mancanti, selezione di più record, errori per limite di lookup, temperror diffusi o autorizzazioni involontarie. Non fare mai test inviando posta non richiesta.
Configura SPF con SendHQ
SendHQ fornisce una policy SPF TXT nell'ambito della configurazione dell'identità del mittente. Interrompe la configurazione in presenza di policy SPF in conflitto e segnala un valore SPF combinato consigliato anziché sovrascrivere silenziosamente una policy non correlata. Mantieni esattamente una policy SPF selezionabile; consulta la documentazione Domini e DNS per i dettagli su configurazione e correzione.
Domande frequenti
Con cosa deve iniziare un record SPF?
Una policy SPF selezionata dai record DNS TXT inizia con v=spf1, seguita da meccanismi ordinati e da eventuali modificatori, separati secondo la grammatica dell'RFC.
Cosa significano più, meno, tilde e punto interrogativo in SPF?
Sono i qualificatori pass, fail, softfail e neutral per un meccanismo corrispondente. Se omesso, per quel meccanismo è implicito il qualificatore più.
Un dominio può pubblicare due record SPF?
No. Più record v=spf1 selezionati sullo stesso dominio esatto producono un errore SPF permanente; coordina invece le modifiche in un'unica policy.
Qual è il limite di lookup DNS di SPF?
L'RFC 7208 limita un singolo controllo a dieci termini che generano query DNS, compresa l'elaborazione annidata. Conta il grafo delle dipendenze espanso, non solo i termini di primo livello.
Include equivale a copiare un altro record?
No. Include esegue una valutazione SPF annidata e corrisponde in caso di pass. Gli altri risultati e gli errori DNS mantengono il comportamento definito dal protocollo e il relativo rischio operativo.
Un record SPF dovrebbe usare ptr?
No, per la progettazione di nuove policy. L'RFC 7208 afferma che ptr non dovrebbe essere usato perché è lento, inaffidabile e oneroso per i name server.
Un pass SPF significa che DMARC viene superato?
Non automaticamente. DMARC richiede anche che il dominio autenticato da SPF sia allineato con il dominio From visibile, a meno che un DKIM allineato non fornisca il percorso per il pass.
SendHQ configura SPF?
Sì. SendHQ fornisce una policy SPF TXT nell'ambito della configurazione dell'identità del mittente e interrompe la configurazione in presenza di policy SPF in conflitto.