DMARC subdomain policy sp=
dmarc sp tag · subdomain dmarc policy · sp=reject
When sp= matters for mail.example.com, how it inherits from p=, and why separate subdomain senders need explicit alignment.
Di DN01 Network Team
The sp= tag defines policy for organizational subdomains when their From addresses use a subdomain of the DMARC 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.
Marketing platforms, support desks, and product mailers often send from subdomains that never inherit the parent policy you thought covered them.
Check sp= in DN01 output alongside p=, list every active subdomain sender, and publish aligned SPF or DKIM for each before tightening enforcement. 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.