La vostra configurazione SPF funziona bene con un solo mittente. Poi aggiungete Google Workspace, Mailchimp, Zendesk e un'API transazionale, e Microsoft inizia a respingere i messaggi con 550 5.7.515. Il record che sembrava pulito al lancio ha appena superato il limite di 10 interrogazioni, e ora tutti i messaggi in uscita falliscono silenziosamente l'autenticazione.
Questa è la trappola. SPF ha un tetto rigido incorporato nel protocollo, che molti team raggiungono quando aggiungono il terzo o quarto servizio di invio. La soluzione abituale, incollare un altro include:, smette di funzionare proprio quando serve di più. Per le basi della sintassi, iniziate dalla nostra guida sul record SPF per email. Questo articolo riguarda l'architettura: progettare una configurazione SPF capace di gestire più mittenti, resistere ai cambi di fornitore e non richiedere riscritture ogni trimestre.
Perché la configurazione SPF si rompe con più mittenti
La configurazione SPF si rompe perché RFC 7208 limita la valutazione a 10 interrogazioni DNS per record. Ogni meccanismo include, a, mx, exists e redirect conta, e il calcolo è ricorsivo. Se l'include di un fornitore ne contiene altri tre, tutti consumano il budget. A 11 i server destinatari restituiscono PermError e possono rifiutare il messaggio.
Lo schema del problema è quasi sempre uguale. Iniziate con due includes e molto margine. Il marketing aggiunge HubSpot, l'assistenza adotta Freshdesk e il reparto tecnico usa SendGrid per gli avvisi dell'applicazione. La catena di ogni fornitore è più profonda di quanto suggerisca la documentazione. All'improvviso raggiungete 12 interrogazioni e Google restituisce 550 5.7.26 per ogni messaggio.
| Meccanismo | Consuma un'interrogazione? | Nota operativa |
|---|---|---|
include: | Sì, comprese quelle annidate | Standard per i fornitori, ma con annidamento imprevedibile |
ip4: / ip6: | No | Senza costo di interrogazione; usatelo per mittenti statici sotto il vostro controllo |
mx | Sì | Spesso abusato; sostituitelo con ip4 quando possibile |
a | Sì | Inefficiente per SPF; preferite ip4 |
ptr | Sì | Obsoleto. Non usatelo |
redirect | Sì | Trasferisce la valutazione al record di un altro dominio |
-all / ~all | No | Chiusura della policy; includetene sempre una |
Il calcolo non è complicato. Rimane semplicemente invisibile finché qualcosa non si rompe. Ecco perché una configurazione SPF per più mittenti deve iniziare dall'architettura, non dal copia e incolla.
Controllate il record SPF prima di aggiungere altro
Il primo passo di ogni configurazione SPF con più mittenti è rimuovere ciò che non dovrebbe più esserci. Molti domini conservano includes di servizi disdetti mesi o anni prima, e ciascuno spreca una parte del budget di interrogazioni. Prima pulite, poi costruite.
Controllate ciò che è realmente pubblicato:
dig txt yourdomain.com +shortSeguite quindi ogni include per scoprirne la profondità:
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortConfrontate il risultato con i report aggregati DMARC. Se nessun traffico proviene davvero dagli IP di un fornitore, quell'include è soltanto un peso. Eliminatelo.
Tre miglioramenti rapidi durante il controllo:
- Sostituite
mxcon l'IP reale usandoip4:; risparmierete un'interrogazione. - Rimuovete gli includes dei servizi che non usate più.
- Cercate record SPF duplicati. Due record TXT che iniziano con
v=spf1sullo stesso dominio provocano immediatamente PermError.
Queste operazioni da sole liberano spesso 2-3 interrogazioni. Per una procedura dettagliata, consultate la nostra guida alla configurazione del record SPF.
Segmentazione per sottodomini: la configurazione SPF che cresce
La configurazione SPF che gestisce in modo affidabile più mittenti senza raggiungere il tetto di 10 interrogazioni si basa sulla segmentazione per sottodomini. SPF viene valutato sul dominio Return-Path, non sull'intestazione From visibile. Spostate i mittenti non aziendali su sottodomini, e ogni flusso riceve un nuovo budget di 10 interrogazioni.
Ecco il modello:
Dominio radice: solo messaggi tra persone
Mantenete pulito il dominio radice. Inserite soltanto il provider principale delle caselle.
v=spf1 include:spf.trekmail.net -allUn include e un'interrogazione. La posta della direzione non si interrompe perché il marketing ha aggiunto un nuovo strumento.
Sottodominio marketing: campagne e newsletter
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot e Mailchimp consumano le interrogazioni di news.example.com, non quelle del dominio radice. Se questo sottodominio subisce limitazioni, la posta aziendale continua a circolare.
Sottodominio di assistenza: sistemi di ticket
; help.example.com
v=spf1 include:mail.zendesk.com -allSottodominio transazionale: avvisi e ricevute delle applicazioni
; alerts.example.com
v=spf1 include:amazonses.com -allQuando Zendesk invia come support@help.example.com, il destinatario interroga il DNS di help.example.com. Il record SPF del dominio radice non viene mai consultato. Questo è lo scopo.
| Vecchio metodo | Nuovo metodo |
|---|---|
| Tutti i mittenti ammassati in un solo record SPF radice | Il dominio radice contiene soltanto il provider principale delle caselle |
| Un cambio di fornitore può interrompere tutti gli invii | Gli errori restano isolati nel sottodominio interessato |
| Il budget di interrogazioni è condiviso da tutti | Ogni sottodominio ottiene il proprio budget di 10 interrogazioni |
| SPF va riscritto a ogni nuovo strumento | L'architettura resiste ai cambi di fornitore |
Appiattimento SPF: l'ultima risorsa
Se i requisiti aziendali impongono che tutta la posta provenga dal dominio radice, senza consentire sottodomini, l'appiattimento SPF offre una via d'uscita. Risolve gli includes dei fornitori in indirizzi IP grezzi e li elenca come meccanismi ip4:, che non consumano interrogazioni. Funziona, ma crea un problema di manutenzione.
Il rischio è l'obsolescenza. I fornitori SaaS cambiano regolarmente gli IP. Se SendGrid aggiunge domani un nuovo intervallo e il record appiattito contiene ancora gli indirizzi di ieri, i messaggi in uscita iniziano a fallire SPF. Non appiattite manualmente il record, a meno che possiate controllarlo ogni giorno. Utilizzate un servizio SPF dinamico automatizzato che sorvegli gli IP dei fornitori e aggiorni il record TXT a intervalli stabiliti.
L'appiattimento è un espediente, non un'architettura. La segmentazione per sottodomini è la soluzione strutturale. Ricorrete all'appiattimento solo dopo aver davvero esaurito ogni altra possibilità.
Verificate che la configurazione SPF funzioni
Dopo ogni modifica a SPF, controllate ciò che il DNS pubblico restituisce realmente. Non affidatevi alla dashboard del registrar, a pannelli con dati nella cache o agli indicatori verdi nell'interfaccia di un fornitore. Interrogate direttamente il dominio e verificate che esista esattamente un record SPF valido per ogni nome host.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortDovete ottenere un record TXT che inizi con v=spf1 per ogni nome host. Non due. Nemmeno uno attuale insieme a un residuo di una migrazione avvenuta due anni prima.
Inviate poi un messaggio di prova a Gmail, apritelo, fate clic sul menu a tre punti, scegliete «Mostra originale» e cercate:
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSQualsiasi risultato FAIL o SOFTFAIL indica un problema nella configurazione SPF. Correggetelo prima di inviare grandi volumi. Se state analizzando anche difficoltà di reputazione che vanno oltre SPF, la nostra guida sui segnali di reputazione del mittente presenta il quadro generale.
Come TrekMail semplifica SPF su più domini
Configurare SPF per un dominio è fastidioso. Farlo per 50 domini di clienti, ciascuno con fornitori di invio e DNS diversi e vari livelli di incuria, consuma molto tempo. TrekMail mantiene l'impronta SPF piccola e prevedibile, lasciando spazio per tutto il resto.
L'include principale è include:spf.trekmail.net. Un'interrogazione. Nessun reindirizzamento annidato e nessuna catena di espansione imprevedibile. Confrontatelo con Microsoft 365, che spesso consuma 2-3 interrogazioni tramite reindirizzamenti interni, o con Google Workspace, il cui comportamento può variare per area geografica.
Per chi lavora da solo, la configurazione SPF rimane semplice anche dopo aver aggiunto uno strumento di marketing. Per i team, diminuiscono gli errori DNS durante l'attivazione. Per le agenzie che gestiscono decine o centinaia di domini di clienti, diventa un modello ripetibile: aggiungete l'include TrekMail, separate gli altri fornitori in sottodomini ed evitate il problema del limite di interrogazioni. Se gestite la posta di molti marchi, consultate l'architettura generale dell'hosting email multidominio.
Il controllo dello stato DNS di TrekMail segnala anche i conflitti SPF nella dashboard prima che provochino guasti in produzione. Vedete il problema prima dei clienti. Per la configurazione completa, consultate i record DNS richiesti nella documentazione.
Conclusione: progettate SPF una volta e smettete di modificarlo
Una buona configurazione SPF inizia dall'architettura, non dalla sintassi. Controllate gli includes obsoleti. Distribuite i mittenti tra sottodomini affinché ogni flusso abbia il proprio budget di 10 interrogazioni. Mantenete pulito il dominio radice: un provider di caselle, un include e un -all. Verificate con dig, non con le dashboard.
Se volete applicare questo modello a un dominio o a cento senza costi per utente, TrekMail offre hosting multidominio a prezzo fisso, un unico include SPF pulito, spazio condiviso e un controllo DNS che individua presto gli errori di configurazione. Secondo le condizioni attuali, il piano Nano copre 10 domini con il vostro SMTP, senza carta di credito e gratuitamente. I piani a pagamento partono da $3.50/month con Starter e SMTP gestito e includono una prova gratuita di 14-day (carta richiesta). Consultate i piani vigenti su trekmail.net/pricing.
