SPF, DKIM e DMARC per Front.
Front (front.com) è una piattaforma di caselle condivise e comunicazione con i clienti, non un host di posta, quindi “inviare a nome del tuo dominio” tramite Front ha un significato ben preciso. Quando colleghi un canale SMTP personalizzato, Front inoltra la tua posta in uscita tramite SendGrid, la sua infrastruttura email sottostante (gli account più vecchi passavano da Mandrill, ed è per questo che potresti aver visto una vecchia dicitura “via mandrillapp.com”). Finché non autentichi questo percorso, i destinatari vedono la dicitura “via sendgrid.net” accanto al tuo indirizzo From e la tua posta ha molte più probabilità di finire nello spam. Le impostazioni Deliverability di Front ti forniscono tre record DNS (un MX, un SPF come TXT e un DKIM come TXT) da aggiungere a un sottodominio di invio dedicato, front-mail. Poiché questi record stanno sul sottodominio e non sul tuo dominio radice, autorizzano SendGrid a inviare a nome tuo, eliminano la dicitura “via” e allineano la tua posta al tuo dominio per DMARC, il tutto senza toccare il tuo SPF esistente né cambiare dove viene recapitata la posta in entrata.
Perché autenticare Front?
Autenticare il tuo dominio di invio Front decide se le tue risposte raggiungono davvero 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 ai mittenti di grandi volumi; i team di supporto e customer success che lavorano in Front superano regolarmente questi volumi. Finché non aggiungi i record, Front invia la tua posta sull'infrastruttura condivisa di SendGrid: i destinatari vedono la dicitura “via sendgrid.net”, il tuo indirizzo From non si allinea al tuo dominio, DMARC non può essere superato tramite SPF e la tua reputazione di invio finisce nello stesso pool di tutti gli altri tenant non autenticati della piattaforma. L'autenticazione risolve tutto in una volta: SendGrid firma con una chiave DKIM pubblicata sotto il tuo sottodominio front-mail (quindi la firma si allinea al tuo dominio), il Return-Path della busta sta sullo stesso sottodominio (quindi SPF si allinea in modalità relaxed), la dicitura “via” scompare, DMARC viene superato e la reputazione che costruisci matura sul tuo dominio invece che nel pool condiviso.
Come funziona davvero SPF con Front
Front è una configurazione con delega a un sottodominio, non un provider “include”: NON esiste alcun include:sendgrid.net da incollare sul tuo dominio radice. L'intero percorso autenticato sta invece su un sottodominio di invio dedicato che Front chiama front-mail. Questo sottodominio riceve tre record direttamente dal pannello Deliverability di Front: un record MX che punta all'host di posta di SendGrid (mx.sendgrid.net) perché SendGrid possa gestire i bounce, un record TXT SPF (v=spf1 include:sendgrid.net ~all) limitato al sottodominio e una chiave pubblica DKIM in TXT su un selettore sotto lo stesso sottodominio. Il record SPF del tuo dominio organizzativo resta esattamente com'è: l'include di Front sta su front-mail.yourdomain.com, quindi non consuma nessuna delle 10 ricerche DNS del tuo SPF radice. DMARC viene comunque superato, ma nota il dettaglio specifico di Front: poiché SIA il Return-Path della busta SIA la chiave DKIM stanno sul sottodominio front-mail, sia SPF sia DKIM si allineano al tuo dominio organizzativo in modalità relaxed (il sottodominio condivide il tuo dominio registrabile), e nessuno dei due si allinea in modalità rigorosa (strict). Relaxed è il valore predefinito di DMARC, quindi Front supera i controlli senza altri interventi; basta non imporre l'allineamento strict (aspf=s o adkim=s) per questo dominio. Infine, tutto questo vale solo per i canali SMTP di Front: se il tuo canale Front è una casella Gmail o Microsoft 365 collegata, Front invia tramite i server di quel provider e l'autenticazione la fai su Google/Microsoft, e nessuno dei record front-mail si applica.
Due modi per configurarlo
Canale SMTP di Front: aggiungi i record SendGrid (questa guida)
- Vale quando il tuo canale è un canale SMTP personalizzato: Front inoltra la posta in uscita tramite SendGrid e devi autenticarla.
- Aggiungi MX + SPF (TXT) + DKIM (TXT) a un sottodominio di invio dedicato, front-mail, copiandoli dal pannello Deliverability di Front.
- Tutti e tre i record stanno sul sottodominio, quindi l'SPF del tuo dominio radice non viene toccato: nessuna delle tue 10 ricerche SPF viene consumata.
- Finché Front non mostra i record come Verified, la posta parte “via sendgrid.net” sul pool condiviso e rischia di finire nello spam.
Canale Gmail / Microsoft 365 collegato: autentica lì
- Vale quando hai aggiunto la tua casella a Front tramite l'integrazione Google o Microsoft 365: Front invia tramite quel provider, non tramite SendGrid.
- L'autenticazione viene ereditata da SPF, DKIM e DMARC di Google Workspace o Microsoft 365: configurali presso quel provider.
- Non c'è alcun sottodominio front-mail, nessun MX verso mx.sendgrid.net e nessuno dei record SPF/DKIM di SendGrid si applica.
- La dicitura “via sendgrid.net” non compare mai, perché SendGrid non è nel percorso di invio.
Passo dopo passo
- 1
Conferma che il canale sia un canale SMTP
Questi record valgono solo per i canali SMTP di Front (posta inoltrata tramite SendGrid). Se il tuo canale è una casella Gmail o Microsoft 365 collegata, Front invia tramite quel provider: fermati qui e autentica su Google/Microsoft. Controlla il tipo di canale in Settings → Channels.
- 2
Apri le impostazioni Deliverability
Per i canali aziendali, fai clic sull'ingranaggio Settings → Company settings → Security nella barra laterale → la scheda Deliverability. Questa pagina compare solo agli amministratori dell'azienda e solo quando esiste almeno un canale SMTP condiviso. Per il canale di un singolo collega, apri Settings → il canale SMTP del collega → scheda Settings → la sezione “Improve delivery rates - SPF / DKIM”.
- 3
Seleziona il dominio di invio
In Domains, scegli il dominio da cui invii. Ogni dominio privo di SPF/DKIM mostra un'icona di avviso gialla. Front mostra quindi Name e Value dei tre record da aggiungere: un MX, un SPF (TXT) e un DKIM (TXT). Tieni aperto questo pannello per copiare i dati: selettore, host e valori della chiave esatti sono unici per il tuo account.
- 4
Aggiungi il record MX sul sottodominio front-mail
Crea un record MX: Host/Name = l'etichetta del sottodominio mostrata da Front (es. front-mail), Value/Target = l'host di posta di SendGrid (es. mx.sendgrid.net), Priority = come indicato (di solito Front usa 10). È un NUOVO MX sul sottodominio per la gestione dei bounce di SendGrid: NON cambia il tuo MX principale (host @) né dove viene recapitata la posta in entrata.
- 5
Aggiungi il record SPF (TXT)
Crea un record TXT: Host/Name = front-mail, Value = esattamente ciò che mostra Front (es. v=spf1 include:sendgrid.net ~all). Questo SPF è limitato al sottodominio di invio: NON aggiungere include:sendgrid.net al record SPF del tuo dominio radice.
- 6
Aggiungi il record DKIM (TXT)
Crea un record TXT con l'host del selettore mostrato da Front (es. s1._domainkey.front-mail) e incolla esattamente il lungo valore della chiave pubblica di Front, senza aggiungere spazi o interruzioni di riga. Front usa il whitelabel classico di SendGrid, quindi è una singola chiave TXT statica, non i CNAME a rotazione automatica della moderna autenticazione del dominio di SendGrid.
- 7
Inserisci gli host come sole etichette e non toccare i record esistenti
Digita solo l'etichetta (front-mail, s1._domainkey.front-mail): la maggior parte dei registrar aggiunge automaticamente il dominio, e inserire il nome completo front-mail.yourdomain.com produce un nome raddoppiato che non si risolve. Aggiungi solo questi tre NUOVI record; non modificare né eliminare i record DNS esistenti, perché potresti compromettere il recapito.
- 8
Pubblica la tua policy DMARC (se non ne hai una)
Sul tuo dominio radice aggiungi un record TXT su _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Tieni esattamente un record _dmarc per l'intero dominio. Lascia l'allineamento sul valore predefinito relaxed: sul sottodominio front-mail di Front sia SPF sia DKIM si allineano in modalità relaxed, quindi non impostare aspf=s o adkim=s, perché ciascuno dei due romperebbe l'autenticazione di Front.
- 9
Fai clic su “Check DNS settings” in Front
Torna al pannello Deliverability di Front e fai clic su Check DNS settings: questo avvia una verifica tramite SendGrid. Quando i record si risolvono, ognuno passa a Verified e l'icona di avviso gialla scompare dal canale. Di solito la propagazione richiede pochi minuti, ma può arrivare a 24-48 ore.
- 10
Invia un vero messaggio di prova e conferma l'allineamento
Inviati un messaggio dal canale Front, aprilo in Gmail e usa ⋮ → Show original. Conferma SPF: PASS, DKIM: PASS con signed-by front-mail.yourdomain.com, DMARC: PASS e che la dicitura “via sendgrid.net” non compaia più nella riga From.
Record da aggiungere
Front 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 |
|---|---|---|
| MX | front-mail | mx.sendgrid.netReturn-Path del sottodominio di invio: l'host dei bounce di SendGrid, con la priorità indicata da Front (di solito 10). Sottodominio e host esatti vengono dal pannello Deliverability di Front. NON è il tuo MX principale e non influisce sulla posta in entrata. |
| TXT | front-mail | v=spf1 include:sendgrid.net ~allSPF solo per il sottodominio di invio: non viene mai aggiunto al tuo dominio radice, quindi costa 0 delle 10 ricerche del tuo SPF radice. Copia il valore esatto da Front. |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…Chiave pubblica DKIM (singolo TXT statico). Front/SendGrid fornisce selettore e chiave esatti: host e valore sono unici per il tuo account, questo è solo illustrativo. Poiché la chiave sta sotto front-mail, il d= della firma è il sottodominio e si allinea al tuo dominio in modalità relaxed. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comLa tua policy DMARC: una per dominio radice. Front si autentica interamente tramite il sottodominio front-mail, quindi mantieni l'allineamento relaxed (il valore predefinito); strict (aspf=s o adkim=s) rompe Front. |
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 Front.
La configurazione consigliata di Front aggiunge 0 ricerche: tutte e 10 restano libere per i mittenti che hanno davvero bisogno di un include.
DKIM
Il DKIM di Front è un singolo record TXT statico con la chiave pubblica, che Front genera tramite SendGrid e ti mostra nel pannello Deliverability. Lo pubblichi sul selettore del sottodominio di invio (qualcosa come s1._domainkey.front-mail.yourdomain.com); SendGrid conserva la chiave privata corrispondente e firma ogni messaggio inoltrato da Front. Poiché la chiave sta sotto front-mail, la firma DKIM riporta d=front-mail.yourdomain.com, che si allinea al tuo dominio organizzativo in modalità relaxed (il valore predefinito di DMARC), esattamente come il Return-Path di SPF. Non si allinea in modalità strict, quindi non impostare adkim=s per questo dominio. Due cose distinguono il DKIM di Front dalla moderna autenticazione del dominio di SendGrid. La prima: è una chiave TXT statica, non un CNAME a rotazione automatica. Front usa il whitelabel classico di SendGrid, quindi incolli la chiave una volta e non ruota da sola (non c'è nulla di delegato da risolvere di nuovo, ma nessuno ruota le chiavi per te). La seconda: essendo una chiave pubblica completa in un valore TXT, può superare il limite di 255 caratteri per singola stringa; la maggior parte dei pannelli DNS la memorizza automaticamente come un unico record suddiviso, ma se in seguito un controllo segnala la chiave come non valida, la causa abituale è un valore alterato o troncato: incollala di nuovo esattamente come la mostra Front. Il selettore assegnato da SendGrid non entra in collisione con i tuoi selettori DKIM di Google (google) o Microsoft (selector1/selector2), quindi il DKIM di Front convive con quello del tuo provider di posta. DKIM resta il più resistente all'inoltro dei tuoi due segnali, perché sopravvive all'inoltro dei messaggi dove SPF si rompe, ma per l'allineamento DMARC dipende dalla stessa modalità relaxed di SPF, quindi mantieni relaxed l'allineamento della tua policy.
DMARC
DMARC è un record di policy separato che pubblichi sul tuo dominio radice: Front non lo crea per te, anche se la sua documentazione sulla deliverability ne spiega l'interazione con Front. Aggiungi un record TXT su _dmarc.yourdomain.com che inizia con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito mentre confermi che la posta Front si autentica. L'insidia specifica di Front è l'allineamento: poiché SendGrid usa il sottodominio front-mail SIA per il Return-Path della busta SIA per il dominio d= di DKIM, la posta Front si allinea al tuo dominio organizzativo in modalità RELAXED sia su SPF sia su DKIM, e in modalità STRICT su nessuno dei due. Relaxed è il valore predefinito di DMARC, quindi una policy standard fa passare Front senza altri interventi e non devi aggiungere nulla. I problemi compaiono solo se il tuo DMARC esistente impone l'allineamento strict: aspf=s rompe l'allineamento SPF di Front e adkim=s rompe il suo allineamento DKIM, e strict su entrambi fa fallire del tutto Front. Mantieni l'allineamento relaxed (puoi renderlo esplicito con aspf=r; adkim=r). Tieni esattamente un record _dmarc per l'intero dominio, a prescindere da quanti mittenti usi (Front, il tuo host di posta, gli strumenti di marketing): non aggiungere mai un secondo record DMARC per Front. Quando i report aggregati confermano che Front/SendGrid si autentica correttamente, passa da p=none a p=quarantine e infine a p=reject.
Verifica che funzioni davvero
Non fidarti del solo badge Verified di Front: controlla su un messaggio reale. Dopo che Check DNS settings mostra i record come Verified, inviati un'email dal canale Front, aprila in Gmail e scegli ⋮ → Show original. Devi vedere SPF: PASS (mailed-by front-mail.yourdomain.com), DKIM: PASS con signed-by: front-mail.yourdomain.com e DMARC: PASS, e la dicitura “via sendgrid.net” non deve più comparire nella riga From. Puoi controllare a campione i record grezzi con dig MX front-mail.yourdomain.com (atteso mx.sendgrid.net), dig TXT front-mail.yourdomain.com (attesa la riga v=spf1 include:sendgrid.net), dig TXT s1._domainkey.front-mail.yourdomain.com (attesa la chiave DKIM) e dig TXT _dmarc.yourdomain.com. Poi analizza il tuo dominio con il check-up del dominio di Qualisend per confermare che ogni record si risolva e che il tuo SPF radice resti sotto il limite di 10 ricerche e, quando iniziano ad arrivare i report aggregati DMARC, caricane uno nell'analizzatore di report DMARC: Front dovrebbe comparire come sorgente allineata che supera i controlli (infrastruttura SendGrid che firma con il tuo dominio).
Insidie comuni
- Copertura
Il record MX richiesto da Front NON è il tuo MX principale. Sta sul sottodominio front-mail e serve solo a far gestire a SendGrid i bounce della posta in uscita di Front: non devia la tua casella né cambia dove viene recapitata la posta in entrata. Il tuo MX esistente sull'host @ non viene toccato.
- Copertura
Inserisci gli host come sola etichetta (front-mail, s1._domainkey.front-mail), non come nome completo front-mail.yourdomain.com. La maggior parte dei registrar aggiunge automaticamente il dominio, e il nome raddoppiato (front-mail.yourdomain.com.yourdomain.com) non si risolve, quindi Check DNS settings non va a buon fine.
- Copertura
Aggiungi solo tre NUOVI record. Front avverte esplicitamente di non modificare né eliminare record DNS esistenti durante questa procedura: toccare i tuoi SPF, MX o DKIM attuali può compromettere il recapito.
- Configurazione DNS
Non aggiungere include:sendgrid.net al tuo SPF RADICE. Front limita SPF al sottodominio front-mail, quindi un include sul dominio radice è ridondante, consuma inutilmente una delle tue 10 ricerche SPF e non è ciò che SendGrid controlla per Front.
- Copertura
L'allineamento DMARC strict rompe Front. Sia il Return-Path della busta sia la chiave DKIM stanno sul sottodominio front-mail, quindi SPF e DKIM si allineano al tuo dominio solo in modalità relaxed. Impostare aspf=s rompe l'allineamento SPF di Front e adkim=s il suo allineamento DKIM; strict su entrambi fa fallire del tutto Front. Relaxed è il valore predefinito, quindi non toccare l'allineamento.
- Copertura
I canali Gmail / Microsoft 365 collegati non usano affatto questi record. Se Front invia tramite la tua casella Google o Microsoft e non tramite un canale SMTP, non c'è alcun sottodominio front-mail né alcuna dicitura “via”: autentica invece presso quel provider.
- Configurazione DNS
I record MX e TXT non possono passare dal proxy, quindi su Cloudflare qui non c'è alcun passaggio nuvola arancione/nuvola grigia (a differenza dell'autenticazione del dominio di SendGrid basata su CNAME). Assicurati solo di averli creati come MX e TXT, non con un altro tipo.
- Copertura
Ogni dominio di invio SMTP e ogni canale si autenticano separatamente. Configurare un dominio non copre gli altri: il pannello Deliverability segnala con un'icona di avviso gialla ogni dominio a cui mancano ancora i record.
Crea il tuo record SPF
Front 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 Front: domande frequenti
Letture correlate
Altri provider: Helpdesk e CRM
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.