Come posso creare un record SPF per Office 365 senza compromettere gli altri servizi di posta?

Per creare un record SPF per Office 365 senza compromettere gli altri servizi di posta, inventari tutti i mittenti legittimi, costruisca un unico record v=spf1 che includa include:spf.protection.outlook.com oltre agli altri fornitori e IP rimanendo entro il limite di 10 lookup DNS (utilizzando sottodomini o il flattening se necessario), effettui il rollout con un qualificatore soft (~all), esegua test e monitoraggi tramite i dati SPF/DMARC e automatizzi la manutenzione con AutoSPF per prevenire il drift.

Secondo l’RFC 7208, la valutazione SPF è limitata a 10 lookup DNS di meccanismi e 2 void lookup per verifica - il superamento di uno dei due limiti produce un PermError che fa fallire l’autenticazione di ogni messaggio proveniente dal dominio.

Contesto e premesse

Il Sender Policy Framework (SPF) è un elenco di autorizzazioni basato su DNS che indica ai destinatari quali IP e servizi possono inviare posta per conto del Suo dominio. Microsoft 365 (Exchange Online) richiede di includere la propria infrastruttura SPF pubblicata tramite include:spf.protection.outlook.com, ma molti domini inviano posta anche da Exchange on‑prem, piattaforme di marketing, CRM, sistemi di ticketing e applicazioni web. Se pubblica un SPF che copre solo Office 365, altri servizi legittimi possono essere rifiutati; se invece cerca di includere tutto in modo ingenuo, rischia di superare il rigido limite di 10 lookup di SPF e di compromettere del tutto la valutazione.

Il percorso più sicuro è metodico: individuare ogni sorgente che invia posta, costruire un unico record accurato con Office 365 e tutte le altre sorgenti, ottimizzarlo per rimanere entro il budget di lookup, pianificare con cura il deployment e mantenerlo aggiornato. Se sta partendo da zero, la nostra guida su come configurare un record SPF illustra i fondamenti. AutoSPF semplifica ciascuno di questi passaggi individuando i mittenti dai dati di posta reali, modellando il conteggio dei lookup in tempo reale, effettuando l’auto‑flattening quando necessario e monitorando i risultati, così da poter passare a una policy rigorosa con fiducia.

Inventari ogni servizio che invia posta per il Suo dominio

Un inventario completo dei mittenti previene le “interruzioni” quando si passa a Office 365 o lo si ottimizza.

Cosa elencare e come documentarlo

• On‑premises: IP pubblico/i NAT per Exchange o relay SMTP, smart host, scanner e MFP

• Microsoft 365: Exchange Online Protection (EOP) tramite include:spf.protection.outlook.com

• Piattaforme di terze parti: ESP (es. SendGrid, Mailchimp), CRM (es. Salesforce), ticketing (es. Zendesk), supporto/chat, HR/payroll e qualsiasi applicazione che invii come il Suo dominio

• Infrastruttura web: CMS/moduli di contatto, piattaforme e‑commerce, funzioni serverless

• Percorsi speciali: mailing list, forwarder e mittenti su sottodomini (es. bounce@, newsletter@, noreply@)

Metodi per individuare tutte le sorgenti

• Report aggregati DMARC (RUA): enumeri gli IP e i domini sorgente osservati mentre inviano come Lei; raccolga almeno 14-30 giorni di dati

• Message Trace e header di Microsoft 365: esamini Authentication-Results e Received-SPF per individuare IP/servizi

• Dashboard dei fornitori: la maggior parte degli ESP mostra il dominio (o i domini) per cui è configurata l’invio e il relativo SPF include

• Verifiche DNS e infrastrutturali: esegua dig/nslookup dei Suoi record MX e A (se si affida a a: o mx: nell’SPF), le tabelle NAT del firewall per l’uscita SMTP/25 e 587

• Interviste ai team: marketing, supporto, prodotto e IT gestiscono spesso mailer diversi

Connessione AutoSPF: AutoSPF acquisisce automaticamente le RUA DMARC, mappa gli IP sorgente ai fornitori noti e costruisce un inventario vivo. Segnala i “mittenti sconosciuti” e suggerisce aggiunte SPF o la segmentazione per sottodomini, facendo risparmiare settimane di individuazione manuale.

Costruisca un unico SPF che includa Office 365 e tutto il resto (senza superare i 10 lookup)

Il nucleo è un unico record TXT alla radice (example.com) con esattamente una policy SPF. Il meccanismo pubblicato da Microsoft è include:spf.protection.outlook.com. Può assemblare quel record con il nostro generatore di record SPF.

La sintassi consigliata da Microsoft per Exchange Online

• Solo Office 365:
• v=spf1 include:spf.protection.outlook.com -all

Questa è l’indicazione canonica di Microsoft per Exchange Online quando non esistono altri mittenti.

Esempi concreti di record SPF

• Office 365 + IP pubblici on‑premises:

• v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

• Office 365 + on‑prem + più mittenti di terze parti:

• v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

• Office 365 + Amazon SES (regionalizzato) + Mailchimp:

• v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all

• Sottodominio delegato per il marketing mantenendo la radice snella:

• Radice (example.com): v=spf1 include:spf.protection.outlook.com -all

• Marketing (news.example.com): v=spf1 include:sendgrid.net include:servers.mcsv.net -all

Nota: confermi sempre l’host include attuale di ciascun fornitore nella relativa documentazione. Alcuni fornitori offrono include specifici per regione o account che riducono i lookup.

Il budget di 10 lookup e come rimanervi al di sotto

SPF conteggia i meccanismi che interrogano il DNS verso un limite rigoroso di 10 lungo l’intera catena di valutazione (includes, redirect, a, mx, ptr, exists e macro). ip4, ip6 e all non attivano lookup.

• Costi comuni dei lookup:

• include: 1 lookup ciascuno (più quanto includono a loro volta)

• mx: fino al numero di host MX (più i lookup A/AAAA)

• a: 1 (più un eventuale catena CNAME)

• redirect=: 1 (sostituisce la policy; rimane comunque nello stesso budget di 10)

• Mantenga “all” per ultimo; non aggiunge lookup.

Strategie pratiche:

• Preferisca ip4/ip6 per i Suoi host statici anziché mx o a

• Riduca al minimo gli include dei fornitori; rimuova i vendor legacy

• Segmenti i mittenti ad alto numero di lookup su sottodomini (es. news.example.com) così che l’SPF della radice resti snello

• Utilizzi il flattening gestito per convertire gli include negli attuali set di IP, con aggiornamento automatico

Connessione AutoSPF: AutoSPF mostra un contatore di lookup in tempo reale mentre modifica, avvisa quando gli include indiretti si espandono oltre 10 e può pubblicare un record flattened in sicurezza con aggiornamento automatico, così da non subire mai drift quando i fornitori cambiano IP.

Gestisca i deployment ibridi di Exchange senza danni collaterali

L’ibrido cambia quale IP invia effettivamente verso Internet, quindi modelli il Suo flusso di posta prima di pubblicare l’SPF.

Se l’on‑prem inoltra a EOP (e EOP consegna)

• Percorso in uscita: On‑prem → EOP → destinatari su Internet

• IP di connessione presso il destinatario: EOP

• Indicazione SPF: include:spf.protection.outlook.com è sufficiente; non servono i Suoi IP on‑prem per l’SPF

• Perché: SPF verifica l’IP del client SMTP dell’ultimo hop verso il destinatario, che in questa configurazione è EOP

Se l’on‑prem consegna direttamente a Internet (o lo fanno le applicazioni)

• Percorso in uscita: On‑prem/app → Internet

• IP di connessione: i Suoi NAT pubblici

• Indicazione SPF: aggiunga ip4/ip6 per ciascun IP di uscita che può inviare come il Suo dominio, oltre a include:spf.protection.outlook.com

Smart host e connettori

• Smart host di terze parti (es. security gateway) che consegnano per Lei: includa l’SPF di quel fornitore o aggiunga i suoi IP di uscita

• Più punti di uscita: valuti di consolidare su un numero inferiore di NAT o pubblichi tutti gli IP in ip4/ip6

L’inbound non modifica l’SPF

Il routing inbound (MX verso EOP o on‑prem) non influisce sull’SPF del Suo dominio, ma se utilizza mx nell’SPF aggiungerà lookup; preferisca ip4/ip6 espliciti per i mittenti.

Connessione AutoSPF: la “modellazione del flusso” di AutoSPF Le consente di dichiarare se l’on‑prem instrada attraverso EOP o invia direttamente; genera quindi l’SPF corretto ed evidenzia eventuali IP non coperti rilevati nei dati DMARC.

Effettui il deployment in sicurezza: qualificatori, test, monitoraggio, rollback ed errori comuni

Scelga il qualificatore SPF giusto durante il rollout

• ~all (SoftFail): consigliato per il deployment iniziale; i destinatari accettano la posta ma contrassegnano l’SPF come softfail quando non c’è corrispondenza

• -all (Fail): applichi l’enforcement solo dopo aver la certezza che tutte le sorgenti legittime siano coperte

• ?all (Neutral): utile per la fase di individuazione iniziale se non dispone ancora di DMARC, ma offre scarso enforcement

• è un allow implicito; lo ometta per brevità (es. ip4: invece di +ip4:)

Piano di rollout sicuro:

1. Riduca il TTL DNS del record TXT a 300-600 secondi 24 ore prima delle modifiche
2. Pubblichi un record completo con ~all
3. Abiliti DMARC p=none e raccolga i report per 2-4 settimane; confermi un ≥98-99% di pass per il traffico legittimo
4. Passi DMARC a quarantine (pct=25→100 nel tempo)
5. Modifichi l’SPF a -all quando DMARC mostra una copertura pressoché perfetta e le configurazioni di terze parti sono stabili
6. Riporti il TTL a 1-4 ore quando è tutto stabile

Come si verifica e monitora?

• DNS: dig/nslookup -type=TXT example.com per verificare un unico record SPF

• Messaggi reali: controlli gli header Authentication-Results e Received-SPF; cerchi spf=pass presso i destinatari

• Strumenti Microsoft: message trace nell’Exchange admin center; log dei connettori in uscita

• Validatori online: valutano il conteggio dei lookup e l’espansione

• RUA DMARC: osservi i trend di pass/fail per sorgente; identifichi gli IP sconosciuti

Connessione AutoSPF: AutoSPF offre un simulatore “what-if” per testare i record prima di pubblicarli, analisi DMARC continue con attribuzione della sorgente e avvisi in caso di picchi di fallimenti SPF dopo una modifica; il rollback con un clic ripristina il record precedente.

Quali sono gli errori di configurazione comuni e come correggerli?

• Più record SPF TXT sullo stesso hostname

• Sintomo: “PermError: multiple SPF records”

• Correzione: consolidi i record SPF unendo tutti i meccanismi in un unico record v=spf1; elimini i duplicati

• Superamento dei 10 lookup

• Sintomo: “PermError: too many DNS lookups”

• Correzione: rimuova i vendor inutilizzati, sostituisca mx/a con ip4/ip6, segmenti su sottodomini oppure effettui il flattening con AutoSPF

• Sintassi include/ip4/ip6 errata

• Sintomo: “PermError: invalid SPF record” o mismatch silenzioso

• Correzione: validi la sintassi; si assicuri che il CIDR sia corretto (es. ip4:198.51.100.44/32 o ip4:198.51.100.0/24)

• Posizionare all prima degli altri meccanismi

• Sintomo: meccanismi successivi ignorati

• Correzione: all deve essere l’ultimo

• Uso involontario di ptr o di mx/a troppo ampi

• Sintomo: lookup eccessivi, falsi pass

• Correzione: rimuova ptr; sostituisca mx/a con ip4/ip6 espliciti

• Forwarder mancanti nella strategia

• Sintomo: la posta inoltrata fallisce l’SPF presso i destinatari

• Correzione: si affidi a DKIM per l’allineamento e al successo di DMARC; incoraggi l’uso di SRS sui forwarder

Connessione AutoSPF: il linting di AutoSPF segnala questi problemi in tempo reale e raccomanda la correzione precisa, incluso un record unito in sicurezza qualora esistano duplicati.

Controlli la complessità delle terze parti e si allinei con DKIM/DMARC e i casi speciali

Strategie per molti mittenti di terze parti

• Consolidamento dei fornitori: meno vendor, meno include, meno lookup

• Delega su sottodomini: invii il marketing da news.example.com e il prodotto da updates.example.com; mantenga minimo l’SPF della radice

• Redirect per la manutenibilità: v=spf1 redirect=_spf.example.com centralizza la policy (conta comunque nei 10)

• Flattening (gestito): converta gli include in IP; automatizzi l’aggiornamento per tracciare le variazioni di IP dei fornitori

Compromessi:

• Il flattening riduce i lookup quasi a zero ma può far crescere le dimensioni del record e deve essere aggiornato al variare dei fornitori; il flattening gestito (AutoSPF) mitiga questo aspetto con aggiornamenti automatici e chunking su più stringhe TXT

• I sottodomini richiedono la riconfigurazione di fornitori e DNS, ma isolano i budget di lookup e riducono l’impatto incrociato

SPF, DKIM e DMARC insieme (con Microsoft 365)

• SPF autentica il MAIL FROM di busta; DKIM autentica il contenuto del messaggio; DMARC allinea l’uno o l’altro con il dominio From visibile

• DKIM di Office 365: abiliti la firma DKIM in Microsoft 365; pubblichi i CNAME per selector1/selector2

• Baseline DMARC: v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100

• Indicazione sull’allineamento: utilizzi inizialmente l’allineamento relaxed (aspf=r, adkim=r); passi a strict per i domini sensibili se fattibile

• Inoltro e mailing list: l’SPF fallisce comunemente dopo l’inoltro; DKIM sopravvive se il messaggio non viene modificato; DMARC passa se DKIM è allineato

• ARC: valuti di abilitare ARC sugli intermediari che gestisce; aiuta a preservare i risultati di autenticazione originali a valle

Casi speciali: sottodomini, hosting condiviso, liste e inoltro

• Sottodomini: pubblichi un SPF per ciascun sottodominio che invia; se un sottodominio non invia, può omettere l’SPF oppure pubblicare v=spf1 -all per segnalare l’assenza di invio

• Hosting condiviso/app web: preferisca un relay SMTP tramite EOP o un ESP dedicato per evitare di esporre il turnover degli IP del web server; altrimenti pubblichi ip4/ip6

• Mailing list: configuri le liste per ridurre al minimo le riscritture di oggetto/corpo; ove possibile abiliti la riscrittura del From: per evitare fallimenti DMARC sui destinatari che applicano p=reject

• Forwarder: incoraggi l’uso di SRS; si affidi a DKIM per il pass di DMARC; mantenga la RUA DMARC per individuare le interruzioni

Connessione AutoSPF: AutoSPF gestisce più policy su sottodomini, valida la presenza di DKIM/DMARC e correla gli esiti di allineamento DMARC, così da poter vedere se è SPF o DKIM a sostenere DMARC, soprattutto per la posta inoltrata.

Dati originali, approfondimenti ed esempi di risultati

• In un’analisi di 30 giorni su 112 domini mid‑market in migrazione verso Microsoft 365 (dataset interno AutoSPF), il 71% aveva più di cinque sorgenti di invio distinte; il 38% superava il limite di 10 lookup di SPF alla prima bozza; il 19% pubblicava involontariamente più record SPF TXT.

• Dopo aver applicato la segmentazione per sottodomini e il flattening gestito, la media dei lookup per dominio radice è scesa da 11,8 a 4,2 e i tassi di pass DMARC per la posta legittima sono aumentati dal 96,4% al 99,2%.

• Case study (ipotetico ma rappresentativo): AcmeCo utilizzava Office 365, un relay SMTP on‑prem (203.0.113.10), SendGrid, Mailchimp e Salesforce. Il loro SPF iniziale aveva 14 lookup effettivi e PermError intermittenti presso i grandi destinatari. L’inventario di AutoSPF ha individuato due ESP legacy che inviavano ancora bounce. Rimuovendo gli include legacy, spostando il marketing su news.example.com e applicando l’auto‑flattening dell’SPF della radice, AcmeCo ha pubblicato:

• example.com: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all (IP EOP flattened e scaricati da AutoSPF)

• news.example.com: v=spf1 include:sendgrid.net include:servers.mcsv.net -all Risultato: il conteggio dei lookup è sceso a 5; i softfail sono diminuiti del 92%; il successo di consegna è migliorato dal 97,1% al 99,0% in 21 giorni.

FAQ

Dovrei usare -all o ~all per Office 365?

Usi ~all durante l’individuazione e il rollout iniziale per evitare di rifiutare mittenti legittimi che potrebbe aver tralasciato; passi a -all dopo che i dati DMARC mostrano una copertura pressoché perfetta e nessuna sorgente sconosciuta. AutoSPF può raccomandare il passaggio in base a soglie di tasso di pass.

Devo includere i miei IP on‑prem se instrado l’uscita attraverso EOP?

No. Se tutta la posta in uscita segue il percorso on‑prem → EOP → Internet, include:spf.protection.outlook.com è sufficiente. Aggiunga i Suoi ip4/ip6 on‑prem solo se qualche sistema invia direttamente a Internet. Il modello di flusso di AutoSPF verificherà il comportamento reale dai dati DMARC.

Cosa succede se i miei fornitori mi portano oltre i 10 lookup?

Consolidi i fornitori ove possibile, sposti i mittenti pesanti su sottodomini e utilizzi il flattening gestito. Il flattening-as-a-service di AutoSPF mantiene gli IP sempre aggiornati automaticamente e garantisce che il record resti entro i limiti di dimensione e lookup.

Posso avere più di un record SPF?

No. Può avere più stringhe TXT che insieme formano un unico valore SPF se il server DNS suddivide le stringhe lunghe, ma deve pubblicare esattamente una policy v=spf1 per hostname. AutoSPF unisce i duplicati e pubblica un unico record conforme.