SPF, DKIM e DMARC per SparkPost.
SparkPost (ora parte di Bird, in precedenza MessageBird) autentica il tuo dominio da Configuration → Sending Domains, dove genera una chiave DKIM da pubblicare come record TXT sul tuo dominio di invio. Quella firma DKIM, apposta come d=yourdomain.com, è il meccanismo che ti fa davvero superare DMARC. L'SPF è il punto delicato tipico di SparkPost: per impostazione predefinita, SparkPost invia bounce e busta dal proprio dominio condiviso (sparkpostmail.com), quindi un semplice controllo SPF viene superato sul dominio di SparkPost ma non si allinea mai al tuo. La soluzione è un Bounce Domain personalizzato: un CNAME che punta un tuo sottodominio a sparkpostmail.com e diventa il tuo Return-Path, così si allinea anche l'SPF. Aggiungi un record di policy DMARC e hai tutti e tre, allineati, senza aggiungere nulla al tuo SPF radice.
Perché autenticare SparkPost?
Autenticare il tuo dominio SparkPost non è una formalità: decide se le email transazionali e di marketing ad alto volume raggiungono o meno la posta in arrivo. Da febbraio 2024 Gmail e Yahoo richiedono a ogni mittente di grandi volumi (circa 5.000+ messaggi al giorno) di superare SPF, DKIM e DMARC con allineamento, e nel 2025 Microsoft ha iniziato ad applicare le stesse regole alle caselle consumer Outlook/Hotmail/Live: esattamente i volumi per cui SparkPost è pensato. Finché non autentichi il dominio, SparkPost firma la tua posta con una chiave condivisa e gestisce i bounce da sparkpostmail.com: il tuo indirizzo From non è crittograficamente tuo, la posta non può superare DMARC e la tua reputazione finisce nello stesso calderone di tutti gli altri mittenti non autenticati su quell'infrastruttura. C'è poi una particolarità di SparkPost che rende DKIM irrinunciabile: poiché il Return-Path è di SparkPost per impostazione predefinita, l'SPF viene superato ma non si allinea al tuo dominio, quindi DKIM è l'unico meccanismo che ti fa superare DMARC finché non configuri anche un bounce domain personalizzato. Con DKIM più un bounce domain allinei entrambi i meccanismi a te, togli ai server riceventi ogni dubbio sulla tua identità, fai superare DMARC alla tua posta e costruisci la reputazione di invio a tuo nome invece che nel pool condiviso.
Come funziona davvero SPF con SparkPost
Sulla carta SparkPost è un provider “include”: include:sparkpostmail.com (e include:_spf.sparkpostmail.com, che si risolve nello stesso identico record) esistono entrambi e superano la verifica DNS, ma aggiungere quell'include al tuo SPF radice è una pratica legacy e NON fa superare DMARC. Ecco perché. Il record attivo è v=spf1 exists:%{i}._spf.sparkpostmail.com ~all: una macro exists: che autorizza gli IP in uscita di SparkPost uno per uno (%{i} è l'IP di invio, controllato su una zona wildcard) invece di elencare intervalli ip4: fissi. L'SPF viene sempre valutato sul dominio MAIL FROM della busta / Return-Path e, per impostazione predefinita, quel dominio è sparkpostmail.com, che appartiene a SparkPost. Quindi l'SPF si risolve e viene superato sul dominio di SparkPost, ma non si allinea mai al dominio organizzativo del tuo From, e DMARC conta l'SPF solo quando è allineato. Pubblicare include:sparkpostmail.com sul tuo dominio radice non cambia le cose, perché il tuo dominio radice non è mai il dominio della busta: consuma solo due delle tue dieci ricerche SPF (l'include più il meccanismo exists annidato nel record di sparkpostmail.com) senza alcun vantaggio di allineamento. La strada per un SPF allineato è un Bounce Domain personalizzato: punti un tuo sottodominio (es. bounces.yourdomain.com) a sparkpostmail.com con un CNAME, SparkPost usa quel sottodominio come Return-Path e il controllo SPF viene eseguito sul tuo sottodominio (con allineamento relaxed al tuo dominio organizzativo), ereditando comunque l'SPF di sparkpostmail.com tramite il CNAME. Ecco perché il flusso di SparkPost ti dà un record TXT DKIM e un CNAME per il bounce domain, non una riga SPF da incollare sul dominio radice. Riserva il tuo record SPF radice ai mittenti che mettono davvero il tuo dominio nel Return-Path (Google Workspace, Microsoft 365, un relay che controlli) e lascia che il lavoro di SparkPost lo facciano il CNAME di bounce e DKIM.
Due modi per configurarlo
Bounce domain personalizzato + DKIM (consigliato, allineato)
- Il TXT DKIM con selettore scph firma la posta come d=yourdomain.com: è il meccanismo che supera davvero DMARC
- Un CNAME per il bounce domain personalizzato (es. bounces.yourdomain.com → sparkpostmail.com) allinea al tuo dominio anche l'SPF
- Non aggiunge nessuna ricerca DNS al tuo SPF radice: il record di bounce sta su un sottodominio proprio, non sul dominio radice
- Funziona allo stesso modo su SparkPost US ed EU (in EU basta puntare il CNAME a eu.sparkpostmail.com)
Include nell'SPF radice (legacy, non si allinea)
- Aggiungi tu v=spf1 include:sparkpostmail.com ~all al tuo SPF radice
- La busta è di SparkPost (bounce predefinito = sparkpostmail.com), quindi questo SPF non si allinea mai al tuo dominio
- Non serve a nulla per DMARC: tutto il lavoro lo fanno comunque DKIM e il bounce domain
- Consuma due delle tue 10 ricerche SPF (l'include più il meccanismo exists annidato) senza alcun vantaggio di allineamento; puoi tranquillamente farne a meno
Passo dopo passo
- 1
Apri Sending Domains e aggiungi il tuo dominio
Accedi a SparkPost (app.sparkpost.com, oppure app.eu.sparkpost.com per gli account EU) e vai in Configuration → Sending Domains → Add Domain. Inserisci il dominio o sottodominio da cui invierai (un sottodominio come mail.yourdomain.com è una scelta comune e tiene separata la reputazione di invio) e salva.
- 2
Copia il record DKIM generato da SparkPost
Nella schermata di configurazione del dominio, SparkPost mostra un record DKIM sotto “Set up for DKIM signing”. È un record TXT: l'host è un selettore generato automaticamente come scph0421._domainkey.yourdomain.com e il valore inizia con v=DKIM1; k=rsa; h=sha256; p=… seguito dalla tua chiave pubblica. SparkPost usa di default una chiave a 2048 bit, quindi il valore è lungo: copialo tutto, esattamente com'è.
- 3
Pubblica il record TXT DKIM
Sul tuo provider DNS, crea un record TXT con host scph0421._domainkey (sotto il tuo dominio/sottodominio di invio) e incolla il valore v=DKIM1… completo. Deve restare un record TXT: il DKIM di SparkPost non è un CNAME. Trattandosi di una chiave a 2048 bit, alcuni pannelli limitano la stringa TXT a 255 caratteri e ti chiedono di dividerla in più stringhe tra virgolette: dividila, senza eliminare caratteri. Se il pannello aggiunge automaticamente il dominio, inserisci solo l'etichetta (scph0421._domainkey) per evitare di duplicarlo.
- 4
Verifica il dominio di invio
Torna nella schermata Sending Domains, spunta la casella che conferma l'aggiunta del record e fai clic su Verify Domain. Appena il record si risolve, il dominio risulta verificato e “DKIM Signing” indica ready: SparkPost non firma con la tua chiave finché questo stato non cambia. Di solito la propagazione richiede pochi minuti, ma può arrivare a 24-48 ore.
- 5
Aggiungi un Bounce Domain personalizzato
Vai in Configuration → Bounce Domains (oppure scegli l'opzione Bounce Domain mentre aggiungi un dominio) e aggiungi un sottodominio a cui affidare il Return-Path: es. bounces.yourdomain.com per l'allineamento relaxed, oppure riusa esattamente il tuo sottodominio di invio (mail.yourdomain.com) per l'allineamento rigoroso (strict). È questo il passaggio che ti dà l'allineamento SPF.
- 6
Pubblica il CNAME del dominio di bounce
Crea un record CNAME: host = il tuo sottodominio di bounce (bounces), valore = sparkpostmail.com (per SparkPost EU, puntalo invece a eu.sparkpostmail.com). Su Cloudflare, imposta il record su “DNS only” (nuvola grigia): un CNAME con proxy attivo (nuvola arancione) non si risolve in SparkPost e la verifica non riesce.
- 7
Verifica il bounce domain
Torna in Bounce Domains e fai clic per verificare. Quando la verifica diventa verde, SparkPost usa il tuo sottodominio come MAIL FROM della busta, quindi ora l'SPF viene superato E si allinea al tuo dominio organizzativo: un secondo meccanismo allineato accanto a DKIM.
- 8
Aggiungi un record di policy DMARC
SparkPost non crea DMARC al posto tuo. Aggiungi un record TXT con host _dmarc e valore v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito mentre confermi che SparkPost supera SPF e DKIM allineati; la renderai più restrittiva in seguito.
- 9
Invia un'email di prova e leggi le intestazioni
Inviati un messaggio tramite SparkPost da un indirizzo del dominio autenticato, aprilo in Gmail e scegli ⋮ → Show original. Devi vedere DKIM: PASS firmato da yourdomain.com (selettore scph…), SPF: PASS con il mailfrom sul tuo sottodominio di bounce (non su sparkpostmail.com) e DMARC: PASS. Poi conferma che ogni record si risolva con un check-up del dominio.
Record da aggiungere
SparkPost genera i valori esatti nella sua procedura guidata di configurazione: questi mostrano la struttura di ciò che aggiungerai presso il tuo provider DNS.
| Tipo | Host | Valore |
|---|---|---|
| TXT | scph0421._domainkey | v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from SparkPost)DKIM: il meccanismo allineato che supera DMARC. Il selettore scph è generato automaticamente per account (es. scph0421, scph0717); valore di esempio: copia il record esatto da Configuration → Sending Domains. SparkPost usa di default una chiave a 2048 bit, quindi dividila in più stringhe tra virgolette se il tuo pannello limita il TXT a 255 caratteri. Pubblicalo sotto il tuo dominio/sottodominio di invio, es. scph0421._domainkey.mail.yourdomain.com. |
| CNAME | bounces | sparkpostmail.comBounce Domain personalizzato (Return-Path): è ciò che ALLINEA l'SPF al tuo dominio. Usa un sottodominio, non il dominio radice. Su SparkPost EU deve puntare a eu.sparkpostmail.com. Su Cloudflare imposta “DNS only” (nuvola grigia). |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comQuesto lo aggiungi tu: SparkPost non lo crea mai. Uno per dominio; parti da p=none, poi sali a quarantine/reject. |
| TXT | @ | v=spf1 include:sparkpostmail.com ~allLEGACY / OPZIONALE: NON crea l'allineamento DMARC, perché la busta è di SparkPost. Il percorso SPF allineato è il CNAME di bounce qui sopra; aggiungi questo record solo se vuoi che il tuo SPF grezzo faccia riferimento a SparkPost e, in quel caso, uniscilo al tuo unico record SPF radice. Costa due ricerche: l'include più la macro exists annidata nel record di sparkpostmail.com. |
Tieni esattamente un record TXT SPF (v=spf1) sul dominio radice e unisci al suo interno tutti i mittenti. Avere due record SPF è di per sé un errore.
Il limite di 10 ricerche DNS
SPF ha un tetto fisso di 10 ricerche DNS: se lo superi, restituisce un permerror e smette di essere valido ovunque. Ecco quanto consuma di questo budget la configurazione di SparkPost.
La configurazione consigliata di SparkPost aggiunge 0 ricerche: tutte e 10 restano libere per i mittenti che hanno davvero bisogno di un include.
DKIM
Per SparkPost, DKIM è il record portante, perché è il meccanismo che si allinea di default. Quando aggiungi un dominio di invio, SparkPost genera una coppia di chiavi RSA (a 2048 bit per impostazione predefinita) e ti mostra un record TXT da pubblicare: l'host è un selettore generato automaticamente nella forma scphNNNN._domainkey.yourdomain.com (ad esempio scph0421._domainkey: le quattro cifre vengono assegnate per account/chiave) e il valore è v=DKIM1; k=rsa; h=sha256; p=<your public key>. Pubblichi quel TXT sul tuo provider DNS; SparkPost conserva la chiave privata corrispondente e con quella firma ogni messaggio in uscita, così la firma DKIM riporta d=yourdomain.com e si allinea al tuo indirizzo From. Due cose distinguono il DKIM di SparkPost dai provider con delega CNAME (SendGrid, Mailchimp, Klaviyo). Primo: è un record TXT da incollare, non un CNAME, quindi pubblicare un CNAME dove è previsto il TXT scph rompe la firma; mantieni il tipo di record TXT. Secondo: poiché pubblichi tu la chiave invece di delegarla, non c'è rotazione automatica: se devi ruotarla, generi una nuova chiave in SparkPost e ripubblichi tu stesso il nuovo TXT scph. Un dettaglio pratico legato ai 2048 bit predefiniti: la chiave pubblica supera il limite di 255 caratteri della singola stringa TXT, quindi molti pannelli DNS ti chiedono di dividerla in più stringhe tra virgolette (SparkPost può emettere una chiave a 1024 bit se il tuo provider non gestisce i TXT a più stringhe). Non basta pubblicare il record: devi tornare in Configuration → Sending Domains e fare clic su Verify Domain, così il dominio risulta verificato e “DKIM Signing” indica ready; SparkPost non firma con la tua chiave finché questo stato non cambia.
DMARC
DMARC è un record di policy separato che aggiungi tu: SparkPost non lo crea. Pubblica un record TXT su _dmarc.yourdomain.com che inizi con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito, mentre i server riceventi ti inviano via email i report aggregati (rua) con cui confermare che la posta SparkPost supera SPF e DKIM allineati al tuo dominio. È qui che la configurazione in due parti di SparkPost dà i suoi frutti: una volta verificato il record DKIM scph ottieni l'allineamento DKIM e, una volta verificato il bounce domain personalizzato, anche quello SPF, quindi un dominio SparkPost configurato correttamente supera DMARC con entrambi i meccanismi invece di affidarsi solo a DKIM. Tieni d'occhio i report per una o due settimane, assicurati che ogni mittente legittimo (SparkPost e qualsiasi altro servizio tu usi) si autentichi, poi passa a p=quarantine e infine a p=reject. Tieni esattamente un record _dmarc per l'intero dominio organizzativo, a prescindere da quanti mittenti usi: non pubblicare mai un secondo record DMARC specifico per SparkPost.
Verifica che funzioni davvero
Non fidarti solo delle spunte verdi della dashboard: verifica su un messaggio reale. Inviati un'email di prova tramite SparkPost da un indirizzo del dominio autenticato, aprila in Gmail e scegli ⋮ → Show original. Devi vedere DKIM: PASS firmato da yourdomain.com con il selettore scph (non un dominio condiviso di SparkPost), SPF: PASS con il mailfrom/Return-Path sul tuo sottodominio di bounce (bounces.yourdomain.com; il segnale tipico del problema è un mailfrom ancora su sparkpostmail.com, che indica che il bounce domain personalizzato non è configurato) e DMARC: PASS. In SparkPost, Configuration → Sending Domains deve mostrare il dominio verificato con DKIM Signing ready e Bounce Domains deve mostrare verificato il tuo sottodominio di bounce. Poi analizza il tuo dominio con il check-up del dominio di Qualisend per confermare che il TXT DKIM, il CNAME di bounce e il record DMARC si risolvano correttamente e, quando iniziano ad arrivare i report aggregati DMARC, caricane uno nell'analizzatore di report DMARC: SparkPost dovrebbe comparire come sorgente allineata che supera i controlli.
Insidie comuni
- Configurazione DNS
La trappola principale: aggiungere include:sparkpostmail.com al tuo SPF radice NON fa superare DMARC. La busta è di SparkPost (bounce domain predefinito = sparkpostmail.com), quindi il tuo SPF radice non viene mai consultato per la posta SparkPost. L'allineamento arriva dal TXT DKIM scph più un CNAME per il bounce domain personalizzato, non da un include SPF.
- Copertura
Con il bounce domain predefinito, l'SPF viene superato su sparkpostmail.com ma non si allinea a te, quindi DMARC dipende interamente da DKIM. Aggiungi un Bounce Domain personalizzato per avere un secondo meccanismo allineato e superare anche i controlli dei server riceventi più severi.
- Configurazione DNS
Il DKIM di SparkPost è un record TXT (selettore scph), non un CNAME. Non cambiare il tipo: un CNAME al posto del TXT scph rompe la firma DKIM. E non c'è rotazione automatica delle chiavi: per ruotarle, genera una nuova chiave in SparkPost e ripubblica il TXT.
- Configurazione DNS
SparkPost usa di default una chiave DKIM a 2048 bit, il cui valore supera il limite di 255 caratteri del TXT. Alcuni pannelli DNS ti chiedono di dividerlo in più stringhe tra virgolette: dividilo, senza troncarlo né aggiungere spazi di troppo nel valore p=.
- Configurazione DNS
Il proxy di Cloudflare rompe il CNAME di bounce. Imposta il record del bounce domain su “DNS only” (nuvola grigia): un CNAME con proxy attivo (nuvola arancione) non si risolve in sparkpostmail.com e il dominio non viene verificato.
- Configurazione DNS
Non puoi usare il dominio radice come bounce domain: un CNAME sul dominio radice entra in conflitto con gli altri tuoi record. Usa un sottodominio (bounces.yourdomain.com per l'allineamento relaxed, oppure esattamente il tuo sottodominio di invio per quello strict).
- Configurazione DNS
SparkPost EU è un'infrastruttura separata: accedi da app.eu.sparkpost.com, invia tramite smtp.eu.sparkpostmail.com / api.eu.sparkpost.com e punta il CNAME di bounce a eu.sparkpostmail.com (non a sparkpostmail.com). Lo stesso dominio su US ed EU corrisponde a due registrazioni indipendenti, ciascuna con i propri record DNS.
- Fa fallire l'autenticazione
Tieni esattamente un TXT SPF e un TXT _dmarc sul tuo dominio. Se per qualche motivo mantieni l'include SparkPost legacy, uniscilo alla tua unica riga v=spf1: avere due record SPF è di per sé un PermError.
- Configurazione DNS
Verifica nella dashboard dopo la pubblicazione: SparkPost non applica la firma DKIM finché Configuration → Sending Domains non mostra il dominio verificato. La propagazione può arrivare a 24-48 ore; se la verifica si blocca, ricontrolla che l'host del record non abbia il dominio aggiunto o duplicato.
Crea il tuo record SPF
SparkPost non richiede un include: nel record SPF del dominio radice. Usa il generatore per comporre un unico record pulito per gli altri mittenti e tienilo su una sola riga.
Fonti di invio
Cerca ogni piattaforma con cui invii email e selezionala.
Cerca qui sopra la tua piattaforma email oppure .
Server propri del dominio
Autorizza il dominio stesso, se invia posta direttamente (non tramite una delle piattaforme sopra).
Altri mittenti e IP
Tutto ciò che non è nella lista: l'host SPF di un altro provider o indirizzi IP specifici.
Aggiungiamo noi il prefisso include:. Inserisci l'hostname indicato nella documentazione del provider.
Policy per tutti gli altri
Cosa devono fare i server riceventi con la posta proveniente da server non elencati sopra (il meccanismo all).
Ancora nessun mittente, quindi ogni messaggio finirebbe nella policy ~all. Aggiungi al passaggio 1 le piattaforme con cui invii.
- Pubblicalo come record TXT sul dominio radice: host @ (il dominio senza prefissi), come valore l'intera stringa qui sopra.
- Tieni un solo record SPF per dominio. Unisci tutte le fonti di invio in quest'unica riga. Un secondo record TXT che inizia con v=spf1 li rende entrambi non validi.
- Resta entro le 10 ricerche DNS. Contano come ricerche include:, a e mx, e un include può innescarne altre al suo interno; ip4: e ip6: sono gratuiti.
Autenticazione pubblicata? Il passo successivo è inviare a una lista pulita e verificata.
Verifica una listaSPF per SparkPost: domande frequenti
Letture correlate
Altri provider: Transazionali e API
Tutte le guide SPFDopo la pubblicazione, controlla con il check-up del dominio che tutti i record vengano risolti correttamente, poi scopri con l'analizzatore di report DMARC chi invia a tuo nome. Sfoglia tutte le fonti di invio nel generatore. L'autenticazione, però, è solo metà della deliverability: un IP o un dominio di invio in blacklist ti manda comunque nello spam, per quanto pulito sia il tuo SPF, quindi conviene tenere d'occhio le blacklist con il monitoraggio blacklist.
Dominio autenticato: ora mantieni pulita la lista
Superare SPF, DKIM e DMARC ti porta nella posta in arrivo; una lista pulita ti ci fa restare. Verifica la tua: inizia gratis con 100 crediti, senza carta di credito.