Esempio di record DMARC: modelli per ogni politica

Ecco il record DMARC funzionante più semplice:

Pubblicalo come record TXT su _dmarc.tuodominio.com. Il gioco è fatto. Il tuo dominio ora dispone di un record DMARC valido che soddisfa i requisiti minimi richiesti da Google, Yahoo e Microsoft.

Se hai fretta, quel record è tutto ciò che ti serve in questo momento. Torna a leggere il resto di questa guida quando sarai pronto a capire a cosa serve ogni tag, come passare a politiche più rigorose senza compromettere la funzionalità della tua posta elettronica e perché DMARC può comunque fallire anche quando sia SPF che DKIM superano i controlli.

Per tutti gli altri: vediamo insieme cosa significa effettivamente il record DMARC, come funziona ogni livello di politica, quale errore di allineamento mette in difficoltà la maggior parte dei mittenti e come il DMARC si inserisce nel vostro quadro generale di deliverability in qualità di mittenti B2B.

Il record DMARC più semplice (e la funzione di ciascuna parte)

Un record DMARC è un singolo record DNS di tipo TXT pubblicato su un sottodominio specifico del proprio dominio:

Il record utile più semplice ha questo aspetto:

Tre parti. È tutto ciò che ti serve per iniziare.

v=DMARC1

Questo campo definisce la versione. Ogni record DMARC deve iniziare con questo campo. Deve apparire per primo, esattamente come riportato. Non deve esserci nulla prima di esso.

p=none

Questa è la politica. Indica ai server di posta in ricezione come comportarsi con i messaggi che non superano il controllo DMARC. Con p=none, la risposta è: nulla. La posta scorre normalmente. Si raccolgono i dati. Nessuna e-mail viene bloccata o filtrata a causa di questo record.

È proprio per questo che è il punto di partenza giusto. Stai attivando il monitoraggio senza interferire con la distribuzione.

rua=mailto:dmarc@yourdomain.com

Questo indica ai provider di caselle di posta elettronica dove inviare i tuoi report DMARC aggregati: riepiloghi giornalieri in formato XML che mostrano quali sistemi inviano e-mail utilizzando il tuo dominio e se superano l'autenticazione. Sostituisci l'indirizzo con uno che controlli effettivamente.

Senza rua=, non hai alcuna visibilità. Il record funziona, ma stai procedendo alla cieca.

Esempi di record DMARC in base alla politica

Ogni record DMARC contiene un tag di policy (p=) che indica ai server destinatari come comportarsi quando un’e-mail non supera l’autenticazione. Sono disponibili tre opzioni. Di seguito viene illustrato il formato di ciascuna di esse e quando utilizzarla. Per approfondire il funzionamento combinato di SPF, DKIM e DMARC, consulta la nostra guida su come implementare SPF, DKIM e DMARC.

p=nessuno - Modalità di monitoraggio

I messaggi non recapitati non vengono gestiti in alcun modo. Il flusso delle e-mail prosegue normalmente. Riceverai rapporti giornalieri che riportano tutti i sistemi che inviano e-mail utilizzando il tuo dominio, indicando se superano l'autenticazione e da dove provengono gli errori.

Utilizzare p=none quando:

• Stai configurando DMARC per la prima volta
• Non hai ancora individuato tutti i servizi che inviano e-mail per tuo conto
• È necessario avere una visione d'insieme prima di intervenire sul flusso di posta

Questo è anche il limite minimo richiesto da Google e Yahoo per i mittenti che inviano grandi quantità di email (oltre 5.000 email al giorno) e da Microsoft a partire da maggio 2025 per le email inviate a indirizzi Outlook, Hotmail e Live.

p=quarantena - Applicazione prudente

I messaggi che non vanno a buon fine vengono considerati sospetti. La maggior parte dei server di ricezione li reindirizza alla cartella dello spam o della posta indesiderata, invece di bloccarli direttamente.

Utilizzare p=quarantena quando:

• SPF e DKIM sono configurati correttamente su tutte le vostre piattaforme di invio
• I rapporti DMARC indicano che i mittenti legittimi superano l'autenticazione in modo costante
• Vuoi una protezione contro lo spoofing senza il rischio di un rifiuto categorico

p=rifiuto - Applicazione integrale

I messaggi non validi vengono respinti prima di raggiungere il destinatario. Si tratta della protezione contro lo spoofing più efficace attualmente disponibile.

Utilizzare p=reject solo quando:

• Hai monitorato i rapporti DMARC per settimane o mesi
• Ogni fonte di invio legittima viene identificata e autenticata
• L'allineamento SPF, DKIM e DMARC viene superato in modo coerente da tutti i tuoi mittenti
• Avete in atto una procedura per il monitoraggio dei nuovi strumenti prima che vengano inviati

Perché DMARC fallisce anche quando SPF e DKIM superano entrambi il controllo

Questo è il problema più comune legato al DMARC che riscontriamo, ed è proprio quello che i concorrenti tendono a nascondere in un'appendice o a tralasciare del tutto. Affrontiamolo quindi senza giri di parole.

Non è sufficiente che i controlli SPF e DKIM abbiano esito positivo. Affinché il controllo DMARC abbia esito positivo, almeno uno di questi risultati deve corrispondere al dominio che i destinatari vedono nell’indirizzo “Da:”.

Ecco cosa significa, in pratica, l’allineamento:

• Allineamento SPF: il dominio presente nel campo Return-Path dell'e-mail (il mittente della busta) deve corrispondere al dominio presente nell'indirizzo "Da:" visibile
• Allineamento DKIM: il dominio specificato nella firma DKIM (tag "d=") deve corrispondere al dominio presente nell'indirizzo "Da:" visibile

Il fattore scatenante più comune: si collega un CRM, un helpdesk, uno strumento di cold outreach o una piattaforma di marketing. Tale piattaforma invia e-mail utilizzando il proprio dominio nell’indirizzo “Da:”, ma dietro le quinte effettua l’autenticazione tramite il proprio dominio. SPF e DKIM superano i controlli per il dominio della piattaforma, ma non corrispondono al dominio indicato nel campo “Da:”. DMARC fallisce.

Lo vediamo continuamente quando i team aggiungono nuovi strumenti senza aggiornare la configurazione DNS. La soluzione consiste nel configurare ogni piattaforma di invio in modo che effettui l'autenticazione specificatamente tramite il proprio dominio, anziché tramite la propria infrastruttura condivisa.

Un record DKIM per ogni provider di servizi di posta elettronica (ESP), non per ogni strumento. Se un ESP invia email per più strumenti presenti nel tuo stack, è necessario un unico record DKIM per quell’ESP, configurato per firmare con il tuo dominio.

Come diagnosticare un problema di allineamento:

• Apri un'e-mail ricevuta e visualizza le intestazioni del messaggio originale
• Guarda l'intestazione "Authentication-Results": mostra i risultati di SPF, DKIM e DMARC e lo stato di allineamento
• Verifica che il dominio autenticato corrisponda al tuo dominio "Da:"
• Esamina i tuoi report aggregati DMARC per individuare eventuali modelli di errori di allineamento
• Esegui un vero e proprio test di consegna nella posta in arrivo con lo Spam Test gratuito di MailReach per verificare i risultati dell'autenticazione in condizioni reali di ricezione

Se riscontri errori DMARC che non ti sembrano giustificati, la nostra guida su come risolvere gli errori DMARC illustra le cause specifiche e le soluzioni.

Esempi di record DMARC per casi particolari

La maggior parte dei domini può partire dall'esempio di base p=none riportato sopra. Tuttavia, in alcuni casi è necessario un approccio diverso.

Domini inattivi e domini che non inviano e-mail

Se un dominio non invia mai e-mail — domini parcheggiati, registrazioni difensive, domini a tutela del marchio — il record DMARC corretto è un “hard reject” (rifiuto definitivo), senza necessità di un indirizzo di segnalazione:

In questo modo si indica a tutti i provider di posta elettronica di respingere qualsiasi email che dichiari di provenire da questo dominio. Poiché non dovrebbe mai essercene una legittima, non c'è alcun rischio di interferire con la posta autentica.

Domini secondari per le campagne di outreach tramite email a freddo nel settore B2B

Questo è il caso d'uso che la maggior parte delle guide su DMARC tralascia completamente.

Se svolgi attività di cold outreach B2B, dovresti utilizzare domini secondari, non sottodomini del tuo dominio principale. I sottodomini condividono la reputazione con il dominio principale. Un problema di deliverability su un sottodominio influisce anche sul tuo dominio principale. I domini secondari (tuadazienda.co, tuadazienda.io) sono completamente separati e si costruiscono una propria reputazione in modo indipendente.

Limitati alle estensioni più diffuse: .com, .co, .io. Evita i TLD poco conosciuti: suscitano sospetti prima ancora che la tua e-mail venga aperta.

Ogni dominio secondario richiede una configurazione completa dell'autenticazione:

• Un record SPF dedicato che elenca i mittenti autorizzati
• Chiavi DKIM configurate per ciascun ESP per quel dominio
• Il proprio record DMARC
• Un proprio processo di avvio per costruire da zero la reputazione del mittente

Per le attività di cold outreach B2B, DMARC rappresenta solo il livello di autenticazione. È il livello di reputazione che fa sì che le email passino dalla cartella dello spam alla posta in arrivo. Scopri come email warmup costruisce la reputazione del mittente di cui hanno bisogno i tuoi domini secondari.

Protezione dei sottodomini con il tag sp=

Per impostazione predefinita, i sottodomini ereditano la politica DMARC del dominio principale. Se desideri un controllo esplicito, utilizza il tag sp=:

p= si applica al dominio della tua organizzazione. sp= si applica a tutti i sottodomini. Se disponi di sottodomini inutilizzati che non dovrebbero mai inviare e-mail, bloccarli con sp=reject impedisce che vengano sfruttati per lo spoofing.

Come passare da p=none a Enforcement senza compromettere la posta

La pubblicazione del record DMARC richiede pochi minuti. L’implementazione richiede settimane. I team che incontrano difficoltà sono quasi sempre quelli che saltano la fase di monitoraggio e scoprono la presenza di mittenti mancanti solo dopo che le e-mail legittime iniziano a essere respinte.

Ecco la sequenza che funziona:

Passaggio 1: Pubblicare p=none e iniziare a raccogliere i rapporti

Lascia tutto così com’è per almeno due o quattro settimane. Verifica che i rapporti arrivino. Esaminali.

Fase 2: Identificare tutti i sistemi che inviano e-mail a nome del proprio dominio

È proprio qui che la maggior parte delle organizzazioni rimane sorpresa. Oltre al proprio provider di posta elettronica principale, controllate:

• Piattaforme CRM e strumenti di coinvolgimento delle vendite
• Piattaforme di automazione del marketing e di newsletter
• Servizio di assistenza e sistemi di gestione dei ticket
• Software per la fatturazione
• Applicazioni interne e notifiche automatiche
• Strumenti di acquisizione di nuovi clienti a freddo

I rapporti DMARC sono spesso il primo luogo in cui i team scoprono sistemi di invio di cui avevano dimenticato l'esistenza.

Fase 3: Configurare l'autenticazione e l'allineamento per ogni mittente

Per ogni piattaforma di invio troverai:

• Verificare che l'SPF sia configurato e che l'IP mittente sia autorizzato
• Pubblica i record DKIM e attiva la firma specificamente per il tuo dominio
• Verifica che il dominio autenticato corrisponda al tuo indirizzo "Da:"
• Verifica i risultati nei tuoi report DMARC prima di proseguire

Fase 4: Spostare in p=quarantena

Trasferisciti qui solo dopo che i tuoi report avranno confermato che l'autenticazione è corretta per tutti i tuoi mittenti. Continua a monitorare la situazione. Fai attenzione a eventuali email legittime che finiscono nella cartella della posta indesiderata.

Fase 5: Passare a p=rifiuto (quando le prove lo giustificano)

Passare alla modalità "p=reject" solo dopo mesi di attività senza problemi, con ogni mittente verificato, ogni problema di allineamento risolto e una procedura in atto per la verifica dei nuovi strumenti prima che inizino a inviare messaggi.

Una nota sul tag pct=: potresti trovare record DMARC che utilizzano pct=10 o pct=25 per applicare le misure di applicazione solo a una percentuale dei messaggi. Le linee guida attuali sconsigliano di fare affidamento su questa opzione, poiché i provider di posta elettronica non la implementano in modo coerente. Un'implementazione graduale che passi da p=none a p=quarantine e infine a p=reject è più affidabile.

Tag di segnalazione DMARC: cosa fanno effettivamente "rua" e "ruf"

I report DMARC ti consentono di monitorare ciò che accade dopo la pubblicazione del tuo record. Se la generazione dei report non è abilitata, potrai comunque applicare le politiche, ma non saprai quali sistemi superano i controlli, quali falliscono o quali tentano di inviare posta utilizzando il tuo dominio.

rua= (Rapporti aggregati)

I report aggregati sono riepiloghi giornalieri in formato XML inviati dai provider di caselle di posta partecipanti. Mostrano chi invia e-mail utilizzando il tuo dominio, quali indirizzi IP sono coinvolti e se superano o falliscono i controlli SPF, DKIM e DMARC.

Questo è proprio quello che ti serve. Per la maggior parte delle organizzazioni, basta il solo "rua=".

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Indicalo a una casella di posta dedicata che controllerai effettivamente. I provider inviano solitamente i report una volta al giorno. Ti verranno inviati file XML che richiedono un'analisi manuale o l'uso di uno strumento di reporting per poterli leggere facilmente.

ruf= (Rapporti forensi / Rapporti sui guasti)

I rapporti forensi contengono dettagli sui singoli errori di autenticazione. Sono facoltativi, non vengono inviati sistematicamente da tutti i provider e sollevano questioni relative alla privacy in alcune regioni. Per la maggior parte dei mittenti, l'impostazione corretta è quella che prevede solo "rua=".

Indirizzi per la rendicontazione esterna

Se il tuo indirizzo rua= utilizza un dominio diverso da quello di invio, il dominio di destinazione deve pubblicare un record DNS che lo autorizzi a ricevere i rapporti per tuo conto. In assenza di tale record, i rapporti potrebbero non essere recapitati, senza alcun avviso.

Verifica sempre che i rapporti arrivino entro pochi giorni dalla pubblicazione del tuo record DMARC. Se così non fosse, controlla innanzitutto questo requisito di autorizzazione.

Perché il DMARC da solo non basta a garantire il corretto inserimento dei messaggi nella posta in arrivo

Il DMARC è necessario. Ma non è sufficiente.

Google, Yahoo e Microsoft utilizzano l’allineamento SPF, DKIM e DMARC per stabilire se un messaggio sia stato autenticato correttamente. Per i mittenti con volumi elevati, questo livello di autenticazione è ormai un requisito imprescindibile. Senza di esso, le tue e-mail rischiano molto di più di finire nella cartella della posta indesiderata, di essere respinte o considerate sospette prima ancora che il contenuto e la reputazione vengano valutati. Ma questo non garantisce l’arrivo nella posta in arrivo. Tale decisione si basa su tre pilastri:

• Configurazione dell’invio (autenticazione): SPF, DKIM e DMARC - DMARC si trova qui
• Reputazione del mittente: determinata sulla base di segnali di coinvolgimento reali nel corso del tempo, quali l’apertura delle tue e-mail da parte dei destinatari su Gmail o Outlook, le risposte, le interazioni positive con la casella di posta, il basso numero di segnalazioni di spam e il posizionamento costante nella posta in arrivo
• Contenuto delle e-mail: struttura, link, parole che attivano i filtri antispam e come i tuoi messaggi vengono percepiti dai filtri

L'autenticazione è il minimo indispensabile. È ciò che ti permette di entrare in gioco. La reputazione è ciò che fa passare le tue e-mail dalla cartella dello spam alla posta in arrivo.

Soprattutto nel caso del cold outreach B2B, questo aspetto è fondamentale. Ti rivolgi a persone che non ti conoscono. Non c’è alcun rapporto preesistente, nessuna cronologia di interazioni, né alcun riconoscimento del marchio da parte del loro provider di posta elettronica. Un record DMARC pulito indica ai provider che la tua email proviene legittimamente da te. Non serve però a convincerli che valga la pena leggerla.

Ecco perché ogni dominio secondario di outreach necessita di un processo di "warmup", non solo di autenticazione. MailReach migliora la reputazione del mittente attraverso interazioni positive e significative con una rete di oltre 30.000 caselle di posta reali di Google Workspace e Microsoft 365. È il livello di reputazione che, insieme all'autenticazione, fa sì che le tue e-mail arrivino effettivamente nella posta in arrivo. Scopri come funziona " email warmup " e perché la qualità della rete è ciò che distingue un "warmup" efficace da tutti gli altri.

Domande Frequenti

Qual è un esempio di record DMARC?

L'esempio più semplice è v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, pubblicato come record TXT su _dmarc.yourdomain.com. v=DMARC1 imposta la versione, p=none indica ai destinatari di monitorare senza intervenire, mentre rua= indica dove devono essere inviati i rapporti aggregati. Si tratta del requisito minimo richiesto da Google, Yahoo e Microsoft per i mittenti di messaggi in massa.

"p=none" va bene?

Per iniziare e soddisfare i requisiti dei provider di posta in arrivo, sì. Anche "p=none" è il punto di partenza corretto perché garantisce visibilità senza interferire con la posta. Per ambienti di invio complessi con più piattaforme e fornitori, un "p=quarantine" ben monitorato è spesso la soluzione giusta a lungo termine. Non affrettarti a impostare "p=reject" prima che i tuoi report confermino che tutti i mittenti siano affidabili.

Perché il DMARC risulta non conforme quando sia l'SPF che il DKIM risultano conformi?

Allineamento. Il superamento dei controlli SPF e DKIM non è sufficiente: il dominio autenticato deve anche corrispondere al dominio presente nel campo "Da" visibile. Questo problema si verifica più spesso quando uno strumento di terze parti (CRM, helpdesk, piattaforma di outreach) autentica l'e-mail utilizzando il proprio dominio anziché il vostro. La soluzione consiste nel configurare ciascuna piattaforma in modo che firmi e autentichi utilizzando specificatamente il vostro dominio.

È necessario un record DMARC separato per ogni sottodominio?

Di solito no. Per impostazione predefinita, un unico record sul dominio della tua organizzazione regola i sottodomini. Utilizza il tag `sp=` per impostare una politica esplicita per i sottodomini: ad esempio, `sp=reject` per bloccare i sottodomini da cui non invii mai messaggi. I domini secondari utilizzati per le comunicazioni esterne, tuttavia, sono completamente separati e ciascuno richiede un proprio record DMARC.

Posso inviare i rapporti DMARC al mio indirizzo e-mail invece che a uno strumento a pagamento?

Sì. Basta inserire "rua=mailto:" in qualsiasi casella di posta di cui hai il controllo e riceverai gratuitamente dei report aggregati. L'unico inconveniente è che questi report arrivano in formato XML grezzo, il che è gestibile per un dominio di piccole dimensioni, ma diventa difficile da analizzare su larga scala. Per un singolo dominio di invio con attività limitata, la tua casella di posta personale va benissimo.

DMARC migliorerà la deliverability delle mie email a freddo?

Il DMARC è necessario ma non sufficiente. Senza di esso, Google, Yahoo e Microsoft possono respingere o classificare come spam le tue e-mail prima ancora che vengano valutate. Tuttavia, la sua presenza da sola non garantisce l’arrivo nella posta in arrivo: ciò dipende dalla reputazione del mittente e dal contenuto. Il DMARC garantisce l’autenticazione. L’arrivo nella posta in arrivo dipende da tutti e tre questi fattori. Consulta la nostra guida su come migliorare la deliverability delle e-mail per avere un quadro completo della situazione.

Microsoft richiede ora l'implementazione del DMARC?

Sì. A partire dal 5 maggio 2025, Microsoft richiede l’uso di SPF, DKIM e una politica DMARC minima impostata su p=none per i mittenti che inviano messaggi in massa (oltre 5.000 e-mail al giorno) a indirizzi Outlook.com, Hotmail.com e Live.com. I messaggi non conformi vengono inizialmente indirizzati alla cartella della posta indesiderata, per poi essere respinti. Google e Yahoo hanno adottato requisiti simili nel febbraio 2024. Tutti e tre i principali provider di posta elettronica richiedono ora il DMARC per la posta in massa.

‍