Come configurare DMARC senza interrompere le email legittime

Se cerchi come configurare DMARC, il consiglio iniziale è questo: non passare subito a p=reject. Inizia con una politica di monitoraggio, verifica che ogni mittente autorizzato superi SPF o DKIM con l’allineamento richiesto e aumenta le restrizioni per gradi. Questo approccio può ridurre la falsificazione senza mettere inutilmente a rischio fatture, reimpostazioni delle password o messaggi di uno strumento SaaS dimenticato.

Molte guide descrivono una situazione più semplice della realtà. Un dominio invia da Microsoft 365, la fatturazione usa un’applicazione esterna, il marketing lavora su un’altra piattaforma e la fotocopiatrice del magazzino invia ancora scansioni. Dimenticare un mittente può trasformare una misura di sicurezza in un’interruzione. Per configurare anche la posta del dominio, consulta come configurare le email sul proprio dominio e la guida più ampia alla posta aziendale.

Questa guida affronta DMARC dal punto di vista operativo: osservare, raccogliere riscontri, correggere l’allineamento e poi applicare restrizioni. Il processo richiede attenzione ai rischi reali, non una ricetta automatica.

Che cosa fa davvero DMARC

DMARC pubblica nel DNS una politica che indica ai server destinatari il trattamento richiesto per i messaggi che usano il tuo dominio nel mittente visibile ma non superano l’autenticazione con allineamento. Si basa su SPF e DKIM. DMARC passa quando almeno uno dei due supera la verifica ed è allineato al dominio visibile di From.

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. Consente di pubblicare una politica per i messaggi che non superano DMARC e di richiedere report sull’utilizzo del dominio come mittente. La specifica di base è RFC 7489. Un’autenticazione riuscita non garantisce che il contenuto sia sicuro.

Per capire come configurare DMARC, parti da questa regola:

• SPF può passare senza che DMARC passi se il dominio autenticato non è allineato a From e DKIM non fornisce un risultato valido e allineato.
• DKIM può passare senza che DMARC passi per lo stesso motivo, se SPF non fornisce il risultato valido e allineato mancante.
• DMARC passa se SPF o DKIM supera la verifica con l’allineamento richiesto. Ne basta uno.

Le indicazioni di Google citate richiedono ai mittenti di grandi volumi SPF, DKIM e un record DMARC con politica minima p=none. Per superare DMARC, SPF o DKIM deve passare con l’allineamento a From. Verifica i requisiti attuali e il loro ambito nelle domande frequenti sulle linee guida di invio di Google.

Le verifiche preliminari a DMARC

Prima di pubblicare una politica DMARC, controlla la configurazione di invio. SPF errato, DKIM assente o firme con un altro dominio possono causare errori DMARC. Individuarli è utile; applicare restrizioni prima di risolverli può interrompere la posta legittima.

Inizia con tre verifiche.

1. SPF: pubblica un solo record SPF valido per ogni dominio realmente usato nel mittente della busta. Rispetta il limite di 10 meccanismi o modificatori che comportano ricerche DNS, incluse le valutazioni annidate; non è un limite al totale delle query DNS.
2. DKIM: attivalo sulle piattaforme di invio compatibili. Usa chiavi da 2048 bit quando il fornitore e la configurazione lo consentono.
3. Inventario: elenca tutti i servizi che inviano con il tuo dominio: posta, CRM, fatturazione, assistenza, moduli, scanner e strumenti di marketing.

Per i domini TrekMail, consulta i record DNS necessari e l’aggiunta di un dominio. I controlli disponibili possono individuare record pubblicati ed errori comuni, come SPF duplicati, senza sostituire la verifica di messaggi reali e risposte DNS esterne.

Esempio: l’applicazione di fatturazione invia da billing@yourdomain.com, ma firma con il dominio del fornitore e usa il suo return-path. SPF e DKIM passano per quei domini, ma nessuno è allineato al tuo. DMARC fallisce per il tuo dominio.

Questo disallineamento spiega molte interruzioni dopo l’attivazione di restrizioni DMARC.

Passo 1: pubblicare una politica DMARC di monitoraggio

Per una distribuzione graduale, spesso conviene iniziare osservando. Una politica p=none richiede report senza chiedere quarantena o rifiuto in base a DMARC. I report non sono garantiti e i destinatari possono continuare ad applicare i propri filtri locali.

Crea un record TXT su _dmarc.yourdomain.com con questo valore:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Lo stesso record nel formato di un file di zona, non un record aggiuntivo:

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

L’esempio segue il formato di RFC 7489. Usa un indirizzo o alias dedicato e monitorato, con controlli adeguati di accesso e trattamento dei dati. I report aggregati sono file XML e possono accumularsi rapidamente. Una destinazione esterna può richiedere un’autorizzazione DNS nel dominio che riceve i report.

Dopo la pubblicazione, verifica le risposte DNS e l’autenticazione dei messaggi inviati da ogni servizio. Le domande frequenti sulle email che finiscono nello spam aiutano anche a distinguere gli effetti dell’inoltro da altri problemi.

Passo 2: leggere i report e identificare i mittenti

Questo passaggio viene spesso trascurato. I report contengono dati dei destinatari partecipanti, non un inventario completo di tutti i messaggi. Aiutano a esaminare servizi autorizzati, configurazioni errate e possibili falsificazioni, ma non classificano da soli il traffico come legittimo o abusivo.

I report DMARC mostrano generalmente:

• Gli IP di origine che hanno inviato messaggi con il tuo dominio
• I risultati SPF
• I risultati DKIM
• L’allineamento dei risultati al dominio di From
• Il trattamento applicato dal destinatario

Distingui due gruppi da esaminare.

Prima, i mittenti autorizzati che non superano l’allineamento e richiedono correzioni. Poi, le fonti ancora sconosciute. Un IP sconosciuto può appartenere a un servizio di inoltro o a un’infrastruttura condivisa: da solo non dimostra una falsificazione.

Questi casi sono illustrativi; i risultati dipendono dalla configurazione e dal messaggio:

Con molti domini, ogni nuovo strumento SaaS richiede una verifica dell’invio. Per questo alcune agenzie valutano l’hosting email multidominio e una gestione più ordinata delle caselle. Cambiare piattaforma non elimina questi compiti.

Passo 3: correggere l’allineamento, non solo l’autenticazione

DMARC richiede un risultato valido e allineato. SPF o DKIM può passare con un altro dominio senza contribuire a DMARC, ma basta che l’altro meccanismo passi con allineamento. In modalità rilassata, il dominio autenticato deve condividere il dominio organizzativo con From; non basta una qualsiasi relazione tra dominio padre e figlio.

RFC 7489 definisce l’allineamento rilassato tramite lo stesso dominio organizzativo fra il dominio autenticato con SPF o firmatario DKIM e il dominio di RFC5322.From. Le domande frequenti di Google indicano che un meccanismo valido e allineato basta per DMARC, anche se i mittenti di grandi volumi devono configurare entrambi i metodi.

Ecco le correzioni abituali:

• Piattaforme di marketing: configura la firma DKIM con il tuo dominio.
• Gestione dei mancati recapiti: configura un return-path o dominio di bounce personalizzato se il fornitore lo permette e verifica l’allineamento.
• Microsoft 365: attiva DKIM per il dominio personalizzato prima delle restrizioni, se scegli questo meccanismo per l’allineamento.
• Invio gestito di TrekMail: pubblica esattamente i record SPF e DKIM indicati per il servizio in uscita realmente utilizzato.

La configurazione deve corrispondere al servizio di invio effettivo. Anche le offerte fatturate per utente possono fornire strumenti DNS. TrekMail propone di separare le caselle dal motore di invio, con SMTP gestito nei piani a pagamento che lo includono o SMTP proprio su Nano secondo le condizioni del piano. Configura e verifica il fornitore SMTP scelto.

Nell’offerta descritta, Nano usa il tuo fornitore SMTP e i piani a pagamento includono SMTP gestito. TrekMail presenta prezzi a partire da $3.50 al mese, una prova di 14 giorni sui piani a pagamento soggetta alle relative condizioni e Nano senza costi né carta secondo l’offerta applicabile. Verifica i requisiti della prova e le funzionalità attuali nella pagina dei prezzi di TrekMail.

Passo 4: valutare una politica di quarantena

Quando i mittenti autorizzati passano con allineamento e hai validato i flussi rilevanti, puoi valutare la quarantena. È già una politica restrittiva: richiede un trattamento speciale per i messaggi che non superano DMARC. Il destinatario decide come applicarla; non garantisce una specifica cartella spam, il recupero del messaggio o l’adeguatezza a ogni dominio.

Sostituisci la politica precedente con questa, senza pubblicarle entrambe:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Perché valutare la quarantena prima del rifiuto?

• Può ridurre l’esposizione ad alcuni tentativi di falsificazione.
• Può consentire di esaminare errori con un trattamento meno restrittivo, senza garantire il recupero dei messaggi.
• Permette di provare una fase restrittiva, con valutazione del rischio e controllo dei flussi critici.

Quanto tempo osservare? Dipende dai flussi. Qualche settimana può essere un riferimento iniziale per domini piccoli; 30 giorni per domini con molti fornitori restano comunque un riferimento, non una prova di preparazione.

Controlla anche i sistemi usati raramente: un plugin WordPress, un ambiente di test del CRM, una vecchia fotocopiatrice o un fornitore che invia ogni mese. I processi trimestrali o eccezionali possono richiedere più tempo e test specifici. La quarantena non offre un margine di sicurezza garantito.

Passo 5: passare al rifiuto dopo aver validato i flussi

La politica p=reject chiede al destinatario di rifiutare i messaggi che non superano DMARC, anziché limitarsi a trattarli come sospetti. Può ridurre la falsificazione diretta del dominio, senza bloccare tutte le forme di frode.

La politica di questa fase ha generalmente questo aspetto:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Secondo RFC 7489, p=reject richiede il rifiuto dei messaggi che non superano DMARC. I destinatari possono applicare eccezioni e politiche locali: non garantisce il blocco universale né il recapito delle email legittime nella posta in arrivo.

Prima di procedere, verifica questi punti:

• Il fornitore principale supera SPF o DKIM con allineamento
• Gli strumenti di marketing e transazionali superano anch’essi un meccanismo allineato
• Hai esaminato diverse settimane di report e provato i flussi critici poco frequenti
• Comprendi gli errori restanti e le loro conseguenze

Continua poi a esaminare i report disponibili e a verificare le modifiche. DMARC fa parte della gestione continua della posta.

Errori comuni che interrompono le email

Oltre alle politiche, devi conoscere i mittenti. Un servizio dimenticato, SPF duplicati, DKIM disattivato o l’autenticazione predefinita di un fornitore possono causare errori quando si applicano restrizioni. La politica di monitoraggio non crea da sola questi errori.

• Applicare restrizioni prima di avere SPF o DKIM valido e allineato
• Pubblicare più record SPF invece di riunire le autorizzazioni in un solo record valido
• Presumere che SPF valido significhi DMARC valido
• Dimenticare fornitori con pochi invii ma messaggi potenzialmente critici
• Passare direttamente dall’assenza di DMARC a p=reject
• Inviare i report a una casella che nessuno controlla

Con alias e inoltri, SPF può fallire mentre DKIM permette ancora a DMARC di passare, purché la firma resti valida e allineata e i dati firmati siano preservati dopo la canonicalizzazione. Non ignorare automaticamente questi errori. Consulta l’inoltro con alias email e la posta sicura per le aziende per ampliare la verifica operativa.

Una lista pratica per configurare DMARC

Questa lista riassume una distribuzione graduale. Aiuta a organizzare le verifiche, senza garantire una transizione priva di incidenti.

1. Esamina tutti i sistemi che inviano con il tuo dominio.
2. Pubblica un solo SPF valido per ogni dominio di busta interessato.
3. Attiva e verifica DKIM su ogni piattaforma di invio compatibile.
4. Pubblica v=DMARC1; p=none; rua=mailto:....
5. Esamina i report confrontandoli con l’inventario dei mittenti.
6. Verifica un meccanismo valido e allineato per ogni mittente autorizzato.
7. Valuta p=quarantine dopo aver provato i flussi.
8. Controlla di nuovo i report e il funzionamento effettivo.
9. Passa a p=reject quando i test e la valutazione del rischio lo giustificano.

Conclusione: configurare DMARC con una distribuzione controllata

Una sequenza comune parte da p=none, confronta i report con l’inventario, corregge autenticazione e allineamento e poi valuta p=quarantine e p=reject. Può ridurre i rischi nell’applicazione delle restrizioni contro la falsificazione, ma richiede test e monitoraggio.

Con un dominio, il coordinamento può essere gestibile; con decine o centinaia servono processi più ordinati. Secondo il piano e l’offerta attuale, TrekMail offre domini personalizzati, caselle IMAP, catch-all, inoltro, strumenti di migrazione e SMTP proprio o incluso. La copia IMAP non sostituisce il cambio dei record MX e non migra automaticamente tutte le applicazioni. Verifica limiti e prezzi: questi strumenti non sostituiscono la configurazione DMARC e non garantiscono risparmi rispetto alla fatturazione per utente.

Questo è l’approccio operativo per configurare DMARC: osservare, verificare i mittenti e poi applicare restrizioni. Basa le decisioni sui report disponibili e su test reali, non su supposizioni.