Updated on June 11, 2026: We updated this guide for RFC 9989 DMARCbis policy discovery. RFC 9989 now defines DMARC, RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting, so the guidance now covers DNS Tree Walk discovery plus active np, psd, and t tag behavior.
A DMARC policy published on the organizational domain applies to that domain and to subdomains that do not publish their own DMARC record. A DMARC record published on a subdomain is used first for that exact Author Domain; if deeper names fall back through RFC 9989 DNS Tree Walk, its sp= or np= settings can apply to those names. The sp= tag lets the applicable policy record set a separate policy for existing subdomains, while np= can set a separate policy for non-existent subdomains. This means p=none can monitor the organizational domain while sp=reject or np=reject blocks unauthenticated mail that claims to come from subdomains that are not allowed to send mail.
I treat the organizational domain as the baseline protection point. For example, if example.com publishes a DMARC record at _dmarc.example.com, receivers use that record for mail from example.com and for mail from billing.example.com if that subdomain has no DMARC record of its own and policy discovery does not find a more specific applicable record. If billing.example.com publishes its own record, that exact record wins.
This matters because most organizations use separate subdomains for marketing, transactional mail, product notifications, support, or system alerts. A clean DMARC monitoring setup shows which senders use each domain before enforcement starts.
How DMARC chooses a policy
DMARC policy discovery starts with the visible From domain in the message header. Receivers look for a TXT record at _dmarc. plus that exact Author Domain. If they find a valid DMARC record, they use it. If they do not find one, RFC 9989 uses a DNS Tree Walk to find the applicable Organizational Domain or Public Suffix Domain record.
The organizational domain is determined by DNS Tree Walk, not just by a public suffix list or the DNS root. For news.example.com, the organizational domain is usually example.com. For country-code domains, the boundary can still be different, such as example.co.uk. The psd= tag can identify Public Suffix Domain policy handling when that applies. The public DMARC overview explains the basic model of using SPF, DKIM, visible From domains, and policy.
- Exact record: A record at _dmarc.news.example.com controls mail using news.example.com in the visible From domain.
- Fallback record: If no exact subdomain record exists, DNS Tree Walk finds the applicable organizational or PSD record.
- Subdomain tag: The sp= tag sets the fallback policy for existing subdomains, while np= can set it for non-existent subdomains.
- No merging: If a subdomain publishes its own record, tags are read from that record rather than mixed with the organizational record.
Flowchart showing exact subdomain lookup before organizational domain fallback.
The short version of p and sp
The p= tag is the requested policy for the domain that publishes the DMARC record. On the organizational domain, it controls that organizational domain. The sp= tag is the requested policy for existing subdomains that fall back to the organizational domain or PSD record, while np= can set the policy for non-existent subdomains. If np= is absent, receivers use sp= when present, then p=. The sp tag is optional, but it is the cleanest way to use a different policy for subdomains without publishing records on every subdomain.
Organizational record
- Scope: Covers the organizational domain and subdomains without exact DMARC records.
- Policy: Uses p= for the organizational domain, sp= for existing fallback subdomains, and np= for non-existent fallback subdomains when present.
- Best use: Baseline protection, reporting, and enforcement for the whole organization.
Subdomain record
- Scope: Covers only the exact subdomain in the visible From domain.
- Policy: Uses its own p= value. It does not inherit the parent rua destination.
- Best use: Separate enforcement for a known mail stream, such as marketing or transactional mail.
The most common mistake is assuming a DMARC record on mail.example.com always controls deeper names such as alerts.mail.example.com. Under RFC 9989, receivers use DNS Tree Walk after the exact Author Domain lookup, so intermediate names can be queried. If mail.example.com is the Organizational Domain found by that walk, its sp= or np= policy can apply to deeper names. If a higher organizational domain record is the applicable policy record, that higher record applies instead.
Important inheritance rule
A subdomain with its own DMARC record overrides the organizational domain policy for that exact subdomain. It does not receive the parent rua, ruf, or t= settings unless those values are also present in the subdomain record.
Policy examples that work
A simple organizational-domain record can collect reports for the whole domain family. I start with reporting, identify every legitimate sender, fix SPF and DKIM domain match issues, then move the policy through enforcement. If the organization has unknown or unused subdomains, I usually make sp= stricter than p= after the reporting data is clean.
Organizational domain with separate subdomain policydns
_dmarc.example.com TXT "v=DMARC1; p=none; sp=reject; rua=mailto:dmarc-rua@example.com"
That record tells receivers to monitor mail from example.com, while rejecting unauthenticated mail from subdomains that do not publish exact records. This is useful when the organizational domain still has legacy senders, but random subdomains are not supposed to send mail.
Exact subdomain record with its own policydns
_dmarc.marketing.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com"
That second record controls only messages with marketing.example.com in the visible From domain. It does not control product.marketing.example.com, and it does not change the organizational domain record.
|
|
|
|
|---|---|---|---|
example.com | Yes | p tag | Org policy |
news.example.com | No | sp or np tag | Fallback |
mail.example.com | Yes | p tag | Exact only |
a.mail.example.com | No | sp or np tag | Org fallback |
Which DMARC policy is used in common cases.
When subdomains need records
Subdomains do not automatically need their own records. If they use the same enforcement posture and the same reporting destination as the organizational domain, the organizational record plus sp=, and np= when non-existent names need different handling, is often cleaner. A separate subdomain record is useful when that subdomain has a different risk level, different sender ownership, or a different rollout timeline. The question of whether a subdomain needs its own DMARC record comes down to control, reporting, and policy separation.
- Use inheritance: Use the organizational domain record when subdomains share the same policy goal.
- Use exact records: Publish a subdomain record when one sender or business unit needs separate control.
- Use strict sp or np: Set a stricter subdomain fallback when random subdomain spoofing is a real threat.
- Use reporting: Keep aggregate report destinations active on every exact record you publish.
Good subdomain candidates
- Marketing: Bulk campaign traffic benefits from a separate domain and a staged policy.
- Transactional: Receipts, password resets, and product notices need careful sender inventory.
- Support: Helpdesk mail often uses different DKIM selectors and sending systems.
- Systems: Alerts and automated notices should be checked before reject is applied.
How to roll out enforcement safely
The safe path is report first, enforce after the data proves that legitimate senders pass SPF or DKIM with the right visible From domain match. I do not jump straight to reject on a domain family with unknown senders. First, I validate the DNS record, read aggregate reports, identify senders, fix authentication gaps, then increase enforcement.
DMARC enforcement stages
A practical sequence for moving a domain family through policy enforcement.
Monitor
p=none
Collect reports and map every legitimate sender.
Filter
p=quarantine
Send failing mail to spam after sender issues are fixed.
Reject
p=reject
Block failing mail after approved mail is clean.
Before changing policy, run the record through a focused DMARC checker. If the domain has no record yet, create a starting record with a DMARC record generator and keep reporting enabled while the policy is staged.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The rollout order usually looks like this:
- Publish reporting: Start with p=none on the organizational domain and include a working rua destination.
- Map senders: Group sources by organizational domain, marketing subdomain, transactional subdomain, and support subdomain.
- Fix failures: Correct SPF includes, DKIM selectors, and envelope domains before policy enforcement.
- Stage policy: Move known-clean domains to quarantine and then reject after report data confirms stability.
Where Suped fits
For this workflow, Suped is the best overall practical choice for most teams because it connects DMARC records, SPF, DKIM, sender discovery, policy staging, real-time alerts, and issue remediation in one place. That matters when one organizational domain has several subdomains, each with different senders and different enforcement readiness.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC workflow is useful when DNS access is slow or split across teams. You can manage policy staging centrally, use Hosted DMARC for simplified policy changes, and pair it with Hosted SPF, SPF flattening, Hosted MTA-STS, blocklist (blacklist) monitoring, and deliverability insights when the domain program grows.
Practical Suped workflow
- Detect: See verified and unverified sources across the organizational domain and subdomains.
- Diagnose: Use automated issue detection and steps to fix SPF, DKIM, and DMARC failures.
- Stage: Move domains through monitor, quarantine, and reject with clearer ownership.
- Scale: Use MSP and multi-tenancy dashboards when many client domains need the same controls.
Views from the trenches
Best practices
Publish the organizational domain record first, then add exact subdomain records only when needed.
Use sp to protect idle or unknown subdomains while the main domain stays in monitor mode.
Keep report destinations consistent so subdomain data remains easy to compare and audit.
Common pitfalls
Do not expect a subdomain record to cover deeper names such as child.mail.example.com.
Do not publish a subdomain record without rua reporting unless lost visibility is acceptable.
Do not jump to reject before checking every active sender that uses the subdomain.
Expert tips
Set sp stricter than p when unknown subdomains create higher spoofing risk than the main domain.
Use separate subdomains for mail streams, then enforce each stream after it is clean.
Document who owns each subdomain before changing DNS, especially in shared organizations.
Marketer from Email Geeks says an organizational domain DMARC record covers that domain and subdomains without exact records, so it is the right baseline.
2024-03-12 - Email Geeks
Marketer from Email Geeks says the sp tag is efficient when the main domain and subdomains need different enforcement levels.
2024-04-08 - Email Geeks
The practical answer
Publish DMARC on the organizational domain first whenever you control it. That gives the whole domain family a baseline, including subdomains that do not publish exact records. Use sp= when the existing subdomain fallback policy should differ from the organizational domain policy, and np= when non-existent subdomains need a separate policy. Publish exact subdomain records only where a subdomain needs its own reporting, ownership, or enforcement stage.
The clean pattern for most teams is p=none with reporting at the start, then stricter sp= or np= for unused subdomains after sender data is clean, then staged enforcement on each active domain. Suped's product makes that workflow easier to manage because the reporting, diagnostics, policy staging, alerts, and domain portfolio view are tied together.
