SPF, DKIM e DMARC per Zendesk.
Zendesk invia le risposte ai ticket, le notifiche e le automazioni dal tuo indirizzo di assistenza (support@yourdomain.com), quindi autenticarlo è ciò che impedisce a quei messaggi di finire nella cartella spam dei clienti o di comparire con l'indicazione “via zendesk.com”. L'autenticazione si divide tra il tuo provider DNS e l'Admin Center di Zendesk. SPF è un vero include condiviso (aggiungi include:mail.zendesk.com all'unico record SPF del dominio), mentre DKIM consiste in due record CNAME di “firma digitale” che pubblichi e poi attivi in Channels → Talk and email → Email. DMARC è un terzo record separato che Zendesk non crea mai per te. C'è un prerequisito importante: l'autenticazione DNS si applica solo quando invii da un dominio email esterno di tua proprietà; gli indirizzi sul dominio predefinito yourbrand.zendesk.com sono già firmati da Zendesk e non richiedono nulla.
Perché autenticare Zendesk?
Autenticare Zendesk non è una formalità: decide se le tue risposte di assistenza arrivano davvero ai clienti. Una coda di assistenza intensa supera facilmente la soglia di 5.000 messaggi al giorno oltre la quale, da febbraio 2024, Gmail e Yahoo obbligano i mittenti di grandi volumi a superare SPF, DKIM e DMARC con allineamento; nel 2025 Microsoft ha iniziato ad applicare regole simili ai mittenti ad alto volume. Finché non autentichi un dominio di assistenza esterno, Zendesk invia risposte riconducibili a te solo debolmente: i destinatari vedono una nota “via zendesk.com”, il tuo indirizzo From non è crittograficamente tuo, DMARC non può essere superato ed eventuali segnalazioni di spam si accumulano sull'infrastruttura condivisa di Zendesk invece di costruire la tua reputazione. C'è anche una particolarità di Zendesk che qui rende DKIM irrinunciabile: l'SPF di Zendesk non si allinea mai al tuo dominio (gestisce i bounce sul proprio Return-Path zendesk.com), quindi, a differenza di Google Workspace o Microsoft 365, non puoi contare su SPF per superare DMARC: DKIM è l'unico meccanismo che si allinea. Configura l'include SPF, i due CNAME DKIM e una policy DMARC: le tue risposte partiranno firmate con il tuo dominio, l'indicazione “via” sparirà, DMARC verrà superato e la reputazione che costruisci sarà tua.
Come funziona davvero SPF con Zendesk
Zendesk è un vero provider “include”: aggiungi un unico meccanismo condiviso reale, include:mail.zendesk.com, all'unico record TXT SPF del tuo dominio, e Zendesk consiglia ufficialmente il record completo v=spf1 include:mail.zendesk.com -all (raccomanda l'hard fail -all per la massima protezione dallo spoofing). Da una verifica sul DNS reale, mail.zendesk.com si risolve in un record piatto che contiene solo intervalli ip4: e il proprio ~all, senza include annidati, quindi costa esattamente UNA delle tue 10 ricerche DNS SPF. Ecco la parte che quasi tutti i tutorial saltano, ed è la cosa più importante da capire sull'SPF di Zendesk: viene superato, ma non si ALLINEA. Per impostazione predefinita Zendesk invia la posta in uscita con il Return-Path della busta (il MAIL FROM su cui i server riceventi eseguono davvero il controllo SPF) su uno dei propri domini di bounce zendesk.com, non sul tuo dominio, e Zendesk non offre alcun modo per spostare quel Return-Path sul tuo dominio. Quindi SPF autentica l'infrastruttura di Zendesk e viene superato, ma poiché il dominio controllato è un sottodominio di zendesk.com e non il tuo dominio From, non è allineato, e DMARC tiene conto di SPF solo quando è allineato. Ciò significa che include:mail.zendesk.com da solo non può far superare DMARC. Vale comunque la pena aggiungerlo (Zendesk lo consiglia, alcuni server riceventi eseguono un controllo SPF non allineato sul dominio From visibile, e l'include evita bounce e consegne nello spam legati a SPF), ma il meccanismo che fa davvero superare DMARC con Zendesk è l'allineamento DKIM, non SPF. Tieni esattamente un record SPF sul dominio (unisci l'include se invii già tramite Google Workspace, Microsoft 365 ecc.), mantieni include:mail.zendesk.com come meccanismo di primo livello in quel record e parti da ~all invece che da -all finché non hai elencato tutti gli altri mittenti legittimi.
Due modi per configurarlo
Dominio email esterno: include SPF + DKIM (consigliato)
- Le risposte arrivano dal tuo brand (support@yourdomain.com), non da un indirizzo zendesk.com
- DKIM firma con d=yourdomain.com, quindi DMARC viene superato tramite l'allineamento DKIM
- Aggiungi al DNS include:mail.zendesk.com più i due CNAME DKIM zendesk1/zendesk2
- Costa una ricerca DNS SPF; le chiavi ruotano automaticamente una volta attivi i CNAME
Indirizzo predefinito yourbrand.zendesk.com: nulla da configurare
- Zendesk autentica e firma già il proprio dominio zendesk.com
- Nessun record SPF, DKIM o DMARC da pubblicare
- Ma i clienti vedono un generico indirizzo From zendesk.com invece del tuo brand
- Nessun controllo sulla reputazione: condividi il dominio di Zendesk con tutti gli altri clienti
Passo dopo passo
- 1
Aggiungi e verifica l'indirizzo di assistenza esterno
Nell'Admin Center apri Channels → Talk and email → Email e aggiungi un indirizzo di assistenza sul tuo dominio (es. support@yourdomain.com), poi verificalo: inoltrando la posta in arrivo di quella casella al tuo indirizzo yourbrand.zendesk.com oppure collegando Google Workspace / Microsoft 365. È importante perché l'autenticazione DNS (include SPF + CNAME DKIM) si applica solo ai domini esterni; gli indirizzi sul dominio predefinito yourbrand.zendesk.com sono già firmati da Zendesk.
- 2
Aggiungi o unisci l'include SPF
Sul dominio radice aggiungi un record TXT con v=spf1 include:mail.zendesk.com -all (Zendesk consiglia l'hard fail -all). Se esiste già un record SPF, non pubblicarne un secondo: unisci include:mail.zendesk.com alla riga v=spf1 esistente, mantenendolo come meccanismo di primo livello, e usa ~all finché non hai elencato tutti gli altri mittenti.
- 3
Aggiungi i due record CNAME DKIM
Crea due record CNAME: host zendesk1._domainkey.yourdomain.com che punta a zendesk1._domainkey.zendesk.com, e host zendesk2._domainkey.yourdomain.com che punta a zendesk2._domainkey.zendesk.com. Sono due perché Zendesk ruota le chiavi DKIM per sicurezza. Devono essere record CNAME, non TXT: è Zendesk a conservare le chiavi dietro quei nomi host.
- 4
Pubblica un record DMARC
Aggiungi un record TXT su _dmarc.yourdomain.com con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito mentre confermi che Zendesk superi DKIM con allineamento al tuo dominio. Tieni un solo record _dmarc per l'intero dominio.
- 5
Attendi la propagazione dei record
Lascia al DNS qualche ora (a volte fino a un giorno) per propagarsi prima del passaggio successivo. NON attivare ancora la firma DKIM in Zendesk: attivarla prima che i CNAME si risolvano è la causa più comune in assoluto dei problemi di recapito con Zendesk.
- 6
Attiva la firma DKIM (deve essere l'ultimo passaggio)
Torna in Admin Center → Channels → Talk and email → Email, trova l'impostazione DKIM / firma digitale, seleziona Custom domain for DKIM e fai clic su Save. Zendesk lo dice chiaramente: deve essere l'ultima cosa che fai, perché attivarla prima che i record CNAME del tuo dominio siano attivi provoca errori di recapito.
- 7
Invia una risposta di prova e leggi le intestazioni
Rispondi a un ticket di prova così che Zendesk invii un vero messaggio in uscita, aprilo in Gmail e usa ⋮ → Show original. Controlla di vedere DKIM: PASS firmato da yourdomain.com (selettore zendesk1 o zendesk2) e DMARC: PASS. SPF risulterà superato ma non allineato (Return-Path su un dominio zendesk.com): è previsto e va bene così, perché è DKIM a far superare DMARC.
- 8
Ripeti per ogni brand e dominio di assistenza
Ogni indirizzo di assistenza esterno su un dominio diverso ha bisogno del proprio include SPF, dei propri CNAME DKIM zendesk1/zendesk2, del proprio record DMARC e dell'opzione Custom domain for DKIM attivata. Autenticare un dominio non copre gli altri.
Record da aggiungere
Zendesk 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 | @ | v=spf1 include:mail.zendesk.com -allSPF radice: tieni un solo record SPF e unisci al suo interno include:mail.zendesk.com. Viene superato ma NON si allinea (il Return-Path di Zendesk è un dominio zendesk.com), quindi da solo non fa superare DMARC. Costa 1 ricerca DNS. |
| CNAME | zendesk1._domainkey | zendesk1._domainkey.zendesk.comChiave DKIM 1. Questa destinazione è la stessa per ogni cliente Zendesk (non è un valore specifico per account); solo il dominio dell'host è tuo. Zendesk ruota automaticamente la chiave che c'è dietro. |
| CNAME | zendesk2._domainkey | zendesk2._domainkey.zendesk.comChiave DKIM 2: servono entrambe perché Zendesk ruota le chiavi. Anche questa è una destinazione condivisa, identica per tutti i clienti. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn solo record DMARC per dominio. È qui che Zendesk supera DMARC, grazie all'allineamento DKIM. Parti da p=none, poi passa a quarantine/reject una volta confermato DKIM. |
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 Zendesk.
Zendesk occupa 1 delle tue 10 ricerche; i meccanismi ip4: e ip6: non consumano ricerche.
DKIM
DKIM è il punto in cui la posta di Zendesk ottiene davvero il superamento di DMARC, quindi è il record più importante. Pubblichi due record CNAME (zendesk1._domainkey.yourdomain.com → zendesk1._domainkey.zendesk.com e zendesk2._domainkey.yourdomain.com → zendesk2._domainkey.zendesk.com) e poi attivi la firma nell'Admin Center. Ecco alcune cose specifiche di Zendesk da sapere. Primo, sono CNAME, non chiavi TXT da incollare: Zendesk conserva le chiavi private e pubblica le chiavi pubbliche dietro zendesk1._domainkey.zendesk.com e zendesk2._domainkey.zendesk.com, così può ruotarle (circa ogni trimestre) senza che tu debba più toccare il DNS: la ricerca CNAME si risolve sempre nella chiave attuale. Secondo, entrambi i nomi host puntano alle stesse destinazioni condivise zendesk.com per ogni cliente; non esiste un valore specifico per account, quindi non cercare di personalizzare la destinazione né di inserirci un ID account. I selettori sono due (zendesk1 e zendesk2) proprio per rendere la rotazione trasparente: uno è attivo mentre l'altro è pronto a subentrare. Terzo, DKIM funziona solo per un dominio email esterno: la posta inviata da un indirizzo yourbrand.zendesk.com non può essere firmata con DKIM a nome del tuo dominio. Infine, pubblicare i CNAME non ha effetto finché non attivi la firma: vai in Admin Center → Channels → Talk and email → Email, seleziona Custom domain for DKIM e poi Save, ma solo dopo che i CNAME si sono propagati, perché attivarla in anticipo provoca errori di recapito. Una volta attiva, Zendesk firma con d=yourdomain.com, che si allinea al tuo dominio From e supera DMARC.
DMARC
DMARC è un record di policy separato che Zendesk non crea mai per te: lo pubblichi tu come record TXT su _dmarc.yourdomain.com, iniziando con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito, ma chiede ai server riceventi di inviarti via email i report aggregati, così puoi confermare che la posta di Zendesk superi i controlli. L'avvertenza specifica di Zendesk è che il superamento di DMARC dipende interamente da DKIM, perché l'SPF di Zendesk non si allinea mai (il suo Return-Path si trova su un dominio di bounce zendesk.com). Quindi, prima di inasprire la policy, usa i report rua per assicurarti che Zendesk risulti allineato tramite DKIM e superi i controlli: se passi a p=quarantine o p=reject mentre DKIM è configurato male, SPF non può compensare e le tue risposte di assistenza inizieranno a finire in quarantena o a essere rifiutate. Osserva i report per una o due settimane, conferma che Zendesk e ogni altro mittente legittimo siano allineati, poi passa a p=quarantine e infine a p=reject. Tieni esattamente un record _dmarc per l'intero dominio, a prescindere da quanti mittenti usi; non aggiungerne mai un secondo solo per Zendesk.
Verifica che funzioni davvero
Non fidarti solo dello stato mostrato nell'Admin Center: confermalo su un messaggio reale. Rispondi a un ticket di prova così che Zendesk invii un'email in uscita dal tuo indirizzo di assistenza esterno, aprila in Gmail e scegli ⋮ → Show original. Devi vedere DKIM: PASS con signed-by: yourdomain.com (selettore zendesk1 o zendesk2) e DMARC: PASS. SPF risulterà pass ma non allineato (il mailed-by/Return-Path sarà un dominio zendesk.com): con Zendesk è previsto, non è un errore di configurazione, quindi non inseguire l'allineamento SPF. Puoi controllare a campione i record grezzi con dig CNAME zendesk1._domainkey.yourdomain.com (deve risolversi fino a zendesk.com) 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 l'SPF resti sotto il limite di 10 ricerche e, quando iniziano ad arrivare i report aggregati DMARC, caricane uno nell'analizzatore di report DMARC: Zendesk dovrebbe comparire come sorgente allineata tramite DKIM che supera i controlli, anche se il suo SPF non è allineato.
Insidie comuni
- Configurazione DNS
Attiva DKIM per ultimo. Zendesk lo dice chiaramente: selezionare Custom domain for DKIM prima che i CNAME zendesk1/zendesk2 si siano propagati provoca errori di recapito. Prima pubblica i record e lascia che il DNS si stabilizzi (da qualche ora a un giorno), poi attiva l'opzione.
- Copertura
SPF non si allinea, per scelta progettuale. Zendesk gestisce i bounce della posta in uscita sul proprio Return-Path zendesk.com, quindi include:mail.zendesk.com fa superare il semplice controllo SPF ma non si allinea mai al tuo dominio e da solo non può far superare DMARC. È DKIM a garantire l'allineamento: non perdere tempo a forzare l'allineamento SPF, Zendesk non offre alcun modo per farlo.
- Copertura
DKIM funziona solo su un dominio email esterno. La posta inviata da un indirizzo yourbrand.zendesk.com non può essere firmata con il tuo dominio: devi prima aggiungere e verificare un indirizzo di assistenza sul tuo dominio (support@yourdomain.com).
- Configurazione DNS
Le destinazioni dei CNAME DKIM sono condivise, non univoche. Entrambe puntano a zendesk1._domainkey.zendesk.com / zendesk2._domainkey.zendesk.com per ogni cliente Zendesk: non cercare di aggiungere un ID account o di 'personalizzare' la destinazione, e non pubblicarle come record TXT.
- Fa fallire l'autenticazione
Tieni esattamente un record SPF e mantieni l'include al primo livello. Se invii già tramite Google Workspace, Microsoft 365 ecc., unisci include:mail.zendesk.com a quell'unica riga v=spf1: due record SPF sono un PermError, e nascondere l'include dentro una ricerca annidata può impedirne la risoluzione al primo livello.
- Copertura
-all o ~all. Zendesk consiglia l'hard fail -all, ma se il tuo SPF non elenca ancora tutti i mittenti legittimi, con -all la posta di quei mittenti riceverà un hard fail. Usa ~all finché non hai elencato tutti i mittenti, poi passa a -all.
- Configurazione DNS
Dominio duplicato nel campo host. Molti registrar aggiungono automaticamente il dominio, quindi inserire zendesk1._domainkey.yourdomain.com produce zendesk1._domainkey.yourdomain.com.yourdomain.com. Inserisci solo l'etichetta zendesk1._domainkey se il pannello aggiunge il dominio per te.
- Configurazione DNS
Ogni brand e dominio ha bisogno della configurazione completa. Ogni dominio di assistenza esterno richiede il proprio include SPF, i propri due CNAME DKIM, il proprio record DMARC e l'opzione Custom domain for DKIM attivata: la configurazione di un dominio non copre gli altri.
Crea il tuo record SPF
Zendesk è già preselezionato qui sotto. Aggiungi le altre piattaforme con cui invii, poi pubblica l'unico record unificato.
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).
- 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 Zendesk: domande frequenti
Letture correlate
Dopo 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.