Debug dei fallimenti DMARC: una guida pratica

In breve: La maggior parte dei fallimenti DMARC deriva da problemi di allineamento. SPF o DKIM possono anche dare esito positivo, ma il dominio autenticato non corrisponde all’intestazione From. Risolvi l’allineamento configurando i mittenti terzi affinché utilizzino il tuo dominio sia in Return-Path sia nelle firme DKIM, verifica la sintassi DNS e usa ARC per gestire l’inoltro. Inizia con p=none, monitora i report settimanalmente e passa all’applicazione della policy solo dopo aver raggiunto tassi di successo superiori al 95%.

Punti chiave

• Allineamento ≠ autenticazione: SPF e DKIM possono andare a buon fine, ma DMARC può comunque fallire se il dominio autenticato non corrisponde a quello nell’intestazione From
• Basta che uno sia allineato: DMARC passa se o SPF o DKIM sono allineati. Non sono necessari entrambi.
• I mittenti terzi sono spesso la causa: Piattaforme di marketing, CRM e strumenti di assistenza spesso inviano messaggi usando i propri domini, rompendo l’allineamento
• Usa l’allineamento rilassato (predefinito) salvo esigenze di sicurezza molto stringenti. Permette che i sottodomini si allineino al dominio principale.
• Inizia con p=none: Raccogli report per almeno 2 settimane prima di passare a quarantena o a rifiuta
• Ottieni almeno il 95% di successi per almeno un mese prima di applicare p=reject
• Controlla i report aggregati ogni settimana: Un calo improvviso del successo indica un cambiamento
• ARC conserva l’autenticazione durante l’inoltro: Non sostituisce SPF/DKIM, ma aiuta quando le email vengono inoltrate
• SPF ha un limite di 10 lookup DNS: Superandolo si verificano errori intermittenti. Appiattisci gli include in IP se necessario.

I fallimenti nell’autenticazione DMARC bloccano email legittime, danneggiano la reputazione del mittente e lasciano scoperti punti di sicurezza sfruttabili dagli attaccanti. Un solo record DNS fuori allineamento può mandare centinaia di email cruciali in spam. Quando SPF va a buon fine e DKIM firma correttamente ma DMARC fallisce comunque, i team IT affrontano ore di analisi di report XML, troubleshooting DNS e coordinamento con i fornitori per identificare la causa principale.

La buona notizia: la maggior parte dei fallimenti DMARC deriva da pochi problemi di configurazione facilmente risolvibili. Disallineamenti, errori di sintassi DNS e problemi con mittenti terzi costituiscono la maggioranza degli insuccessi di autenticazione. Capire come effettuare il debug di ciascun tipo di fallimento trasforma i vaghi problemi “DMARC non funziona” in soluzioni concrete e azionabili.

I team di sicurezza che gestiscono l’autenticazione email hanno bisogno di approcci di debug sistematici per isolare rapidamente i problemi, sia che derivino da record DNS interni, da piattaforme di marketing di terze parti o da configurazioni di inoltro email. Questa guida copre i passaggi pratici di debug che permettono alle email di autenticarsi e recapitarsi in modo affidabile.

• Cosa sono i fallimenti DMARC?
• Correzione degli allineamenti SPF e DKIM
• Interpretazione dei report DMARC
• Correzione degli errori nei record DNS
• Gestione dell’inoltro e dei mittenti terzi
• Implementazione di ARC per risultati migliori
• Riduzione dei fallimenti DMARC: buone pratiche
• Monitoraggio continuo e miglioramento
• FAQ sul debug dei fallimenti DMARC

I fallimenti DMARC si verificano quando le email non superano il controllo di allineamento, anche se l’autenticazione SPF o DKIM è positiva individualmente. Il protocollo DMARC richiede che o SPF o DKIM siano allineati con il dominio dell’intestazione From. Allineamento significa che il dominio autenticato corrisponde a quello del mittente visibile visto dagli utenti.

Scenario comune di disallineamento:

Le newsletter marketing finiscono in spam nonostante SPF superi per mailserver.vendor.com e ci siano firme DKIM valide. L’intestazione From mostra marketing@company.com, ma l’autenticazione è passata per domini vendor.com—creando così un errore di allineamento.

Soluzione: Configura la tua piattaforma marketing affinché usi company.com sia nel Return-Path che nel parametro d= della firma DKIM. Una volta stabilito l’allineamento, DMARC supera e la deliverability torna alla normalità.

Un’email inviata da marketing@company.com autenticata da mailserver.vendor.com fallisce DMARC perché i domini non sono allineati. Il controllo SPF può anche andare a buon fine per il dominio vendor, ma DMARC richiede l’allineamento con company.com.

I fallimenti di autenticazione compaiono nei report aggregati come SPF alignment failed, DKIM alignment failed o entrambi. I server di posta destinatari inviano questi report XML ogni giorno all’indirizzo email specificato nel tuo record DMARC.

I problemi di allineamento SPF derivano da disallineamenti nel dominio Return-Path. Quando le email vengono inviate da servizi di terze parti, Return-Path spesso utilizza il dominio del fornitore invece del tuo. La guida SPF e DKIM spiega come questi protocolli autenticano l’identità del mittente.

I report aggregati DMARC arrivano come file XML compressi allegati a email giornaliere [4]. Ogni report contiene risultati di autenticazione raggruppati per sorgente di invio, mostrando i conteggi di successo/fallimento per l’allineamento SPF e DKIM.

L’indirizzo IP sorgente identifica ogni sistema di invio. Incrocia gli IP con server di posta interni noti, piattaforme marketing di terze parti e applicazioni SaaS. Gli IP sconosciuti richiedono indagini per capire se si tratta di servizi legittimi o mittenti non autorizzati.

Ecco come si presenta effettivamente un record singolo all’interno di un report aggregato:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>438</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>company.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>company.com</domain><result>pass</result></dkim>
    <spf><domain>mail.vendor.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Leggilo così: 438 messaggi sono stati inviati da un IP. DKIM ha autenticato per company.com e si allinea con l’intestazione From, quindi DMARC passa su DKIM. SPF ha autenticato per mail.vendor.com ma non si allinea con company.com, quindi il risultato SPF sotto policy_evaluated indica fail. Il messaggio passa comunque DMARC perché basta che un metodo sia allineato. Interpretare male questa riga, vedere SPF "fail" e pensare che tutto il messaggio sia fallito, è l’errore più comune dei team quando aprono il primo report.

Quando sia SPF che DKIM falliscono, esamina i problemi specifici di allineamento. SPF fallito indica problemi su Return-Path; DKIM fallito indica problemi di firma o assenza di record.

Dai priorità al debug in questo ordine: prima i fallimenti ad alto volume, poi gli IP sconosciuti e infine i problemi a basso volume.

Basi della sintassi DNS:

I record SPF devono iniziare con v=spf1 e terminare con -all o ~all. La direttiva -all blocca i mittenti non autorizzati mentre ~all li rifiuta in modo blando. Usa strumenti di verifica DMARC per controllare la sintassi prima della pubblicazione.

Comandi di validazione DNS:

• DMARC: dig _dmarc.yourdomain.com TXT
• SPF: dig yourdomain.com TXT
• DKIM: dig selector._domainkey.yourdomain.com TXT
• Propagazione: nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8
• Verifica sintassi: redsift.com/tools/investigate

Suggerimento Pro: La maggior parte dei problemi SPF si riconducono al limite di lookup o ai selettori. Concentrati su questi due aspetti per una risoluzione più rapida.

L’inoltro email rompe l’autenticazione SPF perché i messaggi inoltrati provengono da server intermedi non elencati nei record SPF. Quando user@company.com inoltra a personal@gmail.com, Gmail vede l’IP del server di inoltro, non quello del mittente autorizzato.

Come l’inoltro email rompe l’autenticazione:

Prima dell’inoltro: IP mittente originale: 192.0.2.1 (autorizzato in SPF) → Return-Path: sender@company.com → From: sender@company.com → SPF superato ✓ → DMARC superato ✓

Dopo l’inoltro tramite mail personale: IP server di inoltro: 203.0.113.5 (NON in SPF) → Return-Path: sender@company.com (invariato) → From: sender@company.com → SPF fallito ✗ → DMARC fallito ✗

SPF fallisce perché l’envelope sender (Return-Path) resta quello del dominio originale ma l’IP di invio è cambiato in quello del server di inoltro. Le firme DKIM possono sopravvivere all’inoltro se i messaggi rimangono invariati.

Configurazione di mittenti terzi:

• Usa sottodomini per l’invio - news.yourdomain.com invece di yourdomain.com
• Pubblica record SPF per tutti i sottodomini - I sottodomini non ereditano nulla dal dominio padre
• Configura Return-Path personalizzati - Mantieni l’allineamento SPF mentre il fornitore gestisce l’infrastruttura
• Aggiorna quando i fornitori cambiano - I provider aggiungono server senza avvisare

Authenticated Received Chain (ARC) conserva i risultati dell’autenticazione anche in caso di inoltro o di modifiche da parte di mailing list. Quando i messaggi passano per intermediari, ARC crea una catena di risultati che i server destinatari possono validare [1].

Ogni intermediario aggiunge i propri header ARC, creando una catena di autenticazione auditabile.

Opzioni di implementazione:

• Google Workspace / Microsoft 365 - Header ARC automatici (nessuna configurazione necessaria)
• Postfix / Sendmail - Self-hosted tramite i moduli OpenARC
• OnDMARC - Piattaforma commerciale con validazione ARC

Importante: ARC non sostituisce SPF o DKIM. Li integra preservando i risultati dell'autenticazione nei casi in cui l'inoltro romperebbe l'allineamento DMARC. I server riceventi che supportano ARC possono validare la catena e fidarsi dei messaggi che hanno superato l'autenticazione inizialmente.

Documenta tutte le fonti di invio autorizzate prima di implementare le policy DMARC. Interroga i dipendenti sugli strumenti che utilizzano per l'invio di email. Le fonti shadow IT più comuni includono piattaforme di supporto (Zendesk), strumenti di marketing (HubSpot, Mailchimp), sistemi CRM (SalesForce) e piattaforme di sondaggi.

Autovalutazione: la tua configurazione DMARC è a rischio?

1. Esecuzione di p=quarantine/p=reject senza almeno 2 settimane a p=none
2. Tasso di autenticazione sotto il 95% per i mittenti legittimi
3. Servizi di terze parti inviano mail senza configurazione SPF/DKIM
4. Nessun processo di revisione settimanale dei report aggregati
5. Record DNS non verificati da oltre 6 mesi
6. I membri del team possono aggiungere strumenti email senza approvazione IT

Se hai selezionato 3 o più punti: affronta queste lacune prima di applicare le policy di enforcement.

Inizia con p=none e raccogli report per due settimane. Analizza i dati per identificare tutte le fonti di invio e lo stato dell'autenticazione. Passa a p=quarantine al 25% utilizzando il tag pct=, poi aumenta gradualmente fino a pct=100 prima di impostare p=reject.

La guida all’enforcement DMARC ti accompagna nei punti decisionali del percorso delle policy. Passa a p=reject solo dopo aver ottenuto tassi di autenticazione superiori al 95% per almeno un mese.

DMARC richiede una gestione continua e non una configurazione una tantum. I fornitori terzi modificano la propria infrastruttura di invio, nuove applicazioni inviano email senza l’approvazione dell’IT e i record DNS possono scadere durante i rinnovi dei domini.

Monitora i tassi di autenticazione per ciascuna fonte di invio. Se una piattaforma di marketing che raggiunge normalmente il 99% improvvisamente scende all'85%, è necessario indagare immediatamente.

I report aggregati rilevano tentativi di spoofing tramite IP non autorizzati. I report forensi (ruf=) forniscono esempi di messaggi per il debug ma contengono contenuti delle email—usali solo temporaneamente per il debug attivo.

OnDMARC fornisce alert in tempo reale in caso di calo dei tassi di autenticazione, identifica automaticamente nuove fonti di invio e monitora la conformità alle policy su più domini.

[1] Wikipedia contributors. "Authenticated Received Chain." Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Authenticated_Received_Chain

[2] InfraForge. "Why DMARC Fails When SPF and DKIM Pass." InfraForge AI Blog. https://www.infraforge.ai/blog/why-dmarc-fails-when-spf-and-dkim-pass

[3] Kitterman, S. "RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1." Internet Engineering Task Force (IETF). April 2014. https://datatracker.ietf.org/doc/html/rfc7208

[4] Kucherawy, M. and Zwicky, E. "RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)." Internet Engineering Task Force (IETF). March 2015. https://datatracker.ietf.org/doc/html/rfc7489