DMARC Policies for Organizational Domains and Subdomains Explained
Updated on 22 Oct 2026: We clarified DMARC subdomain inheritance and added practical SPF and DKIM setup examples.
A DMARC policy published on the organizational domain applies to that domain and to subdomains that fall back to it. An ordinary record published on a subdomain is used for that exact Author Domain through its p= tag. Its sp= and np= tags do not make that ordinary subdomain record the fallback for deeper names. Those tags are used when the applicable record belongs to the Organizational Domain or a Public Suffix Domain.
This means an organizational record can use p=none to monitor the organizational domain while sp=reject requests rejection of mail that fails DMARC for existing subdomains without exact records. The np=reject value requests the same treatment for non-existent subdomains. Use sp for existing non-sending names and np for names that do not exist in DNS.
Treat the organizational domain as the baseline protection point. 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 when the subdomain has no exact record and the DNS Tree Walk selects example.com as the policy domain. If billing.example.com publishes its own record, that exact record wins for mail using that visible From domain.
Most organizations use separate subdomains for marketing, transactional mail, product notifications, support, or system alerts. A clean DMARC monitoring setup shows which authorized and third-party senders use each domain before enforcement starts.
How DMARC chooses a policy
DMARC policy discovery starts with the domain in the visible From header, called the Author Domain in RFC 9989. Receivers query for a TXT record at _dmarc. plus that exact domain. If they find one valid record, they use it. If they do not, a DNS Tree Walk finds the applicable Organizational Domain or Public Suffix Domain record. The walk is limited to eight queries, so unusually deep names can skip intermediate labels. Multiple DMARC records at one DNS name are discarded; discovery then continues.
Policy discovery and authenticated-identifier matching are related but separate checks. With the default relaxed settings, adkim=r and aspf=r, an authenticated DKIM or SPF domain matches when it shares the Author Domain's Organizational Domain. Strict mode uses s and requires the full domain names to match. A subdomain can inherit a policy and still fail DMARC when neither SPF nor DKIM produces a matching authenticated identifier.
Under RFC 9989, the DNS Tree Walk determines the Organizational Domain; RFC 7489 used a public suffix list. For news.example.com, it is usually example.com. For country-code domains, the boundary can be example.co.uk. The psd= tag identifies explicit Organizational Domain or Public Suffix Domain boundaries. DNS delegation alone does not establish this boundary. The public DMARC overview explains the basic model of 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 record exists, the DNS Tree Walk selects the applicable Organizational Domain or PSD record.
- Subdomain tags: On that fallback record, sp= applies to existing subdomains and np= applies to non-existent subdomains.
- No merging: If the Author Domain publishes an exact record, its tags are not mixed with the organizational record.
DMARC policy discovery flowchart for Author Domains, organizational domains, and subdomains.
How p, sp, and np apply
The p= tag is the requested policy for the domain whose record is applied directly. On the Organizational Domain, it controls that 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=. If sp= is absent, existing subdomains use p=. The sp tag is optional, but it is the cleanest way to set a different policy for fallback subdomains.
For np=, non-existent means DNS returns NXDOMAIN for the Author Domain. A missing MX record or NOERROR with no records of the requested type does not establish non-existence. An inactive subdomain that still exists in DNS uses sp= or p=.
Organizational record
- Scope: Covers the Organizational Domain and subdomains that fall back to it.
- 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 organization's domain family.
Exact subdomain record
- Scope: Covers the exact visible From domain; psd=n also establishes an Organizational Domain boundary.
- Policy: Uses its own p= value and does not inherit the parent's reporting destinations.
- Deeper names: The sp= and np= tags on an ordinary subdomain record are ignored.
- Best use: Separate enforcement for a known mail stream, such as marketing or transactional mail.
The common mistake is assuming a record on mail.example.com automatically controls alerts.mail.example.com. The Tree Walk can query the intermediate name, but it usually selects the valid record with the fewest labels as the Organizational Domain. A record at mail.example.com becomes the policy boundary for deeper names only when the discovery rules establish it as the Organizational Domain, such as through psd=n.
Important inheritance rule
A subdomain with its own DMARC record overrides the organizational policy for that exact Author Domain. It does not inherit the parent's rua, ruf, or t= settings. Include the needed values in the exact record. If a reporting address uses a different Organizational Domain, the report consumer must publish an authorization record at <policy-domain>._report._dmarc.<reporting-domain>. The authorization TXT record must contain v=DMARC1, as specified in RFC 9990.
DMARC policy examples for subdomains
A simple organizational-domain record can collect reports for the whole domain family. Start with reporting, identify every legitimate sender, fix SPF and DKIM domain matching, then move the policy through enforcement. If existing subdomains should not send mail, set a stricter sp= after confirming their sender inventory. Use np= for non-existent subdomains.
Organizational domain with separate subdomain policydns
_dmarc.example.com TXT "v=DMARC1; p=none; sp=reject; rua=mailto:dmarc-rua@example.com"
That record requests no DMARC enforcement for mail from example.com while requesting rejection of DMARC failures for subdomains that use this fallback. Because np is absent, sp=reject also applies to non-existent subdomains. It fits a domain where the organizational name still has legacy senders but unused subdomains are not supposed to send mail. Receivers retain the final delivery decision.
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 messages with marketing.example.com in the visible From domain. It does not control product.marketing.example.com and does not change the organizational record. Adding sp= to this ordinary subdomain record would not extend it to deeper names.
|
|
|
|
|
|---|---|---|---|---|
example.com | Exists | Yes | p | Exact record |
news.example.com | Exists | No | sp, otherwise p | example.com |
ghost.example.com | NXDOMAIN | No | np, then sp, then p | example.com |
mail.example.com | Exists | Yes | p | Exact record |
a.mail.example.com | Exists | No | sp, otherwise p | example.com |
Assumes example.com is the Organizational Domain and no separate subtree boundary is discovered. Requested policies apply to DMARC failures.
Creating a delegated policy boundary with psd=n
RFC 9989 lets a domain owner declare a subdomain to be an Organizational Domain for itself and its descendants by publishing psd=n. This is useful when a delegated business unit or DNS subtree needs its own policy and report destinations. It is different from publishing an ordinary exact subdomain record.
Delegated subtree with its own fallback policiesdns
_dmarc.mail.example.com TXT "v=DMARC1; p=quarantine; sp=reject; np=reject; psd=n; rua=mailto:dmarc-rua@mail.example.com"
For mail using alerts.mail.example.com, the Tree Walk can now treat mail.example.com as the Organizational Domain. Its sp=reject value applies when the Author Domain exists, and np=reject applies when it does not.
Plan for mixed receiver behavior
Some receivers can still use RFC 7489 discovery based on a public suffix list and reach a different Organizational Domain. For a critical Author Domain, publish an exact record and test authentication with both relaxed and strict domain-matching assumptions before relying on a delegated psd=n boundary. A new boundary also changes relaxed domain matching, so test DKIM signing and SPF MAIL FROM domains on both sides.
When subdomains need records
Subdomains do not automatically need their own records. If they use the same enforcement posture and 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 record is useful when a subdomain has different sender ownership, risk, or rollout timing. 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 fallback policies: Set sp=reject for existing fallback subdomains and np=reject for non-existent names after checking legitimate senders.
- Keep reporting: Include active aggregate report destinations 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.
SPF and DKIM for sending subdomains
DMARC policy inheritance does not create SPF records or DKIM keys. Configure each sending service to authenticate a domain that matches its visible From domain under the applicable relaxed or strict settings.
SPF checks the SMTP MAIL FROM domain, usually shown in Return-Path, using that domain's SPF record. A record at example.com is not automatically used for bounce.news.example.com. These exact-domain lookups are defined in the SPF specification.
DKIM key lookup uses the signing domain in d= and selector in s=, as defined in the DKIM specification. For this illustrative message, the service needs SPF authorization at the bounce domain and a DKIM key at the selector's DNS name.
Illustrative sending identifiers and DNS namestext
Visible From domain: news.example.com SMTP MAIL FROM domain: bounce.news.example.com SPF TXT lookup: bounce.news.example.com DKIM signing domain: d=news.example.com DKIM selector: s=mail DKIM key lookup: mail._domainkey.news.example.com
DMARC passes when at least one of SPF or DKIM passes with a matching authenticated domain. Passing authentication for a provider's unrelated domain is insufficient.
How to roll out enforcement safely
The safe path is report first, then enforce after the data shows that legitimate senders pass SPF or DKIM with the correct visible From domain match. Do not jump straight to reject on a domain family with unknown senders. Validate the DNS record, read aggregate reports, identify sending sources, fix authentication gaps, then increase enforcement. Review a full sending cycle, including infrequent automated mail.
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
Request suspicious treatment for DMARC failures after sender issues are fixed.
Reject
p=reject
Request rejection of DMARC failures after approved mail passes consistently.
RFC 9989 removed the legacy pct= tag. Its t=y test mode requests none treatment for a quarantine policy and quarantine treatment for a reject policy, including applicable sp= and np= values. Reports continue. Receivers using older rules ignore t=y and apply the published policy, so it is not a universal safeguard. Remove it or set t=n when the test is complete.
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 aggregate 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 and by each active sending subdomain.
- Fix failures: Correct SPF authorization, DKIM signing, and domain matching before enforcement.
- Stage policy: Move clean domains to quarantine and then reject after report data confirms stable authentication.
Manage subdomain policy changes in Suped
Suped is our DMARC reporting and email authentication platform. For this workflow, teams can separate authorized sources by Organizational Domain and subdomain, then see which names are ready for enforcement.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC workflow starts with a CNAME published by the DNS owner. After that delegation, domain owners can stage policy changes centrally while reviewing report data, which is useful when DNS access is split across teams.
Practical Suped workflow
- Detect: See verified and unverified sources across the Organizational Domain and subdomains.
- Diagnose: Review issue details for SPF, DKIM, and DMARC failures.
- Stage: Move each domain through monitor, quarantine, and reject with clear ownership.
- Govern: Track policy and sender changes across client or business-unit domains.
Subdomain policy checks
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
An ordinary subdomain record covers deeper names only when discovery makes it a boundary.
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.
Frequently asked questions
Yes, when discovery selects that Organizational Domain and the subdomain has no valid exact record. Existing subdomains use sp=, then p=. Non-existent subdomains use np=, then sp=, then p=.
Yes. An exact record controls that exact visible From domain through its p= value. The parent record is not merged into it, and sp= or np= on an ordinary subdomain record does not extend that record to deeper names.
It can be the same, but it does not have to be. A stricter sp= value is useful when existing subdomains are not supposed to send mail.
It declares that domain to be an Organizational Domain for itself and its descendants under RFC 9989. Its sp= and np= policies can then apply within that subtree.
Only when the organizational record is the policy record being used. If a subdomain has its own record, include its own rua tag and authorize an external reporting domain when required.
Start with p=none and a valid aggregate reporting address. Move to quarantine or reject only after legitimate senders pass consistently. RFC 9989 test mode uses t=y instead of the removed pct= tag, but older receivers ignore it and apply the published policy.
