DMARC: come configurarlo senza bloccare le email

DMARC protegge il dominio dagli abusi del campo From e fornisce indicazioni ai server destinatari sui messaggi che non superano i controlli. Una policy restrittiva applicata prima di aver censito newsletter, CRM, gestionali, moduli, gateway e inoltri può però causare il rifiuto di posta autentica.

Che cos’è DMARC

DMARC significa Domain-based Message Authentication, Reporting and Conformance. Il controllo usa SPF e DKIM, ma aggiunge un requisito fondamentale: almeno uno dei due meccanismi deve superare la verifica con un dominio allineato a quello mostrato nel campo From.

In modo semplificato:

• SPF verifica se la sorgente è autorizzata per il dominio dell’envelope sender;
• DKIM verifica la firma e il dominio che ha firmato il messaggio;
• DMARC confronta questi domini con il From visibile all’utente;
• la policy indica come trattare i messaggi non conformi;
• i report aiutano a scoprire sorgenti legittime e tentativi di abuso.

Prima di creare il record DMARC

Non partire dal record. Prima prepara un inventario di tutti i sistemi che inviano email con il dominio:

• caselle Xlogic e Webmail;
• client configurati con SMTP autenticato;
• moduli WordPress e siti web;
• newsletter e marketing automation;
• gestionali, CRM e fatturazione;
• e-commerce e sistemi transazionali;
• Google Workspace o Microsoft 365;
• servizi di ticketing, firma, monitoraggio e alert;
• apparati o applicazioni che inviano notifiche.

Per ogni sorgente verifica:

1. quale dominio usa nel From;
2. quale dominio usa nell’envelope sender o Return-Path;
3. quale dominio firma con DKIM;
4. se SPF passa;
5. se DKIM passa;
6. se almeno uno dei due è allineato.

Verifica SPF e DKIM in cPanel

Apri cPanel → Email → Email Deliverability e controlla il dominio. Correggi eventuali problemi SPF e DKIM prima di rendere DMARC restrittivo. Consulta la guida Email Deliverability in cPanel.

Ricorda che un dominio deve avere un solo record SPF. Se usi più piattaforme, combina correttamente le sorgenti nel medesimo record. Per DKIM, ogni piattaforma può usare un selettore differente.

Struttura di un record DMARC

DMARC viene pubblicato come record TXT sul nome:

_dmarc.example.com

Un record iniziale può essere:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

I tag ruf e i report forensi non sono supportati uniformemente e possono contenere dati sensibili. Per una configurazione iniziale è spesso sufficiente usare i report aggregati rua.

Fase 1: pubblica p=none

La policy p=none richiede ai destinatari di monitorare senza applicare una quarantena o un rifiuto basati sulla policy DMARC. È il punto di partenza consigliato per raccogliere dati.

Esempio:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Sostituisci dominio e indirizzo. La casella dei report può ricevere molti file XML compressi; per domini con volumi significativi è preferibile un servizio di analisi. Non utilizzare una casella personale non presidiata.

Come leggere i report aggregati

I report mostrano generalmente:

• organizzazione che ha inviato il report;
• intervallo temporale;
• indirizzi IP osservati;
• numero di messaggi;
• risultati SPF, DKIM e DMARC;
• domini e selettori utilizzati;
• azione applicata.

Un IP sconosciuto non è automaticamente malevolo: può appartenere a una piattaforma legittima, a un relay o a un servizio cloud. Confrontalo con l’inventario delle sorgenti e con la documentazione del fornitore.

Allineamento rilassato e rigoroso

Con l’allineamento rilassato, dominio organizzativo e sottodominio possono essere considerati coerenti. Con l’allineamento rigoroso devono corrispondere esattamente. In una prima configurazione, adkim=r e aspf=r riducono il rischio di bloccare servizi legittimi che utilizzano sottodomini.

Passare a modalità rigorosa ha senso solamente dopo aver verificato le sorgenti e la necessità operativa.

Fase 2: correggi le sorgenti che falliscono

Per ogni sorgente legittima che non supera DMARC:

1. verifica che il dominio sia autorizzato nel record SPF corretto;
2. attiva DKIM con il dominio aziendale quando il servizio lo consente;
3. configura un Return-Path personalizzato se richiesto;
4. usa un From appartenente al dominio configurato;
5. non usare l’indirizzo del visitatore come From nei moduli;
6. ripeti i test e attendi nuovi report.

Per i moduli web, imposta come From una casella del dominio e usa Reply-To per l’indirizzo del visitatore. Questo evita molti problemi di allineamento e spoofing.

Fase 3: passa gradualmente a quarantine

Quando i report mostrano che le sorgenti legittime sono allineate, puoi valutare una policy di quarantena su una parte dei messaggi:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

La percentuale permette un passaggio graduale, ma il comportamento preciso può dipendere dal destinatario. Aumenta progressivamente e continua a monitorare:

• 10%;
• 25%;
• 50%;
• 100%.

Non cambiare più parametri contemporaneamente. Mantieni ogni fase abbastanza a lungo da coprire invii mensili, fatture, newsletter e attività poco frequenti.

Fase 4: valuta reject

La policy p=reject chiede ai destinatari di rifiutare i messaggi che falliscono DMARC. Offre la protezione più forte contro l’uso non autorizzato del dominio, ma deve essere attivata quando tutte le sorgenti legittime sono note e conformi.

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Prima del passaggio verifica anche sottodomini, sistemi di emergenza, scanner, stampanti, vecchi gestionali e servizi che inviano raramente.

Inoltri e mailing list

L’inoltro può cambiare il server che trasmette il messaggio e causare il fallimento SPF. DKIM può continuare a funzionare se il contenuto firmato non viene modificato. Mailing list e gateway che riscrivono oggetto o corpo possono compromettere DKIM.

Questi casi non si risolvono aggiungendo indiscriminatamente server di terzi al proprio SPF. Analizza i report e valuta DKIM, ARC e il comportamento del servizio coinvolto.

Sottodomini e servizi separati

Può essere utile inviare newsletter o email transazionali da sottodomini dedicati, per esempio news.example.com o mail.example.com. In questo modo autenticazione e reputazione possono essere gestite in modo più ordinato.

Controlla il tag sp e pubblica record specifici quando necessario. I sottodomini possono avere SPF, DKIM e DMARC propri.

Errori che possono bloccare la posta

• attivare reject senza monitoraggio;
• dimenticare una piattaforma di newsletter;
• pubblicare due record DMARC sullo stesso nome;
• usare un indirizzo rua inesistente;
• confondere il dominio From con il Return-Path;
• usare allineamento rigoroso senza test;
• cambiare SPF, DKIM e DMARC nello stesso momento;
• ignorare sistemi che inviano solo una volta al mese;
• copiare un record generico senza sostituire dominio e indirizzo.

Come verificare un messaggio

Invia una mail a un destinatario di prova e controlla le intestazioni complete. Cerca risultati come spf=pass, dkim=pass e dmarc=pass, verificando i domini associati. Un semplice “pass” non basta se il dominio non è allineato con il From.

Per seguire il percorso dal server Xlogic consulta Track Delivery in cPanel.

Quando aprire un ticket Xlogic

Apri un ticket se non sai quali record pubblicare per la posta ospitata su Xlogic, se Email Deliverability mostra errori o se un messaggio viene rifiutato dopo una modifica. Indica dominio, record attuale, piattaforme di invio, data e ora, mittente, destinatario e codice SMTP.

L’assistenza non può conoscere automaticamente tutte le piattaforme esterne autorizzate dalla tua organizzazione: allega l’elenco completo. Non inviare password, codici 2FA o chiavi private.

Fonti tecniche ufficiali

• cPanel: Email Deliverability
• Microsoft: Set up DMARC
• Microsoft: SPF, DKIM and DMARC
• Google: Email sender guidelines

Domande frequenti su DMARC