No DMARC record found: la riga che manca al tuo dominio

In breve

• Il messaggio significa che non esiste alcun record TXT in _dmarc.yourdomain.com. Il tuo server di posta non è guasto.
• Aggiungi un record TXT con host _dmarc e valore v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Con p=none la consegna resta esattamente com’era.
• Gmail, Yahoo e Outlook.com richiedono il record solo ai grandi mittenti. Aggiungilo comunque: Google conta l’intero dominio e non revoca mai lo stato di grande mittente, e i report partono solo quando esiste un record.
• Se uno strumento di controllo continua a non trovare nulla, cerca un provider DNS sbagliato, un nome host raddoppiato o due record DMARC. Due record si annullano a vicenda.
• Lo standard è cambiato a maggio 2026 con RFC 9989: pct è sparito, t e np sono nuovi. A ottobre 2026 la guida di Google descrive ancora pct.

«No DMARC record found» (nessun record DMARC trovato) significa che uno strumento di controllo ha chiesto al DNS un record TXT in _dmarc.yourdomain.com e non ha ricevuto nulla. Sul tuo server di posta non c’è niente di guasto. La soluzione è un record TXT con host _dmarc e valore v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Con p=none la tua posta viene consegnata esattamente come prima. Dici soltanto ai server riceventi che partecipi, e cominci a ricevere i report.

DMARC è il terzo dei tre record per l’email, accanto a SPF e DKIM. SPF elenca i server che possono inviare per il tuo dominio. DKIM firma ogni messaggio. DMARC dice a un server ricevente cosa fare quando nessuno dei due garantisce per il dominio del tuo indirizzo From, e dove inviare un riepilogo giornaliero. Da maggio 2026 è definito in RFC 9989, che ha sostituito la precedente RFC 7489. Molte guide descrivono ancora la versione precedente, e a ottobre 2026 lo fa anche la pagina di aiuto di Google.

Il record da aggiungere

Accedi dove viene gestito il DNS del tuo dominio. È l’azienda a cui puntano i tuoi nameserver, che non sempre è quella da cui hai comprato il dominio. Aggiungi un nuovo record con questi valori:

Scritto come riga di un file di zona, il record finito ha questo aspetto:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Sostituisci example.com con il tuo dominio. Le tre parti servono a questo:

• v=DMARC1 contrassegna la riga come record DMARC. Deve venire per primo, con DMARC1 in maiuscolo. In caso contrario i server riceventi ignorano l’intero record.
• p=none è la policy: tratta la mia posta come faresti comunque. Nulla viene bloccato o spostato nello spam a causa di questo record.
• rua=mailto:… è l’indirizzo per i report giornalieri. Crea quell’indirizzo, o un alias che inoltra a te, prima di pubblicare il record.

Google elenca gli stessi tre campi in Configurare DMARC. Chiede anche che SPF e DKIM funzionino da 48 ore prima di aggiungere DMARC. Se il tuo strumento di controllo segnala anche quei due, sistemali prima.

Come verificare che abbia funzionato

Interroga tu stesso il DNS. Su macOS o Linux apri un terminale e usa dig. Su Windows usa nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Se il record è attivo, la riga torna tra virgolette. Ecco cosa ha risposto il dominio di Google stesso il 5 ottobre 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Una risposta vuota significa che il record non c’è ancora, oppure non è dove lo cercano i server riceventi. Quando la tua interrogazione mostra la riga, esegui di nuovo lo strumento di controllo che ti aveva dato il messaggio. MXToolbox, per esempio, formula il problema come «No DMARC Record found» e spiega che «il tuo dominio non ha un record DMARC pubblicato».

Cosa significa ogni parte di un record DMARC

Un record è un elenco di coppie tag=value separate da punti e virgola. Nello standard solo v è obbligatorio, e deve essere il primo. Metti p al secondo posto: la guida di Google afferma che «i tag v e p devono essere elencati per primi», e lo standard precedente prevedeva lo stesso ordine. Questi sono i tag di RFC 9989, sezione 4.7:

I record più vecchi terminano spesso con pct=100. Il tag serviva ad applicare una policy a una parte della posta che fallisce. RFC 9989 lo ha rimosso, insieme a rf e ri, e ne dà il motivo:

L’esperienza operativa ha mostrato che il tag «pct» di solito non veniva applicato in modo accurato, a meno che il valore specificato non fosse 0 o 100 (il valore predefinito), e che le imprecisioni con gli altri valori variavano molto da un’implementazione all’altra.

I server riceventi devono ignorare i tag che non conoscono, quindi un vecchio pct=100 non fa danni. I record di yahoo.com e microsoft.com lo contenevano ancora il 5 ottobre 2026, e la pagina di aiuto di Google raccomanda ancora pct per un’introduzione graduale. In un record nuovo, lascialo fuori.

Ti serve DMARC se invii solo poche email al giorno?

Secondo le regole pubblicate dai grandi provider di posta, un record DMARC è obbligatorio quando invii grandi volumi. Al di sotto è una raccomandazione.

Le fonti sono le Linee guida per i mittenti di email di Google, le Sender Best Practices di Yahoo e l’annuncio di Microsoft per i mittenti ad alto volume, tutte aggiornate a ottobre 2026. Se invii trenta email al giorno da una casella, nessuno di loro pretende il record. Ci sono comunque tre motivi per aggiungerlo subito.

• La soglia si conta per dominio e non si azzera. Google somma tutti i messaggi verso account Gmail personali che provengono dallo stesso dominio principale, sottodomini compresi. Le sue FAQ per i mittenti dicono: «I mittenti che soddisfano i criteri sopra indicati almeno una volta sono considerati in modo permanente grandi mittenti».
• Sia Google sia Yahoo lo raccomandano a tutti. Google scrive: «ti consigliamo di configurare sempre SPF, DKIM e DMARC per i tuoi domini». Yahoo «esorta vivamente tutti i mittenti a pubblicare una policy DMARC per ogni dominio che invia posta».
• Senza il record non ricevi report. È dai report che vedi quali server inviano posta con il tuo dominio nella riga From, i tuoi strumenti come gli estranei.

Per i grandi mittenti il record mancante ha conseguenze. Le FAQ per i mittenti di Google riportano per questo caso l’errore temporaneo 4.7.31: «il dominio di invio non ha un record DMARC, oppure il record DMARC non specifica una policy DMARC». La stessa pagina dice che da novembre 2025 la posta che non soddisfa i requisiti va incontro a «rifiuti temporanei e permanenti».

Hai aggiunto il record e lo strumento di controllo non trova ancora nulla?

Allora di solito la causa è una di queste. Esaminale con l’interrogazione dig vista sopra.

• Hai modificato il DNS nel posto sbagliato. Se i tuoi nameserver sono presso un’azienda diversa dal tuo registrar, i record inseriti presso il registrar non vengono mai interrogati. dig +short NS example.com mostra chi risponde per il tuo dominio.
• L’host è sbagliato. Il record si trova su example.com stesso, oppure su un nome raddoppiato, come descritto sopra. I server riceventi chiedono solo _dmarc.example.com.
• Ci sono due record DMARC. Qui lo standard è rigido: «Se per una singola destinazione vengono restituiti più record di policy DMARC, vengono tutti scartati». Uniscili in uno solo. Due indirizzi per i report vanno in un unico rua, separati da una virgola.
• Il primo tag non è esattamente v=DMARC1. Le minuscole, un errore di battitura come DMARC 1 o un p= messo davanti rendono il record non valido.
• Il tipo di record non è TXT, oppure il valore è stato incollato da un documento con le virgolette tipografiche. Digita il valore come testo semplice, senza virgolette, a meno che la guida del tuo provider DNS non le richieda.
• Una vecchia risposta è ancora in cache. I resolver ricordano per un po’ che «il record non esiste». Interroga direttamente uno dei tuoi nameserver aggiungendo il suo nome alla richiesta, per esempio dig +short TXT _dmarc.example.com @ns1.example.net. Se lì il record compare, gli strumenti di controllo seguiranno.

Dove arrivano i report e cosa farne

Ogni server ricevente a cui è arrivata posta con il tuo dominio nella riga From invia un report all’indirizzo rua. Secondo la pagina di Google Informazioni sui report DMARC, vengono «di solito inviati una volta al giorno via email». Il report è un file XML, di solito compresso, allegato a un’email. RFC 9990 ne descrive il formato.

Google avverte che le grandi organizzazioni «potrebbero ricevere fino a centinaia o addirittura migliaia di report al giorno» e raccomanda un gruppo o una casella dedicata. Il numero dipende da quanto invii e a quanti domini, quindi una o due caselle ne generano molti meno. Basta un alias come dmarc@ con un filtro verso una cartella a parte.

L’indirizzo dovrebbe essere sullo stesso dominio del record. Se vuoi i report altrove, l’altro dominio deve dare il consenso pubblicando un proprio record. Senza, i server riceventi devono ignorare l’indirizzo (RFC 9990, sezione 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Per questo un indirizzo Gmail gratuito non funziona come indirizzo per i report: quando abbiamo controllato, il 5 ottobre 2026, gmail.com non pubblicava alcun record del genere.

Nel file, ogni blocco record rappresenta un server di invio: il suo indirizzo IP, il numero di messaggi e, sotto policy_evaluated, se DKIM e SPF sono passati per il tuo dominio. Cerchi due cose. I server che conosci e che mostrano fail vanno sistemati, e DMARC fallisce anche se SPF e DKIM passano spiega come. I server che non conosci sono uno strumento che avevi dimenticato oppure qualcuno che usa il tuo nome.

Dopo p=none: quando rendere più severa la policy

p=none è una modalità di monitoraggio. Soddisfa il minimo richiesto dai provider di posta e non impedisce a nessuno di falsificare il tuo indirizzo. Lo fanno solo p=quarantine, che chiede ai server riceventi di trattare come sospetta la posta che fallisce, e p=reject, che chiede loro di rifiutarla.

Prima di rendere più severa la policy, ogni fonte legittima della tua posta deve passare. RFC 9989 dice che queste lacune «DEVONO essere risolte prima di qualsiasi tentativo» di applicarla, e che, a seconda della frequenza con cui invii, per esserne sicuri «possono servire molti mesi» di report. La pagina di Google sull’introduzione graduale considera una settimana di report «di solito sufficiente». Con una casella e uno o due strumenti sei più vicino al dato di Google, ma concediti qualche settimana, così compaiono anche l’invio mensile delle fatture e il modulo di contatto.

Sul passo in sé le due fonti non concordano. Google suggerisce ancora p=quarantine; pct=5 e di aumentare poi il numero. Lo standard ha eliminato pct e offre invece questo:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y chiede ai server riceventi di trattare per ora i fallimenti a un livello più basso, cioè come none. Quando i report restano puliti, rimuovi t=y. Tieni presente che un server ricevente che non conosce il tag lo ignora e applica quarantine per intero, e che a ottobre 2026 le pagine di Google non menzionano t. Se una policy più severa colpirebbe posta che non puoi ancora sistemare, resta su p=none.

Dove entra in gioco WarmupBay

Quando colleghi una casella, WarmupBay controlla SPF, DKIM e DMARC del suo dominio. Se il record DMARC manca, te ne mostra uno già pronto da copiare. Puoi avviare comunque il riscaldamento. Se dopo 72 ore i record mancano ancora, il riscaldamento si ferma.

WarmupBay non può aggiungere il record al posto tuo, perché il DNS è tuo, e non raccoglie né legge i report DMARC. Si occupa del passo che viene dopo i record: la tua casella scambia qualche email al giorno con altre caselle di una rete condivisa, partendo da tre e salendo di una al giorno, così l’attività di invio cresce gradualmente. È gratuito per 10 email al giorno. Guarda cosa comprendono il controllo e il riscaldamento, oppure collega la tua casella quando il record è al suo posto.

Domande frequenti

Un record DMARC su example.com copre anche sottodomini come news.example.com?

Sì. Un server ricevente chiede prima un record in _dmarc.news.example.com. Se non c’è, ripiega sul record del dominio organizzativo, example.com. La policy applicata al sottodominio è quella indicata in sp, se l’hai impostata, altrimenti quella in p.

Posso pubblicare v=DMARC1; p=none senza un indirizzo rua?

Sì. È un record valido e conta come policy pubblicata. Non riceverai report, quindi non vedrai se la tua posta passa né chi altro usa il tuo dominio. Yahoo definisce fortemente consigliato un indirizzo rua funzionante, e Google raccomanda di includerne sempre uno.

Mi serve un record DMARC per un secondo dominio che uso solo per l’outreach?

Sì. I server riceventi consultano il dominio dell’indirizzo From di ogni messaggio, quindi un record sul dominio principale non copre un dominio diverso. Usa la stessa riga sul secondo dominio. Se i suoi report devono arrivare a un indirizzo sul dominio principale, il dominio principale deve pubblicare il record di autorizzazione descritto nella sezione «Dove arrivano i report».

Cosa deve pubblicare un dominio che non invia mai email?

La coppia più severa. Per i domini che non inviano mai posta M3AAWG raccomanda il record SPF v=spf1 -all e un record DMARC con p=reject, così nessuno può usarli in un indirizzo From. Per DMARC è la riga v=DMARC1; p=reject in _dmarc.

p=none è peggio per la mia posta rispetto a p=quarantine o p=reject?

Le regole per i mittenti pubblicate da Gmail, Yahoo e Outlook.com chiedono almeno p=none e niente di più severo. La policy decide cosa succede alla posta che fallisce DMARC, compresa quella falsificata a tuo nome. Una funzione richiede di più: BIMI, il logo accanto ai tuoi messaggi, richiede quarantine o reject secondo la guida di Google.

Fonti

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)