Politica DMARC: scegliere none, quarantine o reject

Una politica DMARC indica al destinatario il trattamento richiesto per i messaggi che usano il tuo dominio e non superano DMARC. Può aiutare contro la falsificazione, ma il destinatario mantiene le proprie regole locali. Un'applicazione prematura può anche colpire fatture, risposte del supporto o inoltri legittimi. Per la configurazione completa, inizia dalla posta aziendale.

Il problema è spesso un inventario incompleto: lasciare p=none senza analizzare i rapporti o passare a p=reject prima di verificare autenticazione e allineamento di ogni servizio. Questo può mettere a rischio messaggi validi.

Un percorso comune usa p=none per osservare i mittenti, valuta p=quarantine dopo aver corretto l'autenticazione allineata e considera p=reject dopo aver indagato gli errori residui. Non tutti gli errori sono falsificazioni e non esiste un calendario sicuro per ogni dominio.

Cos'è una politica DMARC?

La politica richiede un'azione quando un messaggio che usa il tuo dominio fallisce DMARC. Le opzioni sono none, quarantine e reject. La scelta dipende soprattutto dall'autenticazione valida e allineata dei mittenti legittimi.

Il destinatario verifica SPF, DKIM e l'allineamento dei loro domini con il From visibile. Per superare DMARC, almeno uno deve superare l'autenticazione ed essere allineato.

Se SPF passa ed è allineato, DMARC passa.

Se DKIM passa ed è allineato, DMARC passa.

Se nessuno fornisce autenticazione valida e allineata, viene valutata la politica richiesta.

Quale politica DMARC scegliere all'inizio?

Inizia con p=none se non hai verificato l'autenticazione allineata di tutti i mittenti. Il traffico reale aiuta a valutare i rischi prima di richiedere misure più restrittive.

Un record iniziale di monitoraggio è:

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

Questa modalità non richiede blocchi contro la falsificazione e non garantisce il recapito. Può offrire visibilità quando i destinatari partecipanti inviano rapporti, senza necessariamente coprire tutto il traffico.

Mittenti spesso dimenticati:

1. Software contabili che inviano fatture.
2. Strumenti per risorse umane e selezione.
3. Piattaforme CRM e marketing.
4. Sistemi di supporto che rispondono con il dominio principale.
5. Regole personali di inoltro che influenzano SPF al passaggio successivo.

Senza osservare questi flussi, una politica restrittiva può colpire processi reali. Pubblicare un TXT non significa avere identificato tutti i mittenti.

Per i mittenti di grandi volumi, pubblicare DMARC fa parte dei requisiti di alcuni destinatari, come Google. Verifica le condizioni applicabili di autenticazione e allineamento. Lo standard è descritto nella RFC 7489.

Quanto tempo mantenere none?

Mantenere none per due o quattro settimane può servire come riferimento iniziale, senza garantire l'osservazione dei flussi mensili, trimestrali o eccezionali. Adatta il monitoraggio ai tuoi cicli effettivi di invio.

Tre giorni spesso danno poche informazioni: fatture mensili, comunicazioni trimestrali e vecchie applicazioni di recupero password possono restare fuori dal campione.

L'osservazione dovrebbe coprire:

1. Posta aziendale abituale.
2. Campagne marketing.
3. Cicli di fatturazione.
4. Escalation del supporto.
5. Messaggi inoltrati.
6. Automazioni di terzi.

Confronta i rapporti aggregati con l'inventario: sistemi legittimi da correggere, falsificazioni probabili ed errori ancora inspiegati. I rapporti non permettono sempre di stabilire da soli la causa.

Esempio: la piattaforma di newsletter firma con il proprio dominio e SPF passa anch'esso per un dominio non allineato. DMARC fallisce nonostante l'autenticazione valida. Prima di richiedere il rifiuto, correggi l'allineamento del mittente legittimo.

In TrekMail, il percorso DNS può aiutare a verificare i record indicati secondo la modalità di invio. Consulta aggiungere un dominio e i record DNS richiesti. Questi controlli non sostituiscono l'inventario dei servizi esterni.

Perché l'inoltro complica DMARC?

L'inoltro può far fallire SPF perché cambia il server di invio. DKIM valido e allineato spesso permette a DMARC di passare se i dati firmati vengono preservati. Verifica DKIM senza presumere che ogni inoltro lo conservi.

La distinzione tra identità del mittente è essenziale.

L'utente vede From; il server usa un mittente della busta per i mancati recapiti. SPF verifica questa identità e l'IP di invio. DMARC controlla se un risultato SPF valido è allineato al From visibile.

Con l'inoltro, l'IP cambia e potrebbe non essere autorizzato dal SPF originale. DKIM può restare valido se i dati firmati non cambiano oltre quanto tollerato dalla canonicalizzazione.

Questi risultati possono quindi coesistere:

1. SPF fallisce dopo l'inoltro.
2. DMARC passa perché DKIM passa ed è allineato.

Prima di richiedere misure restrittive, prova gli inoltri importanti per l'attività e le firme allineate dei mittenti. Consulta inoltrare la posta del dominio a Gmail e, per problemi di percorso, l'inoltro della posta.

ARC trasporta il contesto di autenticazione tra intermediari e liste, senza sostituire il tuo allineamento né garantire l'accettazione del destinatario. Il protocollo è descritto nella RFC 8617.

Quando passare a quarantine?

Valuta quarantine dopo aver verificato che i mittenti legittimi passino SPF o DKIM con allineamento. La politica richiede di trattare gli errori come sospetti; il destinatario può applicare eccezioni o altre misure.

Il record è:

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

Un mittente dimenticato potrebbe finire nello spam e rivelare il problema, ma non contare sulla conservazione sistematica dei messaggi né sulla segnalazione degli utenti.

Per affrontare un incidente:

1. Ricevi e verifica la segnalazione del messaggio mancante.
2. Esamina il mittente e l'allineamento.
3. Correggi SPF, DKIM o entrambi secondo la causa.
4. Ripeti le prove prima di considerare reject.

Alcuni team usano pct=25 o pct=50 per richiedere applicazione parziale. Non tutti i destinatari rispettano la percentuale allo stesso modo. Anche 100% resta una richiesta, non una garanzia di copertura. Avanza secondo rischi e dati, non soltanto la percentuale.

Nei piani TrekMail che includono SMTP gestito, verifica firme valide e allineate al tuo dominio. Negli inoltri, SPF può fallire e DKIM passare; consulta i miei messaggi finiscono nello spam per la diagnosi.

Quando passare a reject?

Valuta reject dopo aver risolto gli errori legittimi e indagato le cause sconosciute. La politica richiede il rifiuto dei messaggi che falliscono DMARC, ma i destinatari possono mantenere eccezioni locali.

Il record è semplice:

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

È un obiettivo comune quando il traffico legittimo del dominio è stato verificato.

Può essere utile perché:

1. Ostacola alcuni usi diretti del dominio per falsificazione quando il destinatario applica la politica.
2. Può ridurre parte dei rischi di phishing e frode aziendale.
3. Comunica ai destinatari il trattamento richiesto per gli errori.
4. Fa parte della protezione del marchio, senza coprire tutti gli inganni.

Google descrive limitazioni e rifiuti legati ad autenticazione e allineamento, con codici come 4.7.31 e 4.7.32. Alcuni mancati recapiti menzionano 5.7.26 e la politica del dominio. Consulta le domande frequenti sulle linee guida Google per i mittenti per il contesto vigente.

Attenzione: se l'amministrazione usa ancora un servizio senza autenticazione allineata, le fatture potrebbero essere rifiutate. Verifica quel flusso prima di irrigidire la politica.

Quale record DMARC pubblicare nel DNS?

Pubblica un solo TXT di politica sotto _dmarc.yourdomain.com. Anche un valore breve può influenzare il trattamento richiesto per la posta del dominio.

Questi esempi sono alternative: non pubblicarli tutti insieme.

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

In TrekMail, esamina MX, SPF, DKIM e DMARC secondo la configurazione reale. Il modello seguente è illustrativo: quarantine non è un consiglio di applicare restrizioni prima dell'inventario dei mittenti.

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

Non pubblicare più SPF e non inventare chiavi DKIM. Esamina gli MX esistenti prima di cambiarli. Con un tuo servizio di invio, SPF e DKIM devono corrispondere a quel servizio, non necessariamente all'esempio. Consulta SMTP proprio (BYO) e verifica l'allineamento.

Quali errori di politica DMARC evitare?

Errori comuni sono p=none senza analisi, applicazione prematura, dipendenza dal solo SPF e dimenticanza dei sottodomini. Possono lasciare protezione incompleta o colpire messaggi legittimi.

Controlla questi punti:

1. Mantenere none per mesi senza un piano di revisione: non richiede blocchi e i rapporti dipendono dai partecipanti.
2. Ignorare l'allineamento DKIM perché SPF passa: l'inoltro può esporre questa dipendenza.
3. Dimenticare l'ereditarietà dei sottodomini: usa sp= per una politica diversa.
4. Superare il limite SPF di 10 termini valutati che provocano ricerche DNS può produrre PermError; non è il semplice conteggio delle richieste di rete.
5. Fidarsi di un servizio che usa il dominio senza verificare come autentica e firma.

Un esempio per i sottodomini:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

Richiede reject per il dominio principale e none per i sottodomini che ereditano la politica. Non riguarda un solo sottodominio; record specifici possono modificare il comportamento.

Come TrekMail aiuta a configurare DMARC

TrekMail può coordinare domini, archiviazione e controlli DNS secondo il piano. Riduce il lavoro tra strumenti, ma la politica richiede comunque di conoscere i mittenti esterni e i loro risultati reali.

A titolo indicativo, Starter è pubblicizzato da $3.50 al mese con SMTP gestito secondo le sue condizioni. Nano viene offerto gratuitamente con SMTP proprio. TrekMail usa IMAP e offre domini personalizzati, catch-all, inoltro, migrazione e API secondo piano e configurazione: verifica le condizioni vigenti.

Per DMARC non basta pubblicare il TXT: occorre controllare e verificare i sistemi che inviano con il tuo dominio.

Secondo la configurazione disponibile, puoi:

1. Gestire più domini da un pannello.
2. Verificare i record DNS prima dell'attivazione.
3. Usare SMTP gestito nei piani corrispondenti o configurare SES/SendGrid su Nano.
4. Separare hosting delle caselle e scelta del servizio di uscita.
5. Importare la posta precedente con una migrazione IMAP compatibile.

Per l'installazione completa, consulta configurare la posta sul mio dominio. Per più marchi o clienti, l'hosting di posta multidominio descrive il modello operativo.

Conclusione: avanzare da none a reject con dati reali

Un percorso comune parte da none, corregge autenticazione e allineamento, valuta quarantine e poi reject. Ogni passaggio deve basarsi su prove e osservazione.

In sintesi:

1. Usa p=none per un periodo da 2 a 4 settimane come riferimento iniziale, estendendo il periodo per coprire i tuoi cicli.
2. Configura SPF o DKIM validi e allineati per ogni mittente legittimo; verifica DKIM per gli inoltri.
3. Valuta p=quarantine per richiedere un trattamento intermedio.
4. Valuta p=reject dopo aver risolto gli errori legittimi e indagato gli altri.

Questa procedura può ridurre la falsificazione mantenendo attenzione alla posta valida, senza garantire recapito o protezione totale. Per coordinare caselle, inoltri e migrazioni secondo le tue esigenze, consulta i documenti TrekMail o confronta i piani su https://trekmail.net/pricing.