Creare un record DMARC: DNS, tag e politiche email

La decisione di creare un record DMARC arriva spesso dopo un problema: messaggi falsificati, avvisi di Gmail, modifiche DNS richieste da un fornitore o risultati SPF e DKIM diversi tra gli invii. Se stai ancora configurando il sistema, parti dalla nostra guida alla posta aziendale per coordinare dominio, caselle e DNS fin dall’inizio.

Una configurazione errata non provoca sempre un problema immediato. Il record può esistere senza essere usato come previsto: nome sbagliato, politica non valida, report non ricevuti o autenticazione senza allineamento. La falsificazione può continuare e la posta legittima finire nello spam; pubblicare DMARC non garantisce il recapito.

Questa guida spiega come creare un record DMARC, quali tag verificare, cosa pubblicare su _dmarc.yourdomain.com e come valutare il passaggio dal monitoraggio alle restrizioni.

Che cosa pubblichi quando crei un record DMARC

Pubblica un TXT su _dmarc.yourdomain.com che inizi con v=DMARC1 e contenga una politica valida: p=none, p=quarantine o p=reject. DMARC richiede un trattamento al destinatario quando nessun meccanismo fornisce un risultato valido e allineato a From. Basta che SPF o DKIM passi con allineamento per superare DMARC.

Questo è un esempio minimo valido:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

Pubblica una politica senza restrizioni DMARC, ma non richiede report aggregati perché manca la destinazione. I destinatari possono continuare ad applicare i propri filtri locali.

Ecco una politica iniziale alternativa con richiesta di report:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Se i test giustificano le restrizioni, sostituisci la politica precedente anziché aggiungerne un’altra:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

RFC 7489 richiede che v sia il primo tag e che p sia presente. Senza questo formato valido, i destinatari non possono applicare il record come politica DMARC. Consulta i dettagli in RFC 7489.

Dove creare il record DMARC nel DNS

Il record non si pubblica alla radice, ma su _dmarc. Per example.com, il nome completo della ricerca è _dmarc.example.com. Un altro nome non rende disponibile la politica in quella ricerca DMARC.

Un errore comune è usare @ o inserire _dmarc.example.com in un pannello che richiede solo _dmarc e aggiunge automaticamente il dominio. Verifica se il fornitore richiede un nome relativo o completo.

Dopo la pubblicazione, interroga il DNS dall’esterno del pannello:

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

Deve esserci una sola politica DMARC valida che inizi con v=DMARC1. Più stringhe TXT possono costituire lo stesso record; altri TXT non sono necessariamente politiche DMARC.

In TrekMail puoi aggiungere il dominio, copiare i valori indicati e usare i controlli DNS disponibili confrontandoli con ricerche esterne. Consulta l’aggiunta di un dominio, i record DNS necessari e la verifica dello stato DNS. Il pannello non dimostra da solo l’autenticazione di tutti i flussi.

I tag di un record DMARC

Molti tag sono facoltativi. Parti da v, p e, per richiedere report, rua. Modifica l’allineamento per un’esigenza precisa, dopo aver verificato la configurazione di base.

Tag	Obbligatorio	Funzione	Consiglio pratico
`v`	Sì	Identificatore di versione	Deve essere `DMARC1` e comparire per primo
`p`	Sì	Politica per i messaggi che non superano DMARC	Parti da `none`, poi valuta `quarantine` e `reject` in base ai test
`rua`	No	Destinazione dei report aggregati	Usa una destinazione monitorata; i report dipendono dai destinatari partecipanti e possono richiedere autorizzazione esterna
`ruf`	No	Destinazione dei report di errore	Facoltativo, con supporto limitato e possibili dati sensibili; verifica privacy e accesso
`adkim`	No	Modalità di allineamento DKIM	`r` è il valore predefinito; ogni modifica richiede una verifica dei mittenti
`aspf`	No	Modalità di allineamento SPF	Parti da `r`; usa `s` solo per un’esigenza di allineamento rigoroso di cui hai provato gli effetti
`pct`	No	Percentuale richiesta di applicazione ai messaggi in errore	`100` non garantisce copertura universale; il campionamento dipende dal destinatario e non impone restrizioni con la politica di monitoraggio
`sp`	No	Politica ereditata dai sottodomini	Si applica dal dominio organizzativo se il sottodominio non ha un proprio record; se il tag manca, viene ereditata la politica principale

Un record valido con p=none ma senza rua non richiede report aggregati. I tuoi log e gli altri strumenti restano disponibili, ma l’osservazione tramite report DMARC è limitata.

Come scegliere la politica DMARC

Se non hai validato tutti i mittenti, spesso è utile partire da p=none. Valuta p=quarantine dopo aver esaminato i report e corretto i servizi. Considera p=reject dopo aver confrontato le fonti sconosciute con inventario, log e test dei flussi critici poco frequenti.

Politica	Trattamento richiesto	Quando valutarla	Rischio principale
`p=none`	Nessuna restrizione DMARC; restano i filtri locali	Osservazione iniziale	Non richiede il blocco dei messaggi falsificati
`p=quarantine`	Trattamento restrittivo secondo la politica locale del destinatario	Dopo la validazione di mittenti e flussi	La posta legittima mal configurata può subire restrizioni senza recupero garantito
`p=reject`	Rifiuto richiesto, con possibili eccezioni locali	Configurazione validata e rischi valutati	I messaggi legittimi in errore possono essere rifiutati

Le indicazioni di Google citate richiedono SPF e DKIM ai mittenti di grandi volumi e almeno un meccanismo riuscito e allineato a From per DMARC. Non trasformare possibili sviluppi futuri in obblighi attuali; verifica condizioni e ambito nelle domande frequenti sulle linee guida di invio di Google.

DMARC non è una semplice casella da spuntare. Se il CRM usa il tuo dominio in From ma firma e invia con domini del fornitore non allineati, DMARC può fallire anche quando il fornitore dichiara l’autenticazione attivata.

Creare un record DMARC passo dopo passo

Organizza una distribuzione graduale: inventario, politica di monitoraggio e restrizioni dopo le verifiche. L’assenza di sorprese nei report non dimostra che tutti i mittenti funzionino.

Elenca i servizi che inviano con il tuo dominio, inclusi Google Workspace, Microsoft 365, assistenza, CRM, moduli, fatturazione e newsletter.
Verifica SPF e DKIM per ogni servizio e almeno un meccanismo valido e allineato. DMARC non li sostituisce né li corregge. Pubblica un SPF valido per ogni dominio reale della busta e rispetta il limite applicabile ai meccanismi e modificatori che richiedono DNS, comprese le valutazioni annidate.
Crea una casella come dmarc@yourdomain.com o usa un servizio di report, con monitoraggio, accesso adeguato e autorizzazione DNS sul dominio destinatario esterno quando richiesta.
Pubblica inizialmente una politica p=none.
Esamina i report aggregati disponibili e confrontali con i mittenti conosciuti e i loro log.
Correggi i domini autenticati e l’allineamento a From; modificare la politica DMARC non basta.
Valuta p=quarantine dopo aver provato i flussi.
Valuta p=reject quando i test, inclusi i processi poco frequenti, giustificano il cambiamento.

Questo esempio di monitoraggio per un dominio aziendale nel 2026 va adattato alla tua destinazione dei report:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Se usi l’inoltro, consulta come inoltrare la posta del dominio a Gmail. L’inoltro può far fallire SPF. DKIM può permettere a DMARC di passare se la firma resta valida e allineata e i dati firmati sono preservati dopo la canonicalizzazione. ARC può orientare un’eccezione locale del destinatario, ma non fornisce da solo un risultato di autenticazione DMARC valido.

Errori comuni nella creazione di un record DMARC

Molti problemi nascono dalla configurazione: nome errato, più politiche DMARC, destinazioni dei report non valide o aspettative che DMARC corregga SPF e DKIM. Pubblica una politica valida e verificala dall’esterno.

Questi errori si ripetono spesso:

1. Pubblicare alla radice anziché su _dmarc.
Un record su @ non compare nella ricerca DMARC del dominio.

2. Pubblicare più politiche DMARC in TXT.
RFC 7489 indica che più politiche DMARC impediscono di proseguire l’elaborazione. Mantieni una politica per nome di ricerca; i frammenti di un TXT non sono politiche separate.

3. Attivare p=reject fin dall’inizio.
Un servizio dimenticato può causare il rifiuto di reimpostazioni delle password, fatture o risposte legittime dell’assistenza.

4. Far puntare rua a una casella inesistente.
Puoi perdere report effettivamente inviati. L’assenza di report non dimostra neppure che i destinatari li abbiano generati.

5. Aspettarsi che DMARC corregga gli inoltri.
DMARC richiede SPF o DKIM valido e allineato. Se SPF fallisce nell’inoltro, DKIM deve restare valido e allineato per fornire quel risultato.

Esempio: il sito invia conferme con un fornitore SMTP, l’assistenza con un altro e il marketing con un terzo. Pubblichi p=reject senza verificare i tre servizi. Un flusso passa, due falliscono: i destinatari possono rifiutare messaggi necessari ai clienti. La politica non ha corretto i servizi ancora da configurare.

Se configuri il dominio da zero, la nostra guida per creare email con il tuo dominio illustra DNS e caselle insieme a SPF, DKIM e DMARC.

Gestione distribuita o centralizzata di DMARC su più domini

Fogli di calcolo, accessi a ogni registrar e TXT copiati da vecchi ticket complicano il coordinamento. Un’interfaccia centrale e controlli DNS possono aiutare a individuare differenze, ma ogni dominio e servizio di invio richiede una configurazione verificata.

Gestione distribuita	Gestione con TrekMail
Controllare ogni registrar per identificare i valori DNS attuali	Usare l’interfaccia multidominio disponibile nel piano
Confrontare manualmente i TXT e presumere che la propagazione sia terminata	Interrogare il DNS e valutare le differenze, senza garantire la propagazione completa
Coordinare SPF, DKIM e DMARC con strumenti separati	Usare il flusso DNS disponibile e verificare messaggi di ogni servizio reale
Pagare per utente anche con poche caselle per dominio	Valutare l’offerta multidominio da $3.50 al mese, secondo limiti e condizioni attuali

Secondo il piano, TrekMail offre più domini, spazio condiviso, caselle IMAP, strumenti di migrazione, catch-all, inoltro e SMTP gestito o proprio. La copia IMAP non sostituisce il cambio dei record MX e non migra tutte le applicazioni. L’offerta Nano descritta permette fino a 10 domini senza costi con SMTP proprio; i piani a pagamento partono da $3.50 al mese secondo le relative condizioni. Verifica funzionalità e prezzi attuali nella pagina dei prezzi di TrekMail.

Centralizzare può facilitare le verifiche e il coordinamento tra cinque fornitori e venti schede. Non dimostra automaticamente lo stato di tutti i flussi e non garantisce risparmi o una riduzione degli incidenti.

Verifiche finali prima di applicare restrizioni DMARC

Prima delle restrizioni, verifica SPF e DKIM dei mittenti autorizzati, almeno un risultato valido e allineato per flusso, la destinazione dei report e una sola politica DMARC valida su _dmarc. DMARC non sostituisce un’autenticazione corretta.

Rivedi questa lista:

Una sola politica DMARC in TXT.
Nome _dmarc, relativo o completo secondo il fornitore DNS.
Valore che inizia con v=DMARC1; p=....
rua punta a una casella o servizio valido, monitorato e autorizzato quando necessario.
Un SPF valido per dominio della busta, con autorizzazioni riunite e rispetto del limite DNS applicabile, comprese le valutazioni annidate.
DKIM configurato e verificato sulle piattaforme compatibili, con almeno un meccanismo allineato per flusso.
Le ricerche esterne mostrano la politica prevista.
Parti da none se devi ancora validare mittenti e flussi poco frequenti.

TrekMail può centralizzare domini personalizzati, caselle IMAP, controlli DNS, scelta SMTP e strumenti di migrazione secondo il piano. Questo non elimina il monitoraggio continuo e non garantisce il recapito. Consulta trekmail.net e valuta le funzionalità in base alle tue esigenze operative.