DMARC senza blackout: il rifiuto va attivato solo dopo i report

Per configurare DMARC senza rischiare di bloccare la posta aziendale, verifica SPF e DKIM, pubblica un record DNS TXT con p=none e raccogli i report prima di passare a quarantine e reject. La procedura Google per DMARC raccomanda di iniziare con p=none e di irrigidire la policy dopo aver osservato come i destinatari autenticano i messaggi.

Il controllo decisivo è l’allineamento: almeno uno tra SPF e DKIM deve riuscire usando un dominio coerente con quello visibile nel campo From. Un servizio può superare entrambi i controlli con il proprio dominio e fallire comunque DMARC quando invia mostrando il dominio della tua impresa. Con p=none non chiedi al destinatario di penalizzare il messaggio per quel fallimento DMARC; gli altri filtri della posta restano attivi.

Verificare SPF, DKIM e il dominio nel From

Parti dagli indirizzi che l’azienda usa nel campo From e identifica tutti i sistemi che li impiegano. La posta dei dipendenti, le campagne, il CRM e le notifiche del sito possono uscire da infrastrutture diverse. Per SPF conta il dominio del mittente della busta SMTP, visibile nelle intestazioni come smtp.mailfrom; per DKIM conta il dominio della firma, indicato da d=.

Confronta ciascuno di questi domini con quello nel From e controlla anche che la rispettiva autenticazione riesca: per superare DMARC basta un percorso riuscito e allineato. Vale comunque la pena verificare entrambi, perché un inoltro può compromettere SPF e una modifica al contenuto può invalidare DKIM. Se un fornitore usa soltanto il proprio dominio, chiedi se consente un MAIL FROM personalizzato o una firma DKIM con il tuo dominio.

Lascia inizialmente l’allineamento rilassato previsto dalle impostazioni predefinite: ammette i sottodomini dello stesso dominio organizzativo. L’allineamento rigido richiede invece una corrispondenza esatta e può far fallire invii legittimi da sottodomini. Valutalo solo conoscendo i domini effettivamente usati da ciascun servizio.

Censire tutti i mittenti autorizzati

L’inventario deve collegare ogni flusso a un risultato di autenticazione, non limitarsi ai nomi dei fornitori. Per ciascun servizio registra il dominio nel From, quello di MAIL FROM o Return-Path, il dominio DKIM d=, il responsabile della configurazione e la frequenza dell’invio. Includi i flussi occasionali: una campagna stagionale potrebbe non comparire nei primi report.

• Newsletter: registra separatamente il dominio delle campagne, quello usato per i messaggi di ritorno e l’eventuale firma DKIM personalizzata.
• CRM e assistenza: distingui le email automatiche da quelle inviate dagli operatori, se seguono percorsi diversi.
• Sito ed e-commerce: includi conferme d’ordine, reimpostazioni di password e notifiche prodotte da moduli o plugin.
• Servizi amministrativi: individua chi invia fatture o altre comunicazioni mostrando il dominio aziendale nel From.

Segna a parte gli invii che usano un sottodominio. Se questo non ha un record DMARC proprio, eredita la policy del dominio principale: irrigidire quest’ultima può coinvolgere un flusso trascurato nell’inventario. Un record dedicato permette di gestire il sottodominio con una policy distinta.

Pubblicare p=none e verificare il DNS

Nel DNS crea un record TXT con nome _dmarc seguito dal dominio. Per il dominio fittizio example.com, un valore iniziale è v=DMARC1; p=none; rua=mailto:[email protected]. Sostituisci example.com con il tuo dominio e prepara una casella per i report aggregati: v identifica il record, p indica la policy richiesta e rua specifica dove inviare i report.

Controlla come il tuo gestore DNS interpreta il nome del record: alcuni aggiungono automaticamente il dominio a _dmarc. Dopo il salvataggio, interroga il DNS pubblico per accertarti che il TXT sia pubblicato all’indirizzo previsto e abbia il valore corretto. Se l’indirizzo rua appartiene a un dominio diverso da quello protetto, anche il dominio che riceve i report deve pubblicare il record DNS che ne autorizza l’invio.

Conserva l’inventario accanto ai report ricevuti. La sola presenza del record non dimostra che newsletter, CRM e notifiche superino DMARC presso i destinatari: il periodo di osservazione deve comprendere anche gli invii meno frequenti che l’azienda vuole mantenere.

Usare i report per correggere i fallimenti

La documentazione Microsoft sui report aggregati descrive risultati raggruppati per sorgente, con indirizzi IP, esiti di autenticazione e azioni applicate; per diagnosticare un singolo messaggio servono anche le sue intestazioni. Confronta le sorgenti con l’inventario prima di attribuire un fallimento a un servizio: un IP sconosciuto richiede un’indagine, ma non identifica da solo un tentativo di abuso.

Per un messaggio legittimo fallito, apri le intestazioni Authentication-Results di una copia ricevuta. Confronta header.from con smtp.mailfrom per SPF e con header.d per DKIM, verificando in ciascun caso anche l’esito dell’autenticazione. Se SPF e DKIM risultano riusciti ma usano entrambi soltanto il dominio del fornitore, il messaggio fallisce DMARC per il dominio aziendale nel From.

Correggi almeno un percorso con il fornitore e ripeti una prova di invio. Considera gli intermediari quando interpreti il risultato: un inoltro può alterare il percorso valutato da SPF, mentre una modifica al messaggio può compromettere DKIM. Annota il servizio e il tipo di invio coinvolti, così la correzione resta verificabile anche quando più flussi condividono la stessa infrastruttura.

Passare a quarantine e poi a reject

Passa a p=quarantine quando i report coprono i flussi censiti, compresi quelli meno frequenti, e hai risolto i fallimenti dei mittenti autorizzati. Per un esempio puramente illustrativo, il record può diventare v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]. Il tag pct limita la quota dei messaggi che falliscono DMARC ai quali si chiede di applicare la policy; aumentala osservando gli effetti sugli invii legittimi.

Dopo aver verificato quarantine, passa a p=reject e continua a monitorare i report. Reject chiede ai destinatari di respingere i messaggi che falliscono DMARC, anche se l’azione concreta dipende dal sistema ricevente. Prima che un nuovo servizio inizi a spedire con il dominio aziendale, aggiungilo all’inventario e verifica l’allineamento dei suoi messaggi.

Se il tasso di autenticazione cala, controlla il DNS prima di irrigidire ancora la policy: le indicazioni Google per Postmaster Tools segnalano che un record TXT DMARC malformato o un errore DNS temporaneo possono contribuire al problema. Verifica il record pubblicato e le intestazioni dei messaggi di prova, poi confronta i nuovi risultati con quelli dei report precedenti.

Leggi anche:

• Ruotare una chiave API senza blackout: la vecchia va eliminata per ultima
• YouTube e tasse USA: senza modulo la ritenuta può arrivare al 24%
• Matomo senza cookie: una riga di codice non elimina ogni obbligo