Skip to content
Inizia con 100 crediti di verifica gratuiti
Qualisend
Guida alla configurazione SPF

SPF, DKIM e DMARC per Elastic Email.

Verificare un dominio in Elastic Email si riduce a quattro record DNS più un clic nella dashboard: un record TXT SPF che aggiunge l'include condiviso di Elastic Email, un record TXT DKIM sul selettore api, un CNAME di tracking che applica il tuo brand ai link tracciati (clic e aperture), e un record con la policy DMARC. La particolarità è la chiave DKIM: Elastic Email consegna a tutti i clienti la stessa chiave pubblica condivisa invece di generarne una per dominio, e il suo include SPF è una ricerca dinamica basata su macro anziché un elenco statico di IP. Inserisci i record, fai clic su Verify ed Elastic Email invierà con piena autenticazione a nome del tuo dominio, togliendo anche il limite di 500 email al giorno che impone ai domini non verificati.

Include SPF
Your DNSAdd the CNAME / TXT records
Elastic EmailSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Perché autenticare Elastic Email?

Autenticare il tuo dominio su Elastic Email è ciò che ti fa uscire dalla “zona di penalità” dei 500 messaggi al giorno e dal pool condiviso. Finché un dominio non è verificato, Elastic Email lo limita a 500 email al giorno e invia la tua posta attribuendola a te solo in modo debole. 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 al traffico verso Outlook/Hotmail/Live. Dato che Elastic Email è molto usato per invii marketing e transazionali ad alto volume, questa soglia riguarda proprio la posta che fai passare da lì. Pubblicare SPF e DKIM (più il CNAME di tracking e una policy DMARC) allinea la tua posta al tuo dominio, elimina il branding generico di Elastic Email dai link tracciati, rimuove il limite giornaliero e fa sì che la reputazione di invio che costruisci vada al tuo dominio, non all'infrastruttura condivisa da tutti gli account della piattaforma.

Come funziona davvero SPF con Elastic Email

Elastic Email è un vero provider “include”: aggiungi un solo meccanismo condiviso, include:_spf.elasticemail.com, all'unico record TXT SPF del tuo dominio. La riga consigliata da Elastic Email è v=spf1 a mx include:_spf.elasticemail.com ~all, ma l'unica parte che autorizza i server di Elastic Email è l'include: a e mx sono formule generiche che autorizzano il tuo host web e di posta, e sono facoltative. La particolarità di questo include è ciò in cui si risolve: invece di un elenco statico di intervalli ip4:, _spf.elasticemail.com pubblica v=spf1 exists:%{i}._spf.elasticemail.info ~all, un controllo exists: basato su macro che cerca l'esatto IP di invio (%{i}) al momento della verifica. Ne derivano due conseguenze pratiche. Prima: l'include consuma DUE delle tue 10 ricerche DNS SPF, non una: una per l'include stesso e una per il meccanismo exists annidato (se tieni anche a e mx, la riga consigliata da Elastic Email arriva già a quattro ricerche prima ancora di aggiungere un altro mittente). Seconda: dato che l'autorizzazione viene calcolata dinamicamente per IP, Elastic Email può aggiungere o ritirare IP di invio senza che tu debba più modificare il DNS. Tieni esattamente un record SPF sul dominio: se invii già tramite Google Workspace, Microsoft 365, un CRM o altro, unisci include:_spf.elasticemail.com a quell'unica riga v=spf1 invece di pubblicare un secondo record SPF (due record SPF sono un PermError). Elastic Email propone la riga con ~all (softfail) perché la maggior parte dei mittenti invia anche da altri servizi; passa a -all solo quando ogni fonte legittima è in elenco.

Passo dopo passo

In Elastic Email
  1. 1

    Apri Manage Domains

    Accedi su app.elasticemail.com e vai a Settings → Domains → Manage Domains. Fai clic su Start Verification, digita il dominio da cui invii e fai clic su Continue. Elastic Email genera quindi i record DNS esatti per quel dominio.

  2. 2

    Leggi i record generati

    Nella schermata di verifica Elastic Email elenca i record da pubblicare: una riga TXT SPF, un record TXT DKIM sull'host api._domainkey, un CNAME di tracking (host tracking → api.elasticemail.com) e un record DMARC suggerito. Tieni aperta questa scheda: qui farai clic su Verify quando il DNS sarà attivo.

Nel tuo DNS
  1. 3

    Aggiungi o unisci il record SPF

    Presso il tuo provider DNS, aggiungi un record TXT sul dominio radice (host @ o vuoto) con v=spf1 a mx include:_spf.elasticemail.com ~all. Se esiste già un record SPF, NON crearne un secondo: unisci include:_spf.elasticemail.com alla riga v=spf1 esistente. Puoi togliere a e mx se non invii dal server web o di posta del tuo dominio.

  2. 4

    Pubblica il record TXT DKIM

    Aggiungi un record TXT con host api._domainkey e il valore mostrato nella tua dashboard (inizia con k=rsa; t=s; p=MIGf…). È la chiave DKIM condivisa di Elastic Email: copia il valore alla lettera da Manage Domains e non rinominare l'host.

  3. 5

    Aggiungi il CNAME di tracking

    Aggiungi un record CNAME con host tracking che punta a api.elasticemail.com. Fa comparire il tuo sottodominio sui link tracciati per aperture e clic e fa parte della verifica completa del dominio. Su Cloudflare, impostalo su “DNS only” (nuvola grigia) perché si risolva.

  4. 6

    Pubblica il record DMARC

    Aggiungi un record TXT sull'host _dmarc con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Parti da p=none (solo monitoraggio), così non cambia nulla mentre confermi l'allineamento, poi, in un secondo momento, inasprisci la policy.

In Elastic Email
  1. 7

    Fai clic su Verify record

    Torna alla schermata di verifica e fai clic su Verify record. Accanto a ogni record compare una spunta verde quando Elastic Email lo trova nel DNS. La propagazione può arrivare a 24-48 ore, quindi ricontrolla se un record non viene rilevato subito.

  2. 8

    Imposta il dominio come mittente predefinito

    Dopo la verifica, se vuoi, imposta il dominio come mittente predefinito, così le nuove campagne e gli invii via API lo useranno automaticamente. La verifica toglie anche il limite di 500 email al giorno previsto per i domini non verificati.

Verifica
  1. 9

    Invia un'email di prova e controlla le intestazioni

    Invia un messaggio da un indirizzo del dominio verificato, aprilo in Gmail e scegli ⋮ → Show original. Devi vedere DKIM: PASS signed-by yourdomain.com (selettore api), SPF: PASS e DMARC: PASS.

Record da aggiungere

Elastic Email genera i valori esatti nella sua procedura guidata di configurazione: questi mostrano la struttura di ciò che aggiungerai presso il tuo provider DNS.

TipoHostValore
TXT@v=spf1 a mx include:_spf.elasticemail.com ~allSPF radice: tieni un solo record SPF e unisci l'include a quello. Solo include:_spf.elasticemail.com autorizza Elastic Email; a e mx sono facoltativi. L'include consuma 2 ricerche DNS (include + una macro exists annidata).
TXTapi._domainkeyk=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbmGbQMzYeMvxw…Chiave DKIM CONDIVISA di Elastic Email (selettore api): ogni account pubblica lo stesso valore. Copia il valore completo alla lettera da Manage Domains; si allinea al tuo dominio anche se la chiave è condivisa.
CNAMEtrackingapi.elasticemail.comTracking di aperture e clic con il tuo brand. Fa parte della verifica completa. Su Cloudflare impostalo su “DNS only” (nuvola grigia).
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn solo record DMARC per dominio. Parti da p=none, poi 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 Elastic Email.

SPF 10-lookup budget2 used · 8 free

Elastic Email occupa 2 delle tue 10 ricerche; i meccanismi ip4: e ip6: non consumano ricerche.

DKIM

Il DKIM su Elastic Email è un'unica chiave pubblica condivisa con il selettore api, non una chiave per dominio generata da te. Ogni cliente pubblica lo stesso identico record TXT: host api._domainkey.yourdomain.com, valore k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ… (una chiave da 1024 bit). Puoi controllarlo tu stesso: api._domainkey.elasticemail.com si risolve nello stesso identico valore. Elastic Email custodisce l'unica chiave privata corrispondente e firma la tua posta in uscita con d=yourdomain.com, quindi anche se la chiave è condivisa la firma resta ALLINEATA al tuo dominio, ed è esattamente ciò che serve al DKIM per contribuire al superamento di DMARC. Dal fatto che sia condivisa derivano alcune cose: non puoi ruotare la chiave da solo, è una chiave da 1024 bit invece dei 2048 bit oggi standard, e devi copiare il valore esatto dalla tua schermata Manage Domains anziché incollarlo da un articolo di terze parti: se un giorno Elastic Email ruota la chiave condivisa, la fonte attendibile è la dashboard. Pubblicala esattamente come appare: non rinominare l'host api._domainkey, non trasformarlo in un CNAME e non aggiungere né togliere caratteri (il flag t=s nel valore è di Elastic Email, non un errore di battitura). In pratica è il DKIM a reggere DMARC in questa configurazione: si allinea al tuo dominio su ogni messaggio, inoltri compresi, mentre l'SPF aiuta solo quando il tuo dominio è il mittente della busta.

DMARC

DMARC è un record TXT separato che pubblichi tu: Elastic Email non lo crea, anche se la sua procedura di verifica te ne chiede uno. Aggiungi un record 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, ma chiede ai server riceventi di inviarti via email i report aggregati, così puoi confermare che la posta di Elastic Email superi DKIM (e, dove il tuo dominio è il mittente della busta, SPF) con allineamento al tuo dominio prima di applicare qualunque regola. La schermata di verifica di Elastic Email ti spinge subito verso p=quarantine o p=reject, e ha ragione nel dire che una policy none offre poca protezione, ma arrivaci con metodo: osserva i report rua per una o due settimane, conferma che ogni mittente legittimo (Elastic Email più gli altri strumenti sul dominio) sia allineato, poi passa a quarantine e infine a reject. Tieni esattamente un record _dmarc per l'intero dominio, a prescindere da quanti mittenti usi; non pubblicare mai un secondo record DMARC solo per Elastic Email.

Verifica che funzioni davvero

Non fidarti solo delle spunte verdi in Manage Domains: controlla su un messaggio reale. Invia un'email di prova da un indirizzo del dominio verificato, aprila in Gmail e scegli ⋮ → Show original: devi vedere DKIM: PASS signed-by yourdomain.com con selettore api, SPF: PASS e DMARC: PASS. Se l'SPF mostra un dominio di busta di Elastic Email invece del tuo, niente panico: è il DKIM a garantire il superamento di DMARC, e va bene così. Puoi anche controllare i record grezzi con dig TXT api._domainkey.yourdomain.com, dig TXT yourdomain.com (per la riga SPF), dig TXT _dmarc.yourdomain.com e dig CNAME tracking.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 resti sotto il limite di 10 ricerche (ricorda che l'include di Elastic Email ne consuma due) e, quando iniziano ad arrivare i report aggregati DMARC, caricane uno nell'analizzatore di report DMARC: Elastic Email dovrebbe comparire come sorgente allineata che supera i controlli.

Check-up del dominio Analizzatore di report DMARC

Insidie comuni

  • Configurazione DNS

    La chiave DKIM di Elastic Email è condivisa, non per dominio: ogni account pubblica lo stesso valore api._domainkey. È normale e si allinea comunque al tuo dominio, ma significa che non puoi ruotare la chiave da solo, che è una chiave da 1024 bit e che devi copiare il valore esatto da Manage Domains e non da un articolo di terze parti, nel caso Elastic Email la ruoti.

  • Fa fallire l'autenticazione

    L'include consuma DUE ricerche SPF, non una: include:_spf.elasticemail.com più la macro annidata exists:%{i}._spf.elasticemail.info. Se tieni a e mx suggeriti da Elastic Email, la riga consigliata arriva già a ~4 ricerche prima di aggiungere un altro mittente: attento al limite di 10 ricerche.

  • Fa fallire l'autenticazione

    Tieni esattamente un record SPF sul dominio. Se invii già tramite Google, Microsoft 365, un CRM o altro, unisci include:_spf.elasticemail.com alla riga v=spf1 esistente: due record SPF separati sono un PermError che rompe del tutto l'SPF.

  • Configurazione DNS

    a e mx nell'SPF consigliato da Elastic Email sono formule generiche per il tuo host web e di posta, non per Elastic Email. Se non invii davvero posta dal record A o dai server MX del tuo dominio, toglili e usa v=spf1 include:_spf.elasticemail.com ~all per recuperare due ricerche.

  • Configurazione DNS

    Su Cloudflare, imposta il CNAME di tracking su “DNS only” (nuvola grigia). Un CNAME con proxy attivo (nuvola arancione) non si risolve in api.elasticemail.com, quindi il tracking e la verifica completa falliscono.

  • Configurazione DNS

    I domini non verificati sono limitati a 500 email al giorno. Se i tuoi invii vengono rallentati senza avviso, quasi certamente il dominio non ha finito la verifica: per togliere il limite devi completare SPF + DKIM + il CNAME di tracking e fare clic su Verify.

  • Configurazione DNS

    Pubblica il record DKIM esattamente sull'host api._domainkey, come record TXT, con il valore alla lettera. Rinominare l'host, usare un CNAME o alterare la lunga stringa p= fa fallire il DKIM senza alcun avviso, mentre la dashboard può sembrare ancora in parte verde.

  • Copertura

    Invii da un sottodominio (es. mail.yourdomain.com)? Metti ogni record sul sottodominio: SPF sul sottodominio, api._domainkey.mail, tracking.mail e _dmarc.mail. I record del dominio radice non coprono un sottodominio di invio.

Crea il tuo record SPF

Elastic Email è già preselezionato qui sotto. Aggiungi le altre piattaforme con cui invii, poi pubblica l'unico record unificato.

1

Fonti di invio

Cerca ogni piattaforma con cui invii email e selezionala.

Selezionati
Guida →
2

Server propri del dominio

Autorizza il dominio stesso, se invia posta direttamente (non tramite una delle piattaforme sopra).

3

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.

4

Policy per tutti gli altri

Cosa devono fare i server riceventi con la posta proveniente da server non elencati sopra (il meccanismo all).

Il tuo record SPF1/10 ricerche DNS
v=spf1 include:_spf.elasticemail.com ~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 lista

SPF per Elastic Email: domande frequenti

Perché Elastic Email usa un'unica chiave DKIM condivisa sul selettore api per tutti i clienti, invece di generarne una per dominio. È una scelta voluta e non un problema: Elastic Email firma la tua posta con d=yourdomain.com, quindi la firma si allinea comunque al tuo dominio e supera DMARC. Gli unici compromessi sono che non puoi ruotare la chiave da solo e che è una chiave da 1024 bit. Copia sempre il valore dalla tua schermata Manage Domains, nel caso Elastic Email ruoti la chiave condivisa.

Due. include:_spf.elasticemail.com conta come una ricerca per l'include stesso, e il record in cui si risolve (v=spf1 exists:%{i}._spf.elasticemail.info ~all) contiene un meccanismo exists: che conta come seconda. Se tieni anche a e mx della riga consigliata da Elastic Email, il totale sale a quattro ricerche: tienine conto nel tuo budget di 10 ricerche.

A autenticare la tua posta sono SPF e DKIM, ma il CNAME di tracking (host tracking → api.elasticemail.com) fa parte della verifica completa del dominio ed è ciò che fa comparire il tuo sottodominio sui link tracciati per aperture e clic, al posto di uno generico di Elastic Email. Non influisce direttamente su SPF/DKIM/DMARC, ma aggiungerlo completa la verifica e migliora l'aspetto dei link tracciati agli occhi di destinatari e filtri.

È il limite di Elastic Email per i domini non verificati. Quando pubblichi SPF, DKIM e il CNAME di tracking e fai clic su Verify in modo che i record risultino verdi, il limite viene tolto e puoi inviare con l'intero volume del tuo piano. Se gli invii restano rallentati, il dominio non ha finito la verifica: ricontrolla i record nel DNS.

No. Elastic Email inserisce v=spf1 a mx … come modello generico, ma a e mx autorizzano l'host web e di posta del tuo dominio, non Elastic Email. Se non invii posta dal record A o dai server MX del tuo dominio, toglili e usa solo v=spf1 include:_spf.elasticemail.com ~all: risparmi anche due ricerche SPF.

Parti da ~all (softfail), che è ciò che propone Elastic Email, perché la maggior parte dei domini invia anche tramite altri servizi. Passa a -all (hardfail) solo quando sei certo che ogni mittente legittimo (Elastic Email più gli altri strumenti) sia presente in quell'unico record SPF, altrimenti farai andare in hard fail la posta che hai dimenticato di includere.

Sì, purché il DKIM superi i controlli. A volte Elastic Email usa un proprio dominio di busta/Return-Path, e in quel caso l'SPF autentica ma non si allinea al tuo dominio From. Qui è il DKIM il meccanismo che regge DMARC: firma con d=yourdomain.com e si allinea su ogni messaggio, inoltri compresi. Conferma DKIM: PASS con il tuo dominio in Show original e DMARC verrà superato.

Letture correlate

SPF, DKIM e DMARC spiegatiCome si combinano i tre record e cosa significa davvero “allineamento”: i concetti alla base di questa configurazione di Elastic Email.Come configurare DMARCPorta il record p=none di questa guida fino a una policy p=reject sicura, senza compromettere la posta.Requisiti per i mittenti di Google e YahooLe regole del 2024 per i mittenti di grandi volumi con cui viene valutata la tua posta di Elastic Email, e ciò che ora applica anche Microsoft.Come leggere i report DMARCInterpreta i report aggregati rua e conferma che Elastic Email compaia come sorgente allineata che supera i controlli.Check-up del dominioConferma che SPF, DKIM, CNAME di tracking e DMARC si risolvano tutti e che l'SPF resti sotto il limite di 10 ricerche.Generatore di record SPFUnisci l'include di Elastic Email in un'unica riga SPF pulita insieme agli altri mittenti, senza sforare il budget di ricerche.

Altri provider: Transazionali e API

Tutte le guide SPF
Monitora ogni giorno SPF, DKIM e DMARC di Elastic EmailConfigurare il record è un solo passaggio. Il monitoraggio check-up del dominio ricontrolla ogni giorno il numero di query SPF, le chiavi DKIM e la policy DMARC e ti scrive quando uno si rompe.Scopri il monitoraggio check-up del dominioSPF: troppe query DNS. Come contarle e correggere il permerror

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.

Inizia a verificare