Hai pubblicato un record DMARC con un indirizzo rua=, hai aspettato qualche giorno e la tua casella è vuota. Nessun report, nessun errore, niente che ti dica se il record è sbagliato o se sei solo in anticipo. Le cause sono poche e facili da verificare, se conosci l'ordine giusto. Questa guida percorre la checklist, dal test più economico (la pazienza) a quelli più tecnici come l'autorizzazione della destinazione esterna, e spiega che aspetto ha ogni guasto.
In breve#
I report DMARC mancanti dipendono quasi sempre da una di sette cause: non hai ancora aspettato 24-48 ore, il record si trova nel nome DNS sbagliato, c'è più di un record DMARC, il valore rua= è malformato (deve iniziare con mailto:), l'indirizzo dei report è in un altro dominio senza autorizzazione, il tuo dominio invia troppa poca posta perché i riceventi facciano report, oppure la casella filtra gli allegati compressi. Controllale in questo ordine. Una ricerca in tempo reale di _dmarc.yourdomain.com risolve i primi quattro punti in meno di un minuto. dig TXT _dmarc.yourdomain.com +short è ciò che rivela un secondo record, perché il verificatore SPF, DKIM e DMARC gratuito ne mostra solo il primo che trova e non controlla la sintassi di rua=. Se il record è corretto e sono passati alcuni giorni, guarda la casella di destinazione.
Passaggio 1: dai tempo al tempo e sappi chi invia i report#
I provider raggruppano ciò che hanno visto in un giorno e inviano un report per dominio, quindi i primi report arrivano 24-48 ore dopo l'attivazione del record, e a volte più tardi. Il primo giorno non arriverà nulla.
Altri due punti fissano le aspettative:
- Non tutti i riceventi inviano report. I grandi provider di posta sì. Molti più piccoli non lo faranno mai. Stai raccogliendo un campione di provider, non un log completo.
- Un ricevente fa report solo se ha visto posta da te. Se ieri il tuo dominio non ha inviato nulla a un certo provider, quel provider non ha nulla da segnalare.
Se hai aspettato tre giorni pieni, passa al record.
Passaggio 2: conferma che il record sia dove deve essere#
I record DMARC risiedono in un nome preciso: _dmarc. davanti al tuo dominio. Un record pubblicato sul dominio nudo, o su dmarc.example.com, viene ignorato. Controlla cosa è davvero pubblicato:
dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"
Cosa verificare nella risposta:
- Il record esiste. Alcuni host DNS vogliono solo
_dmarcnel campo host, non il nome completo. Se scrivi il nome completo, aggiungono il tuo dominio due volte. I passaggi specifici per host sono in guide come Cloudflare e GoDaddy. - Inizia con
v=DMARC1, esattamente, senza nulla davanti. - Include un tag
p=. Secondo l'RFC 9989 un record senzap=valido ma conrua=valido viene trattato comep=nonee genera comunque report, quindi di solito non è la causa dei report mancanti, ma pubblica comunque il tag in modo esplicito. - I tag sono separati da punto e virgola.
Ricorda la cache DNS. Se hai appena modificato il record, i riceventi possono usare la vecchia copia fino alla scadenza del TTL.
Passaggio 3: assicurati che ci sia un solo record DMARC#
Un dominio deve pubblicare un solo record DMARC. Se due record TXT su _dmarc iniziano entrambi con v=DMARC1, i riceventi di solito li ignorano entrambi e i report si fermano. Succede quando qualcuno aggiunge un nuovo record senza eliminare il vecchio, o quando una migrazione DNS copia il record due volte.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:old@example.com"
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:new@example.com"
Elimina un record, tieni l'altro e riunisci gli indirizzi in un unico elenco rua=. Più destinazioni di report si separano con virgole all'interno di un solo record, non pubblicando altri record.
Passaggio 4: controlla la sintassi di rua#
Il valore rua= è un elenco di URI e ognuno deve iniziare con mailto:. Errori tipici:
| Cosa è pubblicato | Problema |
|---|---|
rua=reports@example.com | Manca mailto: |
rua=mailto:reports@example.com mailto:other@example.com | Due indirizzi senza virgola tra loro |
rua=mailto:reports@exmaple.com | Errore di battitura nel dominio, quindi i report non vanno da nessuna parte |
v=DMARC1; rua=mailto:reports@example.com | Nessun tag p=. L'RFC 9989 lo tratta come p=none quando rua è valido, ma un ricevente che segue le regole precedenti può ignorare il record, quindi pubblica p= in modo esplicito |
Solo ruf=mailto:reports@example.com | ruf richiede report di errore, che molti provider non inviano. I report aggregati richiedono rua |
L'ultima riga fa inciampare molti. I report aggregati arrivano da rua. Impostando solo ruf non riceverai quasi nulla. L'elenco completo dei tag è in come configurare DMARC.
Passaggio 5: autorizza i report verso un altro dominio#
È la causa che le persone dimenticano più spesso. Se il tuo indirizzo rua= è in un dominio diverso da quello protetto dal record, i riceventi verificano che l'altro dominio abbia accettato di ricevere i report. Altrimenti chiunque potrebbe indirizzare valanghe di report verso la casella di una vittima.
Prendi questo record per example.com:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"
Poiché l'indirizzo è fuori da example.com, il dominio ricevente deve pubblicare un record di autorizzazione con un nome costruito a partire dal tuo dominio:
example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1;"
Se quel record TXT non esiste, i riceventi conformi scartano il report. Puoi verificarlo con:
dig TXT example.com._report._dmarc.thirdparty.example.net +short
Due note pratiche:
- Se controlli entrambi i domini, aggiungi semplicemente il record di autorizzazione nella destinazione. Se è un fornitore a ricevere i report per te, di norma è il fornitore a pubblicarlo o a dirti di farlo.
- Inviare i report a una casella nel tuo stesso dominio evita del tutto il controllo, ed è per questo che un semplice inoltro
dmarc@yourdomain.comè la configurazione meno fragile.
Passaggio 6: controlla la casella di destinazione#
Se il record è valido e l'autorizzazione è a posto, i report potrebbero arrivare e perdersi:
- Filtraggio degli allegati. I report arrivano come allegati
.gzo.zip, a volte come XML puro. I filtri di posta che eliminano gli allegati compressi li scartano in silenzio. Controlla spam, quarantena e qualsiasi regola che cancelli gli archivi. - Casella piena. Un dominio con molto traffico può produrre decine di report al giorno. Una piccola casella condivisa si riempie in fretta e inizia a rifiutarli.
- Alias o inoltro che riscrive. Un alias di gruppo che blocca i mittenti esterni rifiuterà i report dei provider.
Cerca oggetti che includano "Report Domain" e il nome del tuo dominio. Se non ne vedi nessuno dopo aver controllato i filtri, il problema è a monte.
Una casella dedicata, o un servizio che riceve i report per te, evita la maggior parte di questi problemi. L'XML grezzo in una casella personale seppellisce inoltre il segnale, come spiegato in come leggere i report DMARC.
Se usi un indirizzo di report Qualisend#
Se il tuo rua= punta a un indirizzo <key>@dmarc.qualisend.com di DMARC Reports, i controlli sulla destinazione sono gestiti per te. Qualisend pubblica un record di autorizzazione con wildcard, quindi i provider invieranno a quell'indirizzo per qualsiasi dominio, e non devi aggiungere il record di autorizzazione del passaggio 5. Questi sono gli ulteriori motivi che possono ancora bloccare i dati:
- Il dominio non è coperto. I report vengono salvati solo per i domini con la copertura attiva nel tuo workspace, o per un sottodominio di uno di essi. Un report per un dominio non coperto viene accettato ma non salvato, quindi la dashboard resta vuota.
- L'abbonamento non è attivo. I report inviati a un indirizzo il cui workspace non ha un abbonamento DMARC attivo vengono rifiutati.
- L'indirizzo è stato ruotato. Dopo una rotazione il vecchio indirizzo smette subito di accettare posta, quindi ogni
rua=che lo elenca ancora perderà report finché non aggiorni il DNS. - Il record non elenca l'indirizzo. Se esiste già un record DMARC, aggiungi
,mailto:<address>al suo elencorua=e mantieni la policy e gli altri indirizzi.
Qualisend non modifica mai il tuo DNS. La modifica del record spetta a te, presso il tuo host DNS. La pagina ti indica che i primi report di solito arrivano entro 24-48 ore, in linea con ciò che fanno i provider.
Sottodomini e il record che prevale#
Se i report mancanti riguardano un sottodominio, guarda cosa è davvero pubblicato lì. Un sottodominio con un proprio record DMARC usa quel record, e se quel record non ha rua=, non viene inviato nulla all'indirizzo del dominio padre. Un sottodominio senza record ricade sul record del dominio padre e sulla sua policy sp=. I report indicheranno il dominio nella policy, quindi cercali con quel nome e non con quello del tuo dominio principale.
Conviene far passare l'intero dominio in un controllo della salute del dominio dopo ogni modifica DNS. Segnala un record DMARC mancante, un record senza tag di policy e una policy p=none, e mostra il record pubblicato così puoi leggere tu stesso il valore rua=. Anche il monitoraggio check-up del dominio a pagamento avvisa quando una policy valida non ha alcun rua=. Se il problema si ripete dopo le modifiche DNS, la guida al monitoraggio della salute del dominio email spiega come individuarlo prima che i report si fermino.
Una checklist finale#
- Aspetta 48 ore dopo l'attivazione del record.
- Esegui
dig TXT _dmarc.yourdomain.come leggi il risultato. - Conferma un solo record, che inizia con
v=DMARC1, con unp=esplicito. - Conferma
rua=mailto:con virgole tra gli indirizzi. - Se l'indirizzo è in un altro dominio, verifica il record di autorizzazione
_report._dmarc. - Controlla spam, quarantena, limiti di dimensione e filtri sulla casella di destinazione.
- Assicurati che il dominio abbia davvero inviato posta ai provider che fanno report.
Quando i report finalmente arrivano, il compito successivo è capirli, e se ne parla in monitoraggio DMARC e chi sta inviando con il tuo dominio.
Domande frequenti
01Quanto tempo ci vuole per ricevere i report DMARC?
I provider raggruppano ciò che hanno visto in un giorno e inviano un report per dominio, quindi i primi report di norma arrivano 24-48 ore dopo l'attivazione del record, e a volte più tardi. Se hai aspettato tre giorni pieni, controlla il record, la sua sintassi e la casella di destinazione invece di aspettare ancora.
02Perché serve un record TXT in _report._dmarc per gli indirizzi esterni?
Se il tuo indirizzo rua è in un dominio diverso da quello protetto dal record, i riceventi verificano che l'altro dominio abbia accettato di ricevere i report. La destinazione pubblica un record TXT che ha come nome il tuo dominio, seguito da _report._dmarc e dal proprio dominio, con valore v=DMARC1;. Senza di esso, i riceventi conformi scartano i report.
03Perché ricevo report DMARC da alcuni provider ma non da altri?
Non tutti i riceventi inviano report aggregati, e un ricevente fa report solo se ha visto posta dal tuo dominio nel periodo. I grandi provider di posta li inviano con regolarità, molti più piccoli non lo fanno mai. I tuoi report descrivono i provider che li inviano, non tutta la tua posta.
04Due record DMARC sullo stesso dominio possono bloccare i report?
Sì. Un dominio deve pubblicare un solo record DMARC. Se due record TXT su _dmarc iniziano entrambi con v=DMARC1, i riceventi di solito li ignorano entrambi e i report si fermano. Elimina un record e riunisci gli indirizzi in un unico elenco rua, separato da virgole, nel record rimasto.
Far arrivare i report DMARC ti mostra chi invia con il tuo dominio, ma non se la tua lista è pulita. Se vuoi controllare subito la lista, il piano gratuito nella pagina dei prezzi ti dà 100 crediti per la verifica completa, e il verificatore email gratuito gestisce i singoli indirizzi. Un'autenticazione funzionante ha comunque bisogno di una lista sana per meritarsi la inbox.
