SPF, DKIM e DMARC per SocketLabs.
SocketLabs autentica il tuo dominio nel suo On-Demand Portal, e la sua configurazione è davvero diversa da quella di un provider del tipo “incolla questa riga SPF”. Ogni messaggio che invii è già autenticato con SPF e firmato con DKIM nel momento in cui lascia la piattaforma, ma di default quell'autenticazione appartiene al dominio di SocketLabs, email-od.com: ecco perché la posta non configurata riporta la nota “via email-od.com” e non può allinearsi al tuo dominio per DMARC. Perché SocketLabs invii con il tuo dominio, aggiungi due record in Configuration → Domain Management: un CNAME Custom Bounce Domain (che sposta il Return-Path su un tuo sottodominio, così SPF si allinea) e un record DKIM (un singolo CNAME o un selettore TXT generato, così DKIM firma con il tuo dominio). Una policy DMARC separata completa il quadro. La particolarità importante: il percorso SPF consigliato da SocketLabs è il CNAME del dominio di bounce, non l'aggiunta di include:email-od.com al tuo SPF radice.
Perché autenticare SocketLabs?
Autenticare SocketLabs non è una formalità: decide se i tuoi messaggi 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 alla posta ad alto volume diretta a Outlook.com/Hotmail. L'insidia specifica di SocketLabs: di default autentica con SPF sul proprio dominio di bounce email-od.com e firma con DKIM come d=email-od.com. Entrambi i controlli danno PASS su email-od.com, ma nessuno dei due si allinea al tuo dominio From, quindi l'allineamento DMARC fallisce, i destinatari vedono l'etichetta “via email-od.com” e la reputazione di invio che costruisci finisce in comune con tutti gli altri mittenti SocketLabs non autenticati invece di crescere sul tuo dominio. Configurare un dominio di bounce personalizzato (SPF si allinea) più un DKIM personalizzato (DKIM si allinea) colma questa lacuna con due record: a quel punto DMARC viene superato con entrambi i meccanismi, l'etichetta “via” sparisce e la reputazione è del tuo dominio.
Come funziona davvero SPF con SocketLabs
Tecnicamente SocketLabs è un provider “include”: include:email-od.com esiste e risulta verificabile nel DNS (si risolve in un unico record piatto, v=spf1 ip4:142.0.176.0/20 ip4:… ~all, con soli intervalli ip4 e nessun include annidato, quindi costerebbe esattamente UNA delle tue 10 ricerche SPF), ma NON è il percorso SPF consigliato da SocketLabs e, da solo, non produce allineamento DMARC. Ecco perché: SPF viene valutato sul dominio di Return-Path (bounce/busta), non sul tuo indirizzo From visibile. Di default il Return-Path di SocketLabs è email-od.com, quindi il controllo SPF interroga il record di email-od.com e il tuo SPF radice non viene mai consultato per la posta di SocketLabs. SocketLabs implementa invece SPF tramite un Custom Bounce Domain: pubblichi un CNAME su un sottodominio del tuo dominio (es. email.yourdomain.com CNAME tracking.socketlabs.com) e, poiché tracking.socketlabs.com pubblica a sua volta v=spf1 include:email-od.com ~all, spostare il Return-Path sul tuo sottodominio fa sia SUPERARE SPF (eredita gli IP in whitelist di SocketLabs tramite quel CNAME) sia ALLINEARE SPF al tuo dominio organizzativo, il tutto senza modificare il tuo record SPF radice esistente. Per questo la configurazione consigliata aggiunge zero ricerche al tuo SPF radice. Il meccanismo include:email-od.com è una sicurezza in più: puoi aggiungerlo al tuo SPF radice (autorizza anche lì gli IP di invio, al costo di una ricerca), ma da solo non dà allineamento e non serve una volta attivo il dominio di bounce personalizzato. Come sempre, tieni esattamente UN record TXT SPF per dominio: se aggiungi l'include, uniscilo alla tua unica riga v=spf1 invece di pubblicare un secondo record.
Due modi per configurarlo
CNAME Custom Bounce Domain (consigliato)
- Sposta il Return-Path su un sottodominio del tuo dominio, così SPF viene superato E SI ALLINEA per DMARC
- Aggiunge zero ricerche DNS al tuo SPF radice: non c'è nulla da unire o appiattire
- Il CNAME verso tracking.socketlabs.com eredita automaticamente gli IP in whitelist di SocketLabs; non devi più modificarlo quando gli IP cambiano
- Lo stesso CNAME del sottodominio può essere riutilizzato per personalizzare con il tuo marchio (white-label) i link di tracciamento di aperture e clic
include:email-od.com sul tuo SPF radice (facoltativo)
- Aggiungi tu v=spf1 include:email-od.com ~all al tuo SPF radice
- Costa una delle tue 10 ricerche DNS SPF (email-od.com è un record piatto con soli ip4, quindi esattamente una)
- Autorizza gli IP di invio sotto il tuo dominio ma da solo NON allinea SPF: il Return-Path resta email-od.com, a meno che tu non imposti anche il CNAME di bounce
- Nel migliore dei casi un'aggiunta, mai un sostituto del dominio di bounce personalizzato
Passo dopo passo
- 1
Apri Domain Management
Accedi all'On-Demand Portal, fai clic su Configuration nel menu a sinistra, scegli Domain Management, poi seleziona il dominio di invio da autenticare (o fai clic per aggiungerlo). Tutto ciò che segue si trova sulla scheda di questo dominio.
- 2
Avvia Custom Bounce Domain e SPF
Sul dominio, apri “Custom Bounce Domain and SPF Authentication”. SocketLabs genera un record CNAME su un sottodominio del tuo dominio (qualcosa come email.yourdomain.com o bounce.yourdomain.com) la cui destinazione è tracking.socketlabs.com. È così che SocketLabs implementa SPF: sposta il tuo Return-Path sul tuo dominio, così SPF si allinea.
- 3
Pubblica il CNAME del dominio di bounce
Presso il tuo provider DNS, crea un CNAME: Host = il sottodominio mostrato da SocketLabs (es. email), Value = tracking.socketlabs.com. Non cambiarlo in record TXT o A e non toccare il tuo record SPF radice esistente: è questo CNAME a gestire SPF.
- 4
Scegli il metodo DKIM
Torna sul dominio e apri la sezione DKIM. Hai due opzioni: la funzione CNAME DKIM Signing (la più semplice: SocketLabs possiede e ruota la chiave per te) o il metodo Advanced/TXT tramite il DKIM Key Generator (scegli un selettore e pubblichi un record TXT con la chiave pubblica). Scegline uno: non servono entrambi.
- 5
Pubblica il record DKIM
Per il metodo CNAME, aggiungi un CNAME: Host = dkim._domainkey, Value = dkim._domainkey.email-od.com. Per il metodo TXT, aggiungi un record TXT con Host = <selector>._domainkey (il selettore scelto nel generatore, alfanumerico e sotto i 10 caratteri) e il valore v=DKIM1; k=rsa; p=… mostrato da SocketLabs. In entrambi i casi, DKIM ora firma con il tuo dominio.
- 6
Aggiungi il record DMARC
SocketLabs non crea DMARC per te. Aggiungi un record TXT con Host = _dmarc e v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è solo monitoraggio, quindi non cambia nulla nel recapito mentre confermi l'allineamento; renderai più rigida la policy in seguito.
- 7
Verifica nel portale
Torna in Domain Management e fai clic su “Verify Bounce” per il dominio di bounce personalizzato e su “Verify” per DKIM. Lo stato del dominio di bounce deve indicare authenticated e quello di DKIM active. Di solito la propagazione richiede pochi minuti, ma SocketLabs può impiegare fino a 24-48 ore per confermare i record.
- 8
Invia un'email di prova e leggi le intestazioni
Invia un messaggio da un indirizzo del dominio configurato a un account Gmail, aprilo e scegli ⋮ → Show original. Devi vedere SPF: PASS con il tuo sottodominio di bounce (non email-od.com), DKIM: PASS con d=yourdomain.com e DMARC: PASS. La nota “via email-od.com” dovrebbe essere sparita.
Record da aggiungere
SocketLabs 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 | tracking.socketlabs.comCustom Bounce Domain: è questo che gestisce e ALLINEA SPF. L'etichetta del sottodominio (email/bounce/…) è quella assegnata da SocketLabs; riutilizzala anche per il white-label del tracciamento delle interazioni. | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM (consigliato, il più semplice): SocketLabs possiede e ruota la chiave. Il selettore è dkim; d= diventa il tuo dominio, così DKIM si allinea. |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)Alternativa al metodo CNAME: usa il percorso DKIM Advanced/TXT solo se vuoi controllare la chiave. Il selettore (qui sl2026) lo scegli tu: alfanumerico, meno di 10 caratteri. Valore di esempio: il generatore usa di default una chiave a 2048 bit, generata per ogni account. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comQuesto lo aggiungi tu: SocketLabs non lo crea mai. Uno per dominio; parti da p=none, poi passa a quarantine/reject. |
| TXT | @ | v=spf1 include:email-od.com ~allFACOLTATIVO, solo come sicurezza in più. Non serve se configuri il dominio di bounce personalizzato e da solo non allinea SPF. Costa 1 ricerca; se lo usi, uniscilo alla tua unica riga SPF radice. |
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 SocketLabs.
La configurazione consigliata di SocketLabs aggiunge 0 ricerche: tutte e 10 restano libere per i mittenti che hanno davvero bisogno di un include.
DKIM
SocketLabs firma ogni messaggio di default, ma con d=email-od.com, che non si allinea al tuo dominio: è quindi il DKIM personalizzato a far funzionare davvero DKIM per te, e ci sono due modi per configurarlo. La funzione CNAME DKIM Signing è la più semplice: pubblichi un solo CNAME, Host = dkim._domainkey.yourdomain.com che punta a dkim._domainkey.email-od.com e, trattandosi di un CNAME (non di una chiave da incollare), SocketLabs mantiene il controllo della chiave privata e di quella pubblica e le ruota per te: non devi più toccare il DNS. Il selettore è semplicemente dkim e, una volta completata la verifica, SocketLabs firma la tua posta con d=yourdomain.com, così DKIM si allinea. Il metodo Advanced/TXT ti dà più controllo: in Domain Management esegui il DKIM Key Generator, scegli un selettore (alfanumerico, meno di 10 caratteri, es. sl2026) e SocketLabs genera la coppia di chiavi, conservando la chiave privata nel tuo account e dandoti la chiave pubblica da pubblicare come record TXT su <selector>._domainkey.yourdomain.com nella forma v=DKIM1; k=rsa; p=…. Il generatore usa di default una chiave a 2048 bit (esiste un'opzione a 1024 bit, ma resta su 2048: la chiave più robusta è lo standard moderno e SocketLabs consiglia di non abbassarla). Esiste anche una variante “bring your own TXT record”, in cui fornisci una chiave privata generata altrove. Un requisito tassativo del percorso TXT: il portale non ti lascia salvare finché non riesce a risolvere dal DNS la chiave pubblica che hai pubblicato e, una volta salvata, la chiave pubblica non viene più mostrata nel portale, quindi pubblicala prima. Un'avvertenza vale per ENTRAMBI i metodi: la firma DKIM personalizzata viene applicata solo ai messaggi il cui indirizzo From (la Purported Responsible Address) corrisponde esattamente al dominio configurato. La posta inviata da qualsiasi altro dominio From torna alla firma predefinita email-od.com e non si allinea, quindi configura DKIM per ogni dominio da cui invii.
DMARC
DMARC è un record TXT di policy separato che SocketLabs non crea: lo pubblichi tu presso il tuo provider DNS. 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 osservi i report aggregati (rua) per confermare che la posta di SocketLabs superi SPF e DKIM con allineamento al tuo dominio. Poiché il dominio di bounce personalizzato ti dà l'allineamento SPF e il DKIM personalizzato l'allineamento DKIM, un dominio SocketLabs configurato correttamente supera DMARC con ENTRAMBI i meccanismi: è la configurazione robusta che resiste all'inoltro, perché un inoltro che rompe SPF lascia comunque una firma DKIM allineata. Osserva i report per una o due settimane, assicurati che ogni mittente legittimo (SocketLabs più gli altri strumenti sul dominio) sia autenticato, poi rendi più rigida la policy passando 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 aggiungere mai un secondo record DMARC solo per SocketLabs.
Verifica che funzioni davvero
Non fidarti solo dei badge “authenticated” e “active” del portale: conferma su un messaggio reale. Invia un'email di prova da un indirizzo del dominio configurato a una casella Gmail, aprila e scegli ⋮ → Show original: devi vedere SPF: PASS con il tuo sottodominio di bounce (es. email.yourdomain.com, NON email-od.com), DKIM: PASS con d=yourdomain.com e DMARC: PASS. Il segnale tipico del problema è SPF/DKIM che mostrano ancora email-od.com: significa che il dominio di bounce e/o il DKIM personalizzato non sono ancora attivi, oppure che hai inviato da un dominio From non configurato. Puoi controllare a campione i record grezzi con dig CNAME email.yourdomain.com (deve risolversi in tracking.socketlabs.com), dig CNAME dkim._domainkey.yourdomain.com (o dig TXT <selector>._domainkey.yourdomain.com per il metodo TXT) 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 correttamente e, quando iniziano ad arrivare i report aggregati DMARC, caricane uno nell'analizzatore di report DMARC: SocketLabs dovrebbe comparire come sorgente allineata che supera tutti i controlli.
Insidie comuni
- Copertura
L'etichetta predefinita “via email-od.com” significa che non sei ancora allineato: finché non configuri SIA un dominio di bounce personalizzato SIA un DKIM personalizzato, SocketLabs autentica come email-od.com, quindi SPF e DKIM danno pass ma l'allineamento DMARC fallisce. L'etichetta sparisce solo quando entrambi puntano al tuo dominio.
- Configurazione DNS
Aggiungere include:email-od.com al tuo SPF radice NON risolve da solo il problema. Autorizza gli IP di invio, ma il Return-Path resta email-od.com finché non pubblichi il CNAME del dominio di bounce, ed è quel CNAME, non l'include, ad allineare davvero SPF. Non saltare il CNAME pensando che basti l'include.
- Copertura
Il DKIM personalizzato firma solo la posta il cui indirizzo From corrisponde esattamente al dominio configurato (la Purported Responsible Address). Se invii da un altro dominio From, SocketLabs torna silenziosamente alla firma predefinita email-od.com e DKIM non si allinea: configura ogni dominio di invio.
- Configurazione DNS
Alcuni provider DNS non accettano un trattino basso nell'host di un CNAME, e questo blocca il metodo CNAME dkim._domainkey. Se il tuo lo rifiuta, usa invece il percorso DKIM Advanced/TXT (DKIM Key Generator): il record TXT con la chiave pubblica aggira il limite sul trattino basso nei CNAME.
- Configurazione DNS
Il proxy di Cloudflare rompe entrambi i CNAME: imposta il CNAME del dominio di bounce e il CNAME DKIM su “DNS only” (nuvola grigia). Un CNAME con proxy attivo (nuvola arancione) non si risolve in tracking.socketlabs.com / email-od.com e la verifica fallisce.
- Copertura
I subaccount si autenticano separatamente. Nel modello di subaccount di SocketLabs, ogni subaccount ha bisogno del proprio dominio di bounce personalizzato e della propria autenticazione DKIM: autenticare l'account principale non li copre.
- Configurazione DNS
La verifica può tardare 24-48 ore. Di solito la propagazione richiede pochi minuti, ma SocketLabs ricontrolla CNAME/TXT con un certo ritardo, quindi “authenticated”/“active” possono non cambiare subito anche se il tuo DNS è già corretto: verifica con Show original invece di aspettare il badge.
- Configurazione DNS
Dominio duplicato nel campo host: i registrar che aggiungono automaticamente il dominio trasformano dkim._domainkey.yourdomain.com in dkim._domainkey.yourdomain.com.yourdomain.com. Inserisci solo l'etichetta (email, dkim._domainkey, <selector>._domainkey) se il pannello aggiunge il dominio per te.
- Fa fallire l'autenticazione
Tieni esattamente un record SPF e un record DMARC per dominio. Se aggiungi l'include:email-od.com facoltativo, uniscilo alla tua unica riga v=spf1: due record SPF sono un PermError, e lo è anche un secondo record _dmarc.
Crea il tuo record SPF
SocketLabs 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 SocketLabs: 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.