Una politica DMARC reject richiede il rifiuto dei messaggi che falliscono DMARC. Con p=none, richiedi rapporti senza restrizioni, ma il loro invio non è garantito; quarantine richiede già una misura di applicazione. Passare troppo presto a p=reject può colpire fatture, recupero password e supporto legittimi. Per le basi, inizia dalla posta aziendale.
Monitorare senza inventariare i mittenti lascia problemi irrisolti; irrigidire una politica DMARC reject senza prove crea altri rischi. Questa guida riunisce requisiti, transizione indicativa ed errori rilevanti nel 2025 e 2026.
| Requisito | Obiettivo | Perché verificarlo prima di reject |
|---|---|---|
| Osservazione del traffico | 30 giorni come riferimento iniziale | Esaminare i cicli mensili ed estendere per quelli rari o trimestrali |
| Audit di allineamento | 100% dei mittenti legittimi allineati come obiettivo | SPF o DKIM valido senza allineamento non basta a DMARC |
| Reputazione | Tasso di spam inferiore a 0.1% secondo le indicazioni del destinatario | Reputazione ed errori DMARC possono coesistere |
| Inoltri | DKIM valido e allineato conservato | SPF può fallire nei percorsi indiretti |
| Sottodomini | Tag sp verificato | L'ereditarietà può colpire sottodomini vecchi o di sviluppo |
Cosa fa realmente DMARC reject
Una politica DMARC reject richiede al destinatario di rifiutare messaggi quando né SPF né DKIM supera la verifica con l'allineamento richiesto per il dominio. Può ridurre alcune falsificazioni quando applicata, senza garantire il blocco di tutte le falsificazioni o il recapito nella posta in entrata.
L'allineamento è essenziale: almeno un'autenticazione valida deve allinearsi al dominio From visibile, secondo la modalità rilassata o rigorosa. Un indicatore SPF o DKIM positivo da solo non basta.
Secondo la RFC 7489, i destinatari possono considerare pct e applicare giudizio locale. Una politica DMARC reject non corregge reputazione, contenuto o configurazione di invio.
Requisito 1: osservare 30 giorni prima di reject
Non basare una politica DMARC reject su una sola settimana favorevole. Trenta giorni sono un riferimento pratico, non una garanzia: fatturazione mensile, rapporti trimestrali e automazioni rare richiedono prove o osservazione prolungata.
Esaminare sette giorni, pubblicare p=reject e scoprire poi fatture rifiutate è un rischio da ridurre con inventario e test di ogni ciclo.
Esempio: la fatturazione invia solo all'inizio del mese. Si autentica con il dominio del fornitore, senza allineamento al tuo. Con
p=none, l'errore può passare inosservato; conp=reject, le fatture potrebbero essere rifiutate.
Cerca mittenti rari ma importanti: fatturazione, risorse umane, scanner, moduli e supporto. Valuta la politica DMARC reject dopo averli identificati, senza usarla come sostituto dell'inventario.
Verifica DNS prima di interpretare i rapporti. La guida ai record DNS richiesti TrekMail descrive SPF, DKIM, MX e DMARC secondo la modalità di servizio.
Requisito 2: verificare allineamento e autenticazione
Prima di una politica DMARC reject, verifica SPF o DKIM validi e allineati per ogni mittente legittimo. Un servizio può autenticarsi correttamente per il proprio dominio senza allinearsi al tuo From.
Un esempio SaaS comune:
From visibile:
support@yourcompany.com
Return-Path:bounce.vendor-mail.com, con SPF valido
DKIM:d=vendor-mail.com, con DKIM valido
Risultato: DMARC fallisce peryourcompany.com
Il pannello del fornitore può mostrare autenticazione valida senza allineamento del dominio. Una politica DMARC reject può colpire questi messaggi.
Correzioni comuni:
- Pubblicare i record DKIM del fornitore e configurare la firma con il tuo dominio.
- Configurare un dominio di ritorno personalizzato per allineare SPF.
- Provare messaggi reali e leggere le intestazioni.
Controlla SPF: il limite riguarda dieci meccanismi o modificatori valutati che provocano ricerche DNS, non tutte le richieste di rete. Più TXT SPF producono un errore permanente. La guida alla configurazione del dominio spiega i record SPF duplicati.
Requisito 3: verificare la reputazione
Una politica DMARC reject può limitare parte della falsificazione, senza migliorare da sola la reputazione. Messaggi autentici possono ricevere segnalazioni, filtri o rifiuti per altre ragioni.
Le indicazioni Google citate raccomandano ai mittenti di grandi volumi spam inferiore a 0.1% e di evitare 0.3% o più, che può influire sulle misure di mitigazione. Yahoo cita anch'esso 0.3% come limite. Verifica requisiti attuali e definizioni delle metriche.
Se Postmaster mostra 0.18%, indaga qualità delle liste e pertinenza. Non esclude un problema DMARC contemporaneo: verifica entrambi prima di cambiare politica.
Prima di una politica DMARC reject, controlla:
- Il tasso di spam Google Postmaster Tools del dominio di invio.
- Picchi di segnalazioni legati a campagne, liste o strumenti.
- Mancati recapiti che suggeriscono dati vecchi o indirizzi funzionali.
- Reputazione condivisa tra messaggi transazionali e marketing.
Riferimenti: domande frequenti sulle linee guida Google e buone pratiche Yahoo.
Requisito 4: provare gli inoltri con reject
Prima di una politica DMARC reject, prova gli inoltri. SPF può fallire perché il server intermediario non è autorizzato dal dominio originale. DKIM valido e allineato può consentire DMARC se i dati firmati vengono preservati.
Un errore SPF nei rapporti non prova falsificazione. Se DKIM passa allineato, DMARC passa, ma liste e gateway possono modificare dati firmati e invalidare DKIM.
Verifica canonicalizzazione e firma nei flussi importanti prima della politica DMARC reject. SRS può aiutare SPF con la nuova busta senza necessariamente ripristinare allineamento originale; ARC dipende dal destinatario.
La documentazione TrekMail descrive SPF non valido e DKIM valido dopo inoltro e l'invio gestito disponibile secondo il piano. Verifica la firma del dominio su messaggi reali. Consulta l'inoltro della posta per esaminare modifiche del percorso.
Consulta anche I miei messaggi finiscono nello spam e le impostazioni IMAP e SMTP. Autenticazione allineata non garantisce recapito, e SMTP in uscita dipende dal piano.
Requisito 5: verificare i sottodomini prima di reject
Una politica DMARC reject del dominio organizzativo può essere ereditata da dev.example.com o alerts.example.com in assenza di una politica propria. Verifica sp e record specifici prima delle restrizioni.
Inventaria sviluppo, stampanti, scanner e strumenti vecchi. Produzione corretta non dimostra che questi flussi siano pronti.
Questo esempio usa sp per distinguere l'ereditarietà:
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.comRichiede reject per il dominio principale e none per i sottodomini che ereditano il record, non quelli con politica propria. Valuta in seguito se irrigidirli.
I rapporti possono rivelare CRM o relay dimenticati, ma la copertura è parziale e un'origine sconosciuta non prova abuso. La politica DMARC reject richiede un inventario indipendente.
Applicare reject per fasi
Valuta una politica DMARC reject dopo prove e osservazione. Quarantine richiede già una restrizione; pct richiede applicazione parziale secondo il destinatario, senza garantire una transizione sicura.
Esempio indicativo:
- Richiedere quarantine al 10% per una settimana con risposta agli incidenti preparata.
- Valutare quarantine al 100% per un'altra settimana o due, estendendo secondo i cicli.
- Valutare reject dopo prove di supporto, fatturazione, autenticazione e inoltri.
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.comv=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comI record sono alternative successive: pubblicane soltanto uno. Quarantine non garantisce recupero; reject può produrre notifiche di mancato recapito e, secondo l'errore, nuovi tentativi. Una politica DMARC reject può rifiutare un messaggio legittimo prima che raggiunga la casella di posta.
Gestire reject su più domini
Una politica DMARC reject richiede più coordinamento con dieci, cinquanta o cinquecento domini. Ogni fornitore ha configurazioni DKIM proprie, e ogni dominio richiede inventario aggiornato.
Approccio disperso: esaminare XML a mano, indagare IP, correggere dominio per dominio e dipendere da avvisi informali sui mittenti.
Approccio coordinato: centralizzare domini, documentare DNS e mantenere prove riproducibili.
TrekMail pubblicizza piani a pagamento da $3.50 al mese con SMTP gestito secondo le condizioni e un pannello per gestire domini, caselle IMAP, inoltri e DNS. Nano è offerto gratuitamente fino a 10 domini con SMTP proprio. Consulta l'hosting multidominio e verifica le funzioni vigenti.
Il coordinamento può ridurre attività ripetitive, senza garantire risparmio o meno incidenti. Mantieni procedure per aggiornare i mittenti prima di una politica DMARC reject.
Consulta i record DNS richiesti e trekmail.net/pricing. I piani a pagamento possono includere una prova di 14 giorni con carta richiesta; Nano è offerto senza carta secondo i termini attuali.
Conclusione: quando pubblicare reject
Per valutare una politica DMARC reject, osserva almeno 30 giorni come riferimento ed estendi per cicli rari, verifica autenticazione allineata, segnalazioni, inoltri ed ereditarietà dei sottodomini. Nessun indicatore isolato dimostra preparazione completa.
Inventaria mittenti, leggi intestazioni e correggi DNS e percorsi prima della politica DMARC reject. Continua a monitorare: la richiesta può aiutare contro falsificazione senza coprire ogni abuso.
Per coordinare l'infrastruttura, consulta TrekMail o confronta i piani su trekmail.net/pricing.
