Te lo sei perso? La maggior parte dei fallimenti DMARC deriva da problemi di allineamento. SPF o DKIM possono passare, ma il dominio autenticato non corrisponde al tuo From header. Risolvi l'allineamento configurando i mittenti di terze parti affinché utilizzino il tuo dominio in Return-Path e nelle firme DKIM, valida la sintassi DNS e utilizza ARC per gestire l'inoltro. Parti con p=none, monitora i report settimanalmente e passa all'applicazione rigida solo dopo aver raggiunto tassi di successo superiori al 95%.
Punti chiave
- Allineamento ≠ autenticazione: SPF e DKIM possono passare ma DMARC può comunque fallire se il dominio autenticato non corrisponde al dominio del From header
- Ne basta uno allineato: DMARC passa se SPF oppure DKIM sono allineati. Non servono entrambi.
- I mittenti di terze parti sono di solito i responsabili: Piattaforme di marketing, CRM e tool di supporto spesso inviano usando i propri domini, rompendo l'allineamento
- Usa allineamento rilassato (impostazione predefinita) a meno che tu non abbia esigenze di sicurezza molto stringenti. Permette ai sottodomini di allinearsi con i domini principali.
- Inizia con p=none: Raccogli i report per almeno 2 settimane prima di passare a quarantine o reject
- Raggiungi il 95% di successi per almeno un mese prima di applicare p=reject
- Revisione settimanale dei report aggregati: Un calo improvviso nei successi indica che qualcosa è cambiato
- ARC preserva l'autenticazione durante l'inoltro: Non sostituisce SPF/DKIM ma aiuta quando le email vengono inoltrate
- SPF ha un limite di 10 lookup DNS: Superarlo causa errori intermittenti. Appiattisci gli include in IP se serve.
I fallimenti DMARC bloccano email legittime, danneggiano la reputazione del mittente e aprono falle che i cybercriminali possono sfruttare. Un solo record DNS fuori allineamento può mandare centinaia di messaggi business-critical in spam. Quando SPF passa e DKIM firma correttamente ma DMARC fallisce ancora, i team IT spendono ore tra report XML, troubleshooting DNS e coordinamento con fornitori per identificare la causa.
La buona notizia è che la maggior parte dei problemi DMARC è riconducibile a poche configurazioni errate: disallineamenti, errori di sintassi DNS e problemi con mittenti di terze parti sono i motivi più frequenti dei fallimenti di autenticazione. Capire come effettuare il debug di ciascun tipo di errore trasforma il vago "DMARC non funziona" in soluzioni concrete e attuabili.
I team di sicurezza che gestiscono l'autenticazione email hanno bisogno di un approccio sistematico per isolare rapidamente i problemi, siano essi dovuti a record DNS interni, piattaforme di marketing esterne o configurazioni di inoltro. Questa guida affronta i passi pratici di debug per ottenere autenticazione e recapito affidabili delle email.
Indice dei contenuti
- Cosa sono i fallimenti DMARC?
- Correzioni di allineamento SPF e DKIM
- Interpretare i report DMARC
- Correggere errori nei record DNS
- Gestione di inoltro e mittenti terzi
- Implementazione ARC per risultati migliori
- Ridurre i fallimenti DMARC: best practice
- Monitoraggio continuo e miglioramenti
- FAQ su debugging dei fallimenti DMARC
Cosa sono i fallimenti DMARC?
I fallimenti DMARC si verificano quando le email non superano i controlli di allineamento, anche se l'autenticazione SPF o DKIM passa singolarmente. Il protocollo DMARC richiede che almeno uno tra SPF o DKIM sia allineato col dominio del From header. L'allineamento significa che il dominio autenticato corrisponde al dominio del mittente che gli utenti vedono.
Scenario tipico di disallineamento:
Le newsletter marketing finiscono in spam anche se SPF passa per mailserver.vendor.com e la firma DKIM è valida. Il From header mostra marketing@company.com, ma l'autenticazione viene superata per i domini vendor.com—creando un disallineamento.
Soluzione: configura la piattaforma marketing per utilizzare company.com sia in Return-Path che nel parametro d= della firma DKIM. Una volta stabilito l'allineamento, DMARC passa e la deliverability torna normale.
DMARC valuta due tipi di allineamento
Tipo di allineamento | Cosa confronta | Risultato richiesto |
Allineamento SPF | Dominio Return-Path vs. dominio From header | I domini devono coincidere |
Allineamento DKIM | Parametro DKIM d= vs. dominio From header | I domini devono coincidere |
DMARC superato | Allineamento SPF o DKIM | Basta che uno passi |
Un'email da marketing@company.com autenticata da mailserver.vendor.com fallisce DMARC perché i domini non sono allineati. Il controllo SPF può passare per il dominio vendor, ma DMARC richiede l'allineamento con company.com.
Le mancate autenticazioni compaiono nei report aggregati come SPF non allineato, DKIM non allineato, o entrambi. I mail server riceventi spediscono questi report XML giornalieri all'indirizzo specificato nel record DMARC.
Correzioni di allineamento SPF e DKIM
I fallimenti di allineamento SPF derivano da incongruenze nel dominio Return-Path. Quando le email partono da servizi terzi, Return-Path spesso usa il dominio del vendor invece del tuo. La guida SPF e DKIM spiega come questi protocolli autenticano l'identità del mittente.
Guida alla scelta della modalità di allineamento
La tua configurazione di invio | Modalità consigliata | Motivazione |
Tutte le email solo dal dominio principale | Stretto (aspf=s) | Massima sicurezza, niente complessità per i sottodomini |
Marketing usa news.example.com | Rilassato (aspf=r) | Consente l'allineamento di sottodomini |
Molteplici servizi terzi | Rilassato (aspf=r) | Configurazione vendor più semplice |
Scopri come risolvere problemi di allineamento SPF e DKIM
Interpretare i report DMARC
I report aggregati DMARC arrivano come file XML compressi allegati ad email giornaliere [4]. Ogni report contiene i risultati di autenticazione raggruppati per fonte di invio, mostrando il numero di successi/fallimenti per allineamento SPF e DKIM.
L'indirizzo IP sorgente identifica ogni sistema di invio. Incrocia gli IP con i mail server interni conosciuti, le piattaforme marketing di terze parti e le app SaaS. Gli IP sconosciuti vanno indagati per capire se sono servizi leciti o mittenti non autorizzati.
Rendi l'interpretazione semplice con Red Sift OnDMARC
Albero delle decisioni per l'analisi dei report
Scenario | Volume | Autenticazione | Azione richiesta |
Mittente noto | Alto | Passa | Monitora i cambiamenti |
Mittente noto | Alto | Fallisce | Correggi subito |
Mittente noto | Basso | Passa | Continua a monitorare |
Mittente noto | Basso | Fallisce | Indaga: test o casi particolari |
IP sconosciuto | Qualsiasi | Fallisce | Indaga subito: potenziale spoofing |
Quando sia SPF che DKIM falliscono, esamina i problemi di allineamento specifici. Un fallimento SPF indica problemi sul Return-Path; uno DKIM segnala problemi sulla firma o record mancanti.
Dai priorità al debug così: prima i fallimenti ad alto volume, poi IP sconosciuti, poi problemi a basso volume.
Correggere errori nei record DNS
Basi della sintassi DNS:
Gli SPF devono iniziare con v=spf1 e terminare con -all o ~all. Il flag -all rifiuta mittenti non autorizzati mentre ~all li segnala senza rigettarli. Usa tool di controllo DMARC per validare la sintassi prima della pubblicazione.
Comandi per la validazione DNS:
- DMARC: dig _dmarc.tuodominio.com TXT
- SPF: dig tuodominio.com TXT
- DKIM: dig selector._domainkey.tuodominio.com TXT
- Propagazione: nslookup -type=TXT _dmarc.tuodominio.com 8.8.8.8
- Controllo sintassi: redsift.com/tools/investigate
Errori comuni di configurazione DNS
Errore | Sintomo | Correzione | Validazione |
Manca il tag v=spf1 | SPF fallisce per tutte le email | Aggiungi v=spf1 all'inizio del record | dig tuodominio.com TXT |
Superato limite 10 lookup DNS | SPF fallisce in modo intermittente | Appiattisci gli include in IP, oppure usa uno SPF Dinamico con Red Sift OnDMARC | Conta i comandi include: |
Selector DKIM errato | DKIM fallisce nonostante la chiave corretta | Associa il selector nel DNS a quello del mail server | Controlla le intestazioni per il valore s= |
Record DMARC su sottodominio errato | Nessuna enforcement DMARC | Mettilo su _dmarc.tuodominio.com | dig _dmarc.tuodominio.com TXT |
Manca indirizzo rua= | Nessun report aggregato ricevuto | Aggiungi rua=mailto:indirizzo@dominio.com | Attendi 24 ore per i report |
Trucco: gran parte dei problemi SPF derivano da limiti di lookup o da selector errati. Focalizzati prima su questi due elementi per una risoluzione più rapida.
Gestione di inoltro e mittenti terzi
L'inoltro delle email rompe l'autenticazione SPF perché i messaggi inoltrati partono da mail server intermedi non presenti nei record SPF. Ad esempio, quando user@company.com inoltra verso personal@gmail.com, Gmail vede l'IP del server di inoltro, non quello autorizzato.
Come l'inoltro compromette 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 OK ✓ → DMARC OK ✓
Dopo l'inoltro verso email personale: IP server inoltro: 203.0.113.5 (NON in SPF) → Return-Path: sender@company.com (invariato) → From: sender@company.com → SPF ✗ → DMARC ✗
SPF fallisce perché il Return-Path si riferisce ancora al dominio originale, ma l'IP è cambiato. Le firme DKIM a volte sopravvivono all'inoltro se i messaggi non vengono modificati.
Configurazione di terze parti:
- Usa invio da sottodomini - news.tuodominio.com invece di tuodominio.com
- Pubblica record SPF per ogni sottodominio - I sottodomini non ereditano nulla dal dominio principale
- Configura Return-Path personalizzati - Mantiene l'allineamento SPF mentre il vendor gestisce l'infrastruttura
- Aggiorna quando i vendor cambiano - I fornitori aggiungono server senza preavviso
Implementazione ARC per risultati migliori
Authenticated Received Chain (ARC) preserva i risultati di autenticazione durante l'inoltro e le modifiche tramite mailing list. Quando i messaggi passano tramite intermediari, ARC crea una catena di risultati d'autenticazione verificabili dai server destinatari [1].
Struttura dell'intestazione ARC
Intestazione ARC | Funzione |
ARC-Authentication-Results | Registra lo stato originale dell'autenticazione |
ARC-Message-Signature | Fornisce una firma crittografica |
ARC-Seal | Crea un sigillo anti-manomissione |
Ogni intermediario aggiunge i propri header ARC, costruendo una catena di autenticazione verificabile.
Opzioni di implementazione:
- Google Workspace / Microsoft 365 - Header ARC automatici (nessuna configurazione richiesta)
- Postfix / Sendmail - Self-hosted tramite moduli OpenARC
- OnDMARC - Piattaforma commerciale con validazione ARC
Importante: ARC non sostituisce SPF o DKIM. Li integra conservando i risultati di autenticazione quando l'inoltro interromperebbe altrimenti l'allineamento DMARC. I server destinatari che supportano ARC possono convalidare la catena e fidarsi dei messaggi che hanno superato l'autenticazione inizialmente.
Riduzione dei fallimenti DMARC: best practice
Documenta tutte le fonti autorizzate di invio prima di implementare le policy DMARC. Chiedi ai dipendenti quali strumenti per l'invio email usano. Le fonti di shadow IT comuni includono piattaforme di supporto (Zendesk), strumenti di marketing (HubSpot, Mailchimp), sistemi CRM (SalesForce) e piattaforme di sondaggio.
Auto-valutazione: la tua configurazione DMARC è a rischio?
- Esecuzione di p=quarantine/p=reject senza almeno 2 settimane a p=none
- Tasso di superamento dell'autenticazione inferiore al 95% per mittenti legittimi
- Servizi di terze parti che inviano senza configurazione SPF/DKIM
- Nessun processo di revisione settimanale dei report aggregati
- Record DNS non controllati da oltre 6 mesi
- I membri del team possono aggiungere strumenti per le email senza l'approvazione dell'IT
Se hai riscontrato 3 o più di questi punti: risolvi queste lacune prima di procedere con policy restrittive.
Inizia con p=none e raccogli i report per due settimane. Analizza per identificare tutte le fonti di invio e lo stato di autenticazione. Procedi a p=quarantine al 25% utilizzando il tag pct=, aumentando gradualmente fino a pct=100 prima di passare a p=reject.
La guida all'applicazione DMARC illustra i punti decisionali per la progressione della policy. Passa a p=reject solo dopo aver raggiunto tassi di successo dell'autenticazione superiori al 95% per almeno un mese.
Monitoraggio e miglioramento continui
DMARC richiede una gestione continua, non una configurazione una tantum. I fornitori di terze parti possono cambiare infrastruttura di invio, nuove applicazioni potrebbero inviare email senza approvazione IT e i record DNS possono scadere a seguito di rinnovi del dominio.
Best practice di monitoraggio
Attività | Frequenza | Trigger di azione |
Rivedi i report aggregati | Settimanale | Caduta del tasso di autenticazione >5% |
Aggiorna i record SPF | Trimestrale | Nuovi fornitori o cambiamenti infrastrutturali |
Controlla le configurazioni DNS | Ogni 6 mesi | Cambi di policy o dominio |
Monitora i tassi di autenticazione positivi per ogni fonte di invio. Se una piattaforma di marketing che solitamente ha un tasso di successo del 99% improvvisamente scende all'85%, è necessario indagare immediatamente.
I report aggregati rivelano i tentativi di spoofing tramite IP non autorizzati. I report forensi (ruf=) forniscono campioni di messaggi per il debug ma contengono contenuti email—utilizzali solo temporaneamente in fase di debug attivo.
OnDMARC invia notifiche in tempo reale quando i tassi di autenticazione scendono, identifica automaticamente nuove fonti di invio e monitora la conformità alle policy su più domini.
Riferimenti
[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