DMARC policy explained
dmarc policy · p=reject · email authentication
Understand p=, sp=, pct=, and how policy changes affect spoofed mail before you move from monitoring to enforcement.
Di DN01 Network Team
DMARC policy tells receivers what to do when SPF and DKIM alignment fail for the visible From domain. L'analizzatore DMARC DN01 recupera il TXT _dmarc, analizza i tag e evidenzia policy e alignment prima dell'enforcement. Gli operatori lo usano in migrazioni, triage incidenti e onboarding vendor quando servono prove ripetibili invece di screenshot isolati.
A published TXT record at _dmarc.example.com is useless without aligned SPF or DKIM success paths for legitimate senders.
Run the DMARC Analyzer on your domain, read p= and pct= separately, and only tighten policy after aggregate reports look stable. Combina l'output DMARC con validatori SPF e DKIM sullo stesso dominio per correggere l'autenticazione insieme. Salva il permalink del risultato nel ticket, registra l'ora del controllo e confronta l'output prima e dopo modifiche di configurazione o aggiornamenti client.
Ripeti il controllo dopo ogni modifica rilevante e conserva il link della guida nel runbook del team così i nuovi operatori seguono lo stesso ordine diagnostico.
Tag evidenziati da DN01
La policy p= e il sottodominio sp= definiscono le azioni dei destinatari; pct= limita quanta mail copre la policy durante il rollout.
Le modalità aspf e adkim controllano matching relaxed o strict tra domini autenticati e header From visibile.
Errori di rollout
Pubblicare reject mentre marketing o ticketing inviano con DKIM del vendor rompe la posta legittima in spam.
Ignorare i report aggregati fa scoprire fonti non allineate solo dopo reclami su ricevute mancanti.
Percorso sicuro di enforcement
Inizia con p=none e rua, correggi l'allineamento per ogni mittente approvato, poi quarantine prima di reject.
Usa pct<100 solo come ponte temporaneo; documenta la data obiettivo per enforcement completo nel runbook mail.
Documentazione e passi successivi
Archivia l'output del controllo nei ticket di change, revisioni vendor e incidenti così il prossimo operatore vede la stessa evidenza analizzata.
Collega questa guida e la landing dello strumento nei wiki del team e abbina i risultati ad altre utility DN01 quando il problema attraversa DNS, mail, TLS o sicurezza. Annota chi ha eseguito il controllo, quale input è stato usato e se il permalink è stato condiviso con il richiedente.
Quando escalare o combinare i controlli
Se l'output di Analizzatore DMARC continua a discordare dal resoconto utente dopo riavvio o svuotamento cache, cattura timestamp, input grezzi e permalink DN01 prima di modificare DNS, mail, TLS o auth di produzione.
Escala ai responsabili piattaforma o identità quando la policy aziendale blocca la correzione; altrimenti abbina questa guida alle utility DN01 DNS, mail, TLS o sicurezza per chiudere il loop in un ticket.
| Policy | Uso tipico |
|---|---|
| p=none | Monitorare e raccogliere rua |
| p=quarantine | Ammorbidire i fallimenti verso spam |
| p=reject | Bloccare spoof dopo alignment pulito |
| pct<100 | Solo enforcement graduale |
Domande frequenti
- DMARC sostituisce SPF o DKIM?
No. DMARC dipende da SPF e DKIM più alignment con il dominio From.
- Ogni dominio deve usare p=reject?
Molti domini mittenti dovrebbero, ma solo dopo report con posta legittima allineata e senza fonti a sorpresa.
- Perché mostrare pct separatamente?
reject con pct=20 non è enforcement completo. DN01 mostra pct per non sovrastimare la protezione.
- Posso condividere i risultati con il team?
Sì. Copia l'output DN01 o il permalink nei ticket di change così tutti rivedono la stessa evidenza analizzata invece di screenshot isolati.