SPF, DKIM e DMARC per Mailtrap.
Mailtrap autentica il tuo dominio tramite una verifica basata su CNAME, senza farti incollare una riga SPF condivisa. Nel prodotto Email Sending aggiungi un dominio di invio e Mailtrap ti fornisce cinque record DNS nella pagina Domain Verification: un CNAME Domain Verification (che copre anche SPF/Return-Path), due CNAME DKIM sui selettori rwmt1._domainkey e rwmt2._domainkey, un CNAME Custom Tracking Domain facoltativo per il tracciamento di aperture e clic con il tuo brand e un record TXT DMARC. Quando questi si risolvono, Mailtrap firma e invia come il tuo dominio, DMARC viene superato con DKIM allineato (e con SPF tramite il tuo Return-Path) e non devi mai pubblicare o gestire un include SPF grezzo. Una cosa trae subito in inganno molti: tutto questo vale solo per Mailtrap Email Sending. La sandbox separata Email Testing intercetta i messaggi in una casella fittizia e non richiede alcun DNS.
Perché autenticare Mailtrap?
Verificare il tuo dominio di invio in Mailtrap fa la differenza tra posta in arrivo e cartella spam, e Mailtrap lo impone prima ancora di inviare posta di produzione. Finché un dominio non è verificato, Mailtrap limita uno stream Email Sending ai messaggi di prova indirizzati all'email del tuo account; i destinatari reali sono bloccati. Oltre a questo, conta il momento: 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 gli stessi requisiti per Outlook/Hotmail/Live, prima dirottando nello spam la posta di grandi volumi non conforme, poi andando verso il rifiuto vero e proprio. Poiché Mailtrap è un mittente transazionale/API, uno stream non verificato significa che la tua posta non parte oppure parte debolmente attribuibile al tuo dominio: niente DKIM allineato, niente DMARC superato e una reputazione condivisa con l'infrastruttura comune di Mailtrap, non una reputazione tua. Completare la verifica del dominio risolve tutto in un colpo solo: i due selettori DKIM rwmt firmano come d=yourdomain.com, quindi DKIM si allinea; il CNAME Domain Verification mette il Return-Path di Mailtrap sul tuo dominio, quindi anche SPF viene superato e si allinea; DMARC viene superato con entrambi i meccanismi e la reputazione di invio che costruisci va a vantaggio del tuo dominio.
Come funziona davvero SPF con Mailtrap
Mailtrap è un provider con verifica del dominio basata su CNAME, quindi per il tuo dominio radice NON c'è alcun include SPF da aggiungere, e la documentazione di Mailtrap lo dice chiaramente: “Il controllo SPF della tua posta è coperto dal record di verifica del dominio. Non serve aggiungere un record SPF separato sul tuo dominio di invio.” Ecco il meccanismo. Quando verifichi un dominio di invio, uno dei CNAME forniti da Mailtrap è il record Domain Verification, che funge anche da host di Return-Path/bounce sul tuo dominio e delega la ricerca SPF all'infrastruttura di invio di Mailtrap. Il vero record SPF attivo di Mailtrap si trova su _spf.smtp.mailtrap.live (v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all), ma non lo pubblichi mai tu: il CNAME Domain Verification si risolve in quel record al posto tuo. Poiché quell'host di Return-Path sta sotto il tuo dominio verificato, SPF viene superato e si allinea al tuo dominio organizzativo con l'allineamento relaxed, un vero vantaggio rispetto ai mittenti CNAME solo DKIM (Mailchimp, Klaviyo), dove SPF non può mai allinearsi. Due cose da sapere. La prima: ignora qualsiasi vecchia indicazione di aggiungere include:_spf.mailtrap.io, perché quell'hostname non si risolve affatto come record SPF, e anche l'host di infrastruttura corretto (_spf.smtp.mailtrap.live) non va incollato sul tuo dominio radice: aggiungerlo a mano consumerebbe inutilmente una delle tue 10 ricerche DNS SPF. La seconda: se il tuo DNS è su Google Cloud DNS, la sua console offre ancora un tipo di record “SPF” legacy. Mailtrap ti dice esplicitamente di ignorarlo (è deprecato) e di aggiungere normalmente i quattro CNAME più il TXT DMARC. Effetto netto sul tuo SPF radice: Mailtrap aggiunge zero ricerche DNS, quindi convive senza problemi con Google Workspace, Microsoft 365 o qualsiasi altro mittente che elenchi già.
Due modi per configurarlo
Verifica un sottodominio di invio dedicato (es. mail.yourdomain.com)
- Isola la reputazione di Mailtrap/transazionale dalla posta inviata dalle persone sul tuo dominio radice, così un errore di invio non può danneggiare il dominio principale.
- DKIM firma come d=mail.yourdomain.com e, con l'allineamento DMARC relaxed, si allinea comunque al tuo dominio organizzativo: DMARC viene superato.
- Il CNAME Domain Verification mette il Return-Path sul sottodominio, quindi anche lì SPF viene superato e si allinea.
- Aggiungi comunque i quattro CNAME più un TXT DMARC; il tuo SPF radice resta intatto, con zero ricerche DNS in più.
Verifica il dominio radice/organizzativo (yourdomain.com)
- La scelta più semplice se Mailtrap è il tuo unico mittente o quello principale e vuoi che la posta arrivi visibilmente dal dominio radice.
- DKIM e il Return-Path stanno direttamente sul dominio organizzativo, quindi l'allineamento è esatto invece di dipendere dalla modalità relaxed.
- La reputazione è condivisa con tutto ciò che invii dal dominio radice: tienine conto se lì c'è anche la posta inviata dalle persone con Google Workspace o Microsoft 365.
- Sempre zero ricerche aggiunte al tuo SPF radice, poiché Mailtrap usa il CNAME Domain Verification e non un include sul dominio radice.
Passo dopo passo
- 1
Apri Email Sending, non Email Testing
Accedi su mailtrap.io e assicurati di essere nel prodotto Email Sending (la sezione della barra laterale per la posta reale in uscita), non in Email Testing (la sandbox che intercetta i messaggi per il QA e non richiede DNS). La verifica del dominio esiste solo per Email Sending.
- 2
Aggiungi il dominio di invio
Nella navigazione a sinistra, vai su Sending Domains e fai clic su Add Domain. Inserisci il dominio da cui invierai (es. yourdomain.com, o un sottodominio come mail.yourdomain.com se vuoi isolare la posta transazionale). Mailtrap genera i record DNS per quel nome esatto.
- 3
Apri la pagina Domain Verification
Seleziona il nuovo dominio per aprire la sua pagina Domain Verification. Vedrai i record da pubblicare, ciascuno etichettato per scopo: Domain Verification (CNAME), DKIM (due CNAME), Custom Tracking / Domain Tracking (CNAME) e DMARC (TXT). Fai attenzione alle colonne Type, Name e Value: Name e Value sono generati per il tuo account.
- 4
Aggiungi il CNAME Domain Verification
Crea il record Domain Verification come CNAME usando esattamente il Name e il Value mostrati da Mailtrap. Questo unico record dimostra la proprietà e copre SPF/Return-Path: ecco perché non pubblichi un record SPF separato. Mantieni il tipo CNAME; non convertirlo in TXT o A.
- 5
Aggiungi i due CNAME DKIM
Crea due record CNAME: Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io e Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io (usa i valori esatti della tua dashboard). Due selettori permettono a Mailtrap di ruotare le chiavi DKIM senza che tu debba più toccare il DNS. Sono questi CNAME a firmare la tua posta come d=yourdomain.com e a farti superare DMARC.
- 6
Aggiungi il CNAME Custom Tracking Domain
Crea il CNAME di tracciamento (di solito Mailtrap mostra un Name come mt-link) che punta al Value fornito. Così il tracciamento di aperture e clic e i link di disiscrizione passano dal tuo dominio invece che da un host Mailtrap. È l'unico record che puoi saltare se non usi il tracciamento dei link, ma aggiungerlo mantiene i link tracciati coerenti con il tuo brand ed evita la reputazione di dominio condiviso di un host di tracciamento generico di Mailtrap.
- 7
Aggiungi il record TXT DMARC
Crea un solo record TXT con Name _dmarc e il valore mostrato da Mailtrap (una policy v=DMARC1; p=none; …). Se il tuo dominio ha già un record _dmarc, NON aggiungerne un secondo: un dominio deve avere esattamente un record DMARC; tieni quello esistente.
- 8
Correggi il dominio duplicato e disattiva il proxy di Cloudflare
Molti registrar aggiungono automaticamente il dominio, quindi inserisci solo l'etichetta (rwmt1._domainkey, non rwmt1._domainkey.yourdomain.com) per evitare la duplicazione, anche se alcuni pannelli vogliono la forma completa con il dominio: adeguati a ciò che chiede il tuo provider. Su Cloudflare, imposta ogni CNAME su “DNS only” (nuvola grigia): Cloudflare attiva il proxy per impostazione predefinita e un CNAME con proxy attivo (nuvola arancione) non si risolve in Mailtrap, quindi la verifica fallisce.
- 9
Ricontrolla il DNS in Mailtrap
Torna alla pagina Domain Verification e fai clic su Re-check DNS Records. Mailtrap controlla anche automaticamente a intervalli, quindi i record passano da Missing (rosso) a Verified (verde) man mano che si propagano: di solito pochi minuti, ma calcola da 15 minuti a 24-48 ore. Alcuni record vengono verificati prima di altri; attendi che siano tutti verdi.
- 10
Invia un'email di prova e leggi le intestazioni
Invia un messaggio da un indirizzo del dominio verificato, aprilo in Gmail e scegli ⋮ → Show original. Conferma DKIM: PASS firmato da yourdomain.com (selettore rwmt1 o rwmt2), SPF: PASS e DMARC: PASS, tutti allineati al tuo dominio e non a un host mailtrap.io.
Record da aggiungere
Mailtrap 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 |
|---|---|---|
| CNAME | (Mailtrap-generated verification host) | (per-account target, e.g. under smtp.mailtrap.live)Record Domain Verification: valore di esempio. Mailtrap mostra il Name e il Value esatti del tuo account nella pagina Domain Verification. Questo CNAME copre anche SPF/Return-Path, ed è per questo che non serve un record SPF separato. |
| CNAME | rwmt1._domainkey | rwmt1.dkim.mailtrap.ioChiave DKIM 1 (a rotazione automatica). Copia il valore esatto dalla tua dashboard; alcuni provider DNS richiedono la forma completa rwmt1._domainkey.yourdomain.com. |
| CNAME | rwmt2._domainkey | rwmt2.dkim.mailtrap.ioChiave DKIM 2: il secondo selettore permette a Mailtrap di ruotare le chiavi. Usa la destinazione esatta mostrata nella tua dashboard. |
| CNAME | mt-link | (per-account tracking target)Custom Tracking Domain: host e destinazione di esempio. Abilita il tracciamento di aperture e clic con il tuo brand e i link di disiscrizione sul tuo dominio. Facoltativo ma consigliato; il Name e il Value esatti vengono mostrati per ogni account. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comPolicy DMARC: una per dominio. Mailtrap precompila un valore p=none; tieni un solo record _dmarc e più avanti passa a quarantine/reject. |
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 Mailtrap.
La configurazione consigliata di Mailtrap aggiunge 0 ricerche: tutte e 10 restano libere per i mittenti che hanno davvero bisogno di un include.
DKIM
DKIM è gestito da due record CNAME, rwmt1._domainkey e rwmt2._domainkey, che Mailtrap genera per il tuo dominio e che puntano rispettivamente a rwmt1.dkim.mailtrap.io e rwmt2.dkim.mailtrap.io (copia i valori esatti dalla pagina Domain Verification). Poiché sono CNAME delegati a Mailtrap, non record TXT da incollare, Mailtrap custodisce le chiavi private e usa i due selettori per ruotare le chiavi pubblicate dietro di essi, senza che tu debba più modificare il DNS. Non c'è alcuna chiave pubblica DKIM da copiare né un selettore da inventare. Qui è DKIM il meccanismo che fa il grosso del lavoro per DMARC: quando i CNAME si risolvono, Mailtrap firma la posta in uscita come d=yourdomain.com, quindi la firma si allinea al tuo dominio organizzativo e soddisfa DMARC da sola, a prescindere dall'inoltro, che può rompere SPF. Qualche nota pratica: mantieni il tipo di record CNAME (un TXT dove è previsto un CNAME fa fallire la convalida); inserisci solo l'etichetta (rwmt1._domainkey) se il pannello aggiunge automaticamente il dominio, oppure il nome completo rwmt1._domainkey.yourdomain.com in caso contrario; su Cloudflare imposta entrambi su “DNS only” (nuvola grigia) perché si risolvano nelle destinazioni mailtrap.io. Aggiungi i due CNAME, fai clic su Re-check DNS Records e le righe DKIM diventano verdi.
DMARC
DMARC è un record di policy separato sul tuo dominio e Mailtrap lo include nell'insieme di record della pagina Domain Verification, di solito precompilato come v=DMARC1; p=none; … . Pubblicalo come record TXT su _dmarc.yourdomain.com. p=none è solo monitoraggio: non cambia nulla nel recapito mentre confermi, dai report aggregati (rua), che la posta Mailtrap supera DKIM (e SPF) con allineamento al tuo dominio. Poiché Mailtrap ti dà sia DKIM allineato (i selettori rwmt) sia un Return-Path allineato (il CNAME Domain Verification), un dominio verificato correttamente supera DMARC con entrambi i meccanismi: la configurazione resiliente che sopravvive all'inoltro. Osserva i report per una o due settimane, assicurati che ogni mittente legittimo si autentichi, poi passa a p=quarantine e infine a p=reject. Due regole: tieni esattamente un record _dmarc per l'intero dominio, a prescindere da quanti mittenti usi (se ne hai già uno, non aggiungere la seconda copia di Mailtrap, tieni il tuo), e punta rua a una casella (o a un servizio di report DMARC) che controlli davvero, altrimenti p=none non ti serve a nulla.
Verifica che funzioni davvero
Non fidarti solo del badge verde “Verified” nella pagina Domain Verification: conferma soltanto che i record si risolvono, non che un messaggio reale si autentichi. Inviati un'email di prova da un indirizzo del dominio verificato, aprila in Gmail e scegli ⋮ → Show original: devi vedere DKIM: PASS firmato da yourdomain.com con selettore rwmt1 o rwmt2, SPF: PASS e DMARC: PASS, tutti con il tuo dominio e non con un host mailtrap.io. In Mailtrap, usa il pulsante Re-check DNS Records per forzare un controllo invece di attendere quello periodico. Puoi controllare a campione i record grezzi con dig CNAME rwmt1._domainkey.yourdomain.com e dig TXT _dmarc.yourdomain.com. Poi analizza il tuo dominio con il check-up del dominio di Qualisend per confermare che il CNAME Domain Verification, entrambi i selettori DKIM, il CNAME di tracciamento e il record DMARC si risolvano correttamente 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: Mailtrap dovrebbe comparire come sorgente allineata che supera i controlli.
Insidie comuni
- Copertura
Email Testing e Email Sending: la verifica del dominio esiste solo per il prodotto Email Sending. La sandbox Email Testing intercetta i messaggi in una casella fittizia per il QA e non richiede alcun record DNS: se cerchi una configurazione DNS in Email Testing, sei nel posto sbagliato.
- Configurazione DNS
Non c'è alcun record SPF da aggiungere. Il CNAME Domain Verification di Mailtrap copre già SPF/Return-Path, quindi non incollare include:_spf.mailtrap.io (non si risolve) o include:_spf.smtp.mailtrap.live (l'host di infrastruttura interna di Mailtrap) sul tuo dominio radice: sprecheresti una ricerca SPF e la documentazione di Mailtrap dice esplicitamente che un record SPF separato non serve.
- Configurazione DNS
Il proxy di Cloudflare rompe la verifica: imposta ogni CNAME di Mailtrap su “DNS only” (nuvola grigia). Cloudflare attiva il proxy (nuvola arancione) per impostazione predefinita e un CNAME con proxy attivo non si risolve nelle destinazioni mailtrap.io / mailtrap.live, quindi i record non vengono mai verificati.
- Configurazione DNS
Dominio duplicato nel campo host: molti registrar aggiungono automaticamente il dominio, quindi rwmt1._domainkey può diventare rwmt1._domainkey.yourdomain.com.yourdomain.com. Inserisci solo l'etichetta se il pannello aggiunge il dominio per te; al contrario, alcuni provider (certi pannelli in stile Squarespace) vogliono la forma completa: adeguati a ciò che chiede il tuo provider.
- Configurazione DNS
Tutti i record sono CNAME tranne DMARC (TXT): non cambiare tipo. Su Google Cloud DNS in particolare, ignora il tipo di record “SPF” legacy della console; Mailtrap segnala che è deprecato. Aggiungi i quattro CNAME e l'unico TXT DMARC.
- Copertura
Finché il dominio non è Verified, Mailtrap permette a uno stream Email Sending di recapitare solo messaggi di prova all'indirizzo email del tuo account. Gli invii di produzione a destinatari reali restano bloccati, quindi completa la verifica prima di collegare Mailtrap al traffico reale della tua app.
- Configurazione DNS
Tieni un solo record DMARC e un solo record SPF. Se invii anche tramite Google Workspace, Microsoft 365, SendGrid ecc., non aggiungere un secondo _dmarc o un secondo TXT SPF: Mailtrap non aggiunge nulla al tuo SPF radice, quindi tieni i singoli record che hai già.
- Copertura
La verifica non è istantanea: la propagazione può richiedere da 15 minuti a 24-48 ore e Mailtrap ricontrolla secondo i propri tempi. Usa Re-check DNS Records per forzare un controllo e aspettati che alcuni record diventino verdi prima di altri.
Crea il tuo record SPF
Mailtrap 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 Mailtrap: domande frequenti
Letture correlate
Altri provider: Transazionali e API
- Mandrill (Mailchimp Transactional)
- Postmark
- Resend
- Scaleway Transactional Email
- SendGrid
- SMTP.com
- SMTP2GO
- SocketLabs
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.