Per configurare DMARC senza bloccare email legittime bisogna procedere gradualmente: prima verificare tutte le sorgenti di invio e l’allineamento SPF/DKIM, poi pubblicare una policy p=none, analizzare i report e solo successivamente valutare quarantine o reject.
Indice dei contenuti
DMARC
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:
- quale dominio usa nel From;
- quale dominio usa nell’envelope sender o Return-Path;
- quale dominio firma con DKIM;
- se SPF passa;
- se DKIM passa;
- 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.comUn record iniziale può essere:
v=DMARC1; p=none; rua=mailto:dmarc@example.com| Tag | Funzione | Nota |
|---|---|---|
| v | Versione | Deve essere DMARC1 |
| p | Policy del dominio | none, quarantine o reject |
| rua | Report aggregati | Casella o servizio di analisi |
| adkim | Allineamento DKIM | r rilassato, s rigoroso |
| aspf | Allineamento SPF | r rilassato, s rigoroso |
| sp | Policy sottodomini | Valuta i servizi che usano sottodomini |
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=rSostituisci 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:
- verifica che il dominio sia autorizzato nel record SPF corretto;
- attiva DKIM con il dominio aziendale quando il servizio lo consente;
- configura un Return-Path personalizzato se richiesto;
- usa un From appartenente al dominio configurato;
- non usare l’indirizzo del visitatore come From nei moduli;
- 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: valuta il passaggio a quarantine
Prima del passaggio, verifica nei report e con invii di prova tutte le sorgenti legittime, comprese quelle usate di rado. Con p=quarantine chiedi ai destinatari di trattare come sospetti i messaggi che falliscono DMARC: una sorgente dimenticata potrebbe quindi finire nello spam.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comSostituisci l’indirizzo con quello predisposto per i report. Non affidarti a pct=10 per limitare la quarantena al 10%: RFC 9989 ha rimosso il tag pct, il cui comportamento era già poco uniforme. Il nuovo tag di test t non è una percentuale e non va sostituito automaticamente a pct.
- Mantieni
p=nonefinché restano sorgenti legittime non verificate. - Prepara il ripristino della policy precedente e modifica un parametro alla volta.
- Dopo il passaggio, controlla report, messaggi di mancata consegna e segnalazioni dei destinatari.
- Se emerge un problema, correggi la sorgente e valuta il ritorno temporaneo alla policy precedente, tenendo conto delle cache DNS.
La policy esprime una richiesta: ogni destinatario conserva le proprie decisioni di filtro. Anche un messaggio che supera DMARC può essere classificato come spam.
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.comPrima 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.
Domande frequenti
Come verificare SPF e DKIM prima di applicare DMARC?
Apri Email Deliverability in cPanel e controlla che SPF e DKIM risultino coerenti con i servizi che inviano posta per il dominio. Correggi prima questi problemi e solo dopo passa a una policy DMARC più restrittiva.
A cosa servono i report aggregati DMARC?
I report aggregati mostrano quali sorgenti inviano usando il dominio e come risultano SPF, DKIM e allineamento. Servono per individuare servizi legittimi non ancora configurati e invii sospetti prima di applicare una policy più severa.
Guide Xlogic correlate
- DMARC p=none, quarantine e reject: differenze
- Email Deliverability in cPanel: controllare SPF, DKIM e DMARC
- DMARC fail per mancato allineamento
Fonti tecniche
- Microsoft: Set up DMARC
- Microsoft: SPF, DKIM and DMARC
- Google: Email sender guidelines
- RFC Editor — DMARC, RFC 9989, appendice A.6