Come risolvere l'errore "Politica DMARC non abilitata".

Che cos'è l'errore "Politica DMARC non abilitata"?

L'errore "Politica DMARC non abilitata" significa che il suo dominio non sta applicando un'azione esecutiva tramite DMARC. In molti strumenti di , viene attivato quando..:

• Non è stato pubblicato alcun record DMARC per il suo dominio, oppure
• Esiste un record DMARC, ma il criterio DMARC di è impostato su p=none (solo monitoraggio), quindi non può intervenire sulle e-mail non autorizzate.

DMARC lavora con Sender Policy Framework (SPF) e DKIM per supportare l'autenticazione delle e-mail. SPF verifica se l'IP di invio è autorizzato (in base al suo record SPF). DKIM verifica la firma DKIM utilizzando il suo record DKIM. 

DMARC valuta quindi l'allineamento (chiamato anche allineamento dell'identificatore) per confermare se SPF o DKIM "corrisponde" al dominio visibile Da, che è ciò che rende l'autenticazione DMARC significativa per la protezione del marchio.

Perché un criterio DMARC potrebbe non essere abilitato

Il problema della politica DMARC non abilitata si riduce solitamente a una delle due cose: una configurazione DNS mancante o un'applicazione ritardata di .

Cause tecniche comuni

Questo problema è spesso radicato nella configurazione DNS e nell'allineamento dell'autenticazione. Prima di apportare modifiche alla policy, confermi che il record esiste, è valido e che SPF/DKIM sono impostati per allinearsi al suo dominio Da.

• Nessun record TXT DMARC DNS pubblicato sul suo server DNS (quindi gli strumenti mostrano "nessun record" o "record DMARC trovato: no")
• Il record DMARC esiste ma è incompleto (manca v=DMARC1 o p=), non riesce a convalidare dmarc.
• SPF/DKIM esistono, ma l'allineamento spf o l'allineamento DKIM non passano, quindi il proprietario del dominio esita a farli rispettare.
• I mittenti di terze parti (piattaforme di marketing, sistemi di ticketing, strumenti CRM) inviano posta senza la firma DKIM o SPF allineato.

Cause organizzative comuni

Anche quando i componenti tecnici sono disponibili, le organizzazioni possono ritardare l'applicazione a causa di preoccupazioni legate al rischio e alla scarsa visibilità del mittente . Questi blocchi sono comuni negli ambienti con più mittenti di terze parti e con una maturità di reporting DMARC limitata.

• Affidarsi solo a SPF/DKIM, senza rendersi conto che DMARC aggiunge l'applicazione e i rapporti DMARC.
• I sistemi di posta tradizionali e i complessi ecosistemi di mittenti rendono rischiosa l'implementazione del DMARC.
• Il timore di interrompere la deliverability delle e-mail, se l'applicazione viene attivata prima che tutti i mittenti siano stati registrati, è molto forte.
• La visibilità dei flussi di posta è limitata, quindi i team non sanno quali sistemi inviano per conto del dominio, finché non non iniziano il monitoraggio con p=none.

Ecco perché gli strumenti di reporting e di monitoraggio sono importanti per ridurre le congetture e rendere l'applicazione di un rollout controllato e graduale di .

Come risolvere l'errore "Politica DMARC non abilitata".

Passo 1: verificare se esiste un record DMARC

Esegua un controllo utilizzando un checker DMARC / uno strumento di ricerca DMARC. Sta cercando la conferma che un record DMARC è presente come record DNS TXT su:

_dmarc.yourdomain.com

Se lo strumento mostra "nessun record DMARC" (o simile), dovrà pubblicarne uno.

Passo 2: generare e pubblicare un record DMARC di base (p=nessuno)

Inizia con la modalità di monitoraggio per evitare di interrompere la posta legittima. Un semplice esempio di record DMARC:

v=DMARC1; p=nessuno; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100

• p=nessuno significa solo monitorare (nessuna applicazione).
• rua= abilita i rapporti aggregati DMARC, per aiutarla a vedere chi sta inviando come lei.
• adkim / aspf imposta il comportamento di allineamento (rilassato è un punto di partenza più sicuro)

Può crearlo con un generatore di record DMARC di (o con il flusso di lavoro "genera record DMARC"), quindi pubblicarlo come record TXT nel DNS.

Passo 3: convalidare l'allineamento SPF e DKIM prima di applicarlo

Prima di passare alla quarantena o al rifiuto:

• Confermi che l' autenticazione SPF funziona (il record SPF autorizza i mittenti giusti).
• Conferma che la firma DKIM funziona ( firma DKIM valida per ogni flusso di invio)
• Confermi l'allineamento per il dominio Da (allineamento SPF e/o allineamento DKIM).

Se non convalida prima l'allineamento, l'applicazione può avere un impatto sull'accettazione del provider di posta elettronica e sulla deliverability complessiva dell'e-mail .

Passo 4: passare dal monitoraggio all'applicazione in modo sicuro

Una volta che il reporting mostra che i flussi di e-mail legittime sono allineati, si procede con la politica di avanzamento:

• p=nessuno → p=quarantena (i messaggi che non superano il DMARC possono essere trattati come sospetti; spesso vengono indirizzati allo spam)
• p=quarantena → p=rifiuto (applicazione più forte; la posta che non riesce viene bloccata)

Questo approccio "road to enforcement" è ampiamente raccomandato: prima monitorare, poi stringere. Per risolvere in modo specifico "La politica DMARC non è abilitata ", molti verificatori si aspettano la quarantena o il rifiuto (cioè, l'applicazione abilitata).

Passo 5: utilizzare gli strumenti per gestire la complessità in scala

Se ha molti domini, molti mittenti o cambiamenti frequenti, un approccio DMARC in hosting può aiutarla:

• Vista centralizzata delle statistiche DMARC
• Aggiornamenti dei record più semplici
• Identificazione più rapida delle fonti che causano un fallimento DMARC
• Progressione di applicazione semplificata

Mimecast DMARC Analyzer include flussi di lavoro per la generazione e la pubblicazione di record DMARC e l'analisi dei dati DMARC, che aiuta a ridurre il rischio di interruzione durante il rollout.

Perché l'abilitazione del DMARC è importante per la sicurezza delle e-mail

Lasciare irrisolto il "Criterio DMARC non abilitato" significa che il suo dominio è più facile da falsificare. Senza l'applicazione della legge, i destinatari hanno meno istruzioni su cosa fare con i messaggi non autenticati che affermano di provenire da lei, il che aumenta l'esposizione al phishing e all'impersonificazione del marchio.

L'abilitazione dell'applicazione del DMARC supporta:

• Maggiore sicurezza delle e-mail (riduce le e-mail non autenticate che raggiungono i destinatari)

• Migliore fiducia nel marchio e reputazione del mittente nel tempo

• Migliore coerenza per il posizionamento della posta in arrivo quando la posta autentica è allineata

• Reporting più pulito e rilevamento più rapido di mittenti mal configurati

Può anche essere un prerequisito per alcuni indicatori del marchio. Molte implementazioni BIMI richiedono l'applicazione del DMARC (p=quarantena o p=rifiuto), il che significa che la "politica non abilitata" può bloccare il progresso del BIMI.

Passare da "Criterio DMARC non abilitato" alla protezione totale

"Criterio DMARC non abilitato" è un segno che il suo dominio non sta ancora applicando il DMARC, o perché non esiste un record DMARC o perché il suo criterio è ancora impostato sulla modalità di monitoraggio p=nessuno. La soluzione più sicura è un rollout graduale: pubblicare un record DMARC TXT valido, utilizzare il reporting per confermare l'allineamento tra tutti i mittenti, quindi passare alla quarantena e infine rifiutare.

Se desidera ridurre i rischi e accelerare l'impostazione e l'applicazione del DMARC, strumenti come Mimecast DMARC Analyzer possono aiutarla a tracciare i mittenti, a convalidare le modifiche e a gestire la reportistica su scala.