Correggere gli errori DMARC: 8 cause di «dmarc=fail»

Come il destinatario decide su DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) si basa su due controlli. SPF verifica se il server di invio è autorizzato per il dominio del mittente indicato nella busta dell'e-mail. Questo indirizzo si chiama Return-Path e non è visibile al destinatario. DKIM verifica una firma digitale che un determinato dominio appone all'e-mail.

DMARC è superato solo se almeno uno dei due controlli è superato e il suo dominio corrisponde all'indirizzo del mittente visibile (From). Questa corrispondenza si chiama allineamento. Per impostazione predefinita vale l'allineamento flessibile: i domini devono solo avere lo stesso dominio principale. bounce.example.com è quindi allineato con example.com, newsletter.example.net no.

Trovare la causa nell'intestazione dell'e-mail

Invii un'e-mail di prova a una casella esterna e apra le intestazioni complete. In Gmail il comando si chiama «Mostra originale», in Outlook trova le intestazioni nelle proprietà del messaggio. Cerchi la riga Authentication-Results. Si presenta più o meno così:

Authentication-Results: spf=pass smtp.mailfrom=bounce.newsletter.example.net;
 dkim=pass header.d=newsletter.example.net;
 dmarc=fail action=none header.from=example.com

Confronti tre domini: header.from è il suo dominio mittente visibile. smtp.mailfrom è il dominio per cui è stato verificato SPF. header.d è il dominio della firma DKIM. Se nessuno dei due corrisponde a header.from, DMARC fallisce, anche se SPF e DKIM sono superati singolarmente.

Trovare la causa nel rapporto DMARC

I rapporti DMARC dei destinatari mostrano tutte le e-mail inviate con il suo dominio, raggruppate per indirizzo IP di invio. Per ogni fonte vede il risultato di SPF e DKIM, i domini controllati e il risultato DMARC. Cerchi le fonti con un volume rilevante in cui DMARC è rosso. Come leggere i file XML lo spiega la guida Leggere il rapporto DMARC: cosa c'è nei file XML e cosa farne

Errore 1: SPF e DKIM superati, ma non per il suo dominio

Come riconoscerlo: nell'intestazione o nel rapporto compaiono spf=pass e dkim=pass, ma dmarc=fail. I domini di smtp.mailfrom e header.d appartengono al fornitore, non a lei. È il classico errore di allineamento DMARC.

Come risolverlo: faccia in modo che almeno un controllo avvenga con il suo dominio. La soluzione più affidabile è una firma DKIM con d=example.com. Molti servizi offrono inoltre un proprio dominio Return-Path, per esempio bounce.example.com tramite un record CNAME. Così è allineato anche SPF.

Errore 2: sistemi terzi senza firma DKIM propria

Come riconoscerlo: le e-mail principali da Microsoft 365 o Google Workspace passano, ma newsletter, CRM, software di contabilità o negozio online falliscono. Nel rapporto compaiono indirizzi IP sconosciuti con dkim=none o con una firma del fornitore.

Come risolverlo:

1. Elenchi tutti i sistemi che inviano con il suo indirizzo, comprese stampanti, sistema di ticket e modulo di contatto.
2. Cerchi in ogni strumento l'impostazione del dominio mittente. Spesso si chiama «autentica il dominio» o simile.
3. Inserisca nel DNS i record DKIM indicati, per esempio un CNAME sotto s1._domainkey.example.com. Il selettore s1 è solo un esempio; usi esattamente il nome indicato dallo strumento.
4. Avvii la verifica nello strumento e invii un'e-mail di prova.

Se un sistema non può firmare con il suo dominio, lo faccia inviare tramite il suo server di posta oppure gli assegni un sottodominio proprio.

Errore 3: SPF supera dieci interrogazioni DNS

Come riconoscerlo: l'intestazione riporta spf=permerror, spesso per tutte le fonti contemporaneamente. Di solito poco prima è stato aggiunto un ulteriore include: alla voce SPF.

Come risolverlo: SPF consente al massimo dieci interrogazioni DNS. Oltre questo limite l'intera voce è considerata errata e SPF non può più salvare DMARC. Rimuova i servizi non utilizzati e per i sistemi terzi si affidi a DKIM. Come contare e accorciare lo spiega la guida Errore SPF «too many DNS lookups»: perché il limite di dieci interrogazioni va rispettato

Errore 4: inoltri

Come riconoscerlo: nel rapporto compare una piccola quantità di e-mail da server che non conosce, per esempio quello di un'università o di un'associazione. SPF fallisce, DKIM per lo più è superato.

Come risolverlo: con un inoltro invia un server estraneo, quindi SPF fallisce per forza. L'importante è che tutte le sue e-mail portino una firma DKIM con il suo dominio. La firma sopravvive all'inoltro finché nessuno modifica il contenuto.

Nel dettaglio, anche su SRS e ARC: Inoltro email: SPF fail ed email inoltrate nello spam

Errore 5: sintassi errata della voce DMARC

Come riconoscerlo: invece di dmarc=fail compare dmarc=none o un permerror. I rapporti non arrivano, anche se ha indicato un indirizzo.

Come risolverlo: una voce corretta è un record TXT sotto _dmarc.example.com con il valore v=DMARC1; p=none; rua=mailto:dmarc@example.com. Errori tipici:

• v=DMARC1 non sta all'inizio, oppure p= non segue subito dopo.
• Virgole invece di punti e virgola tra i parametri.
• L'indirizzo per i rapporti senza mailto:.
• Due record TXT con v=DMARC1. In questo caso i destinatari non applicano alcun DMARC.
• L'editor DNS aggiunge da solo il dominio. Così _dmarc.example.com diventa _dmarc.example.com.example.com. Come nome inserisca solo _dmarc.

Errore 6: sottodomini

Come riconoscerlo: le e-mail con un indirizzo mittente come info@fatture.example.com falliscono, il dominio principale passa. Oppure tutto ha cominciato a fallire dopo aver impostato adkim=s o aspf=s.

Come risolverlo: senza una voce DMARC propria, per i sottodomini vale la voce del dominio principale, con sp= se presente, altrimenti con p=. SPF invece non si eredita: se il sottodominio ha bisogno di SPF, gli serve una propria voce SPF. Configuri SPF e DKIM per i sottodomini che inviano. L'allineamento rigoroso (s per strict) richiede domini identici. Mantenga l'impostazione flessibile predefinita finché non c'è un motivo chiaro per cambiarla.

Errore 7: passaggio troppo precoce a p=reject

Come riconoscerlo: l'errore in realtà c'era già, ma lo nota solo ora. I clienti segnalano e-mail mancanti e i mittenti ricevono rifiuti con «rejected due to DMARC policy».

Come risolverlo: p=reject non causa un dmarc=fail, rende solo visibili le conseguenze. Torni temporaneamente a p=quarantine o p=none, risolva la fonte e inasprisca di nuovo quando i rapporti sono puliti da alcune settimane. Cosa succede con il rifiuto lo spiega «Rejected due to DMARC policy»: il proprio dominio blocca le proprie e-mail e quando il passaggio è sicuro lo trova in DMARC da p=none a quarantine e reject: quando è sicuro?

Errore 8: chiave DKIM cambiata o eliminata

Come riconoscerlo: funzionava da mesi, poi all'improvviso compare dkim=fail o «no key for signature». Spesso dopo un cambio di hoster, una pulizia del DNS o un cambio di chiave nel sistema di posta.

Come risolverlo: legga il selettore nell'intestazione (header.s oppure s= nella firma) e verifichi che sotto <selettore>._domainkey.example.com ci sia una voce completa. Con Microsoft 365 devono rimanere entrambi i record CNAME selector1 e selector2, anche se al momento ne è attivo solo uno. Gli altri messaggi di errore DKIM sono spiegati in Firma DKIM non valida: «body hash did not verify» e altri errori

Verificare che la correzione funzioni

1. Attenda che la modifica DNS sia visibile. A seconda dell'impostazione ci vogliono da alcuni minuti a qualche ora.
2. Invii dal sistema interessato un'e-mail di prova a una casella esterna e verifichi dmarc=pass nell'intestazione.
3. Controlli i rapporti DMARC dei giorni successivi. La fonte deve risultare verde presso tutti i grandi destinatari.

Cosa fa DomainRadar per voi

DomainRadar le fornisce un indirizzo per i rapporti, analizza ogni giorno i rapporti DMARC e attribuisce gli indirizzi IP ai servizi. Vede a colpo d'occhio quale fonte fallisce e se la causa è SPF, DKIM o l'allineamento. Se compare una nuova fonte con errori o scompare un selettore DKIM, riceve un allarme.