Do subdomains need their own DMARC records if the main domain has one?
Updated on 22 Oct 2026: We clarified subdomain DMARC inheritance, custom MAIL FROM requirements, and policy rollout safeguards.
No, a subdomain does not always need its own DMARC record if the organizational domain already has one. A DMARC record published at _dmarc.example.com can apply to mail using news.example.com, sender.example.com, and other subdomains when those subdomains do not publish their own DMARC records. That is normal DMARC policy discovery.
The caveat is important: add a subdomain record when it needs a different policy, reporting destination, rollout stage, or troubleshooting boundary. If a subdomain is failing DMARC, the absence of a direct record is usually not the root cause when a valid organizational-domain policy applies. Check SPF and DKIM authentication and alignment first. Investigate reputation separately if DMARC passes but mail lands in spam.
The short answer
A DMARC record on the organizational domain can cover its subdomains when the exact Author Domain has no valid record of its own. Under RFC 9989, receivers check the exact Author Domain first. If no valid record is found there, they use the DNS Tree Walk to find the organizational domain or an applicable Public Suffix Domain policy.
DMARC is evaluated against the domain in the visible From header, called the Author Domain in RFC 9989. If the From domain is sender.example.com, the receiver first checks _dmarc.sender.example.com. If that record does not exist, the receiver walks up the DNS hierarchy to determine the organizational domain and any applicable Public Suffix Domain policy. In a straightforward example.com setup, the applicable owner policy will usually be found at _dmarc.example.com.
That makes "every sending subdomain must have its own DMARC TXT record" too broad. Every visible From domain you want DMARC to protect needs an applicable policy, either directly or through policy discovery.
- Default coverage: A valid organizational-domain record covers subdomains that do not publish their own DMARC records.
- Exact-domain override: A valid record on the exact Author Domain supplies the policy for that domain.
- Policy separation: Use a subdomain record when marketing, transactional, vendor, or internal mail needs different enforcement.
- Reporting separation: Use a subdomain record when aggregate or failure reports need subdomain-specific routing.
For more detail, the page on subdomain DMARC overrides explains how receivers choose between the exact subdomain and an inherited policy.
How DMARC inheritance works
DMARC policy discovery checks the visible From subdomain before the parent domain.
DMARC does not merge settings across DNS levels. It finds the relevant policy record, then evaluates authentication domain alignment against that record. For troubleshooting, use two steps: find the DMARC policy, then determine whether SPF or DKIM produced an aligned pass for the visible From domain. An exact subdomain record does not inherit missing tags such as rua from the parent.
If a message uses sender.example.com in the From header, the receiver first checks for a record at _dmarc.sender.example.com. If it finds one, it uses that record's policy, reporting tags, alignment settings, and other tag values. If it does not find one, RFC 9989 directs the receiver to walk up the DNS hierarchy, with no more than eight policy queries, to determine the organizational domain or applicable Public Suffix Domain. Separate Tree Walks can also be needed to evaluate relaxed SPF or DKIM alignment. For a typical setup, the owner policy is found at _dmarc.example.com.
Organizational-domain record covering subdomainsdns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
With only the organizational-domain record above, mail using sender.example.com is still covered by DMARC. It uses the organizational domain's p=quarantine policy unless sp or np supplies the applicable inherited policy. These values describe handling of mail that fails DMARC.
Organizational-domain record with a subdomain policydns
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"
In that example, the organizational domain uses p=reject, while existing subdomains without their own records use sp=quarantine. The sp tag sets the inherited policy for existing subdomains without their own records. RFC 9989 also defines np for non-existent subdomains and uses psd=y or psd=n to identify Public Suffix Domain and organizational boundaries during the DNS Tree Walk. Ordinary domain owners should publish a psd value only when they know that boundary status applies.
For deeper names such as a.mail.example.com, an intermediate record does not automatically override the organizational-domain record. Under RFC 9989, psd=n can establish a separate organizational boundary; the nearest ancestor record is not automatically the policy source.
Does a custom MAIL FROM subdomain need DMARC?
A subdomain used only as the MAIL FROM (envelope sender or Return-Path) does not need its own DMARC record just for that role. DMARC policy discovery uses the visible From domain. SPF checks the MAIL FROM domain.
Different domains in the same messagetext
Visible From: news@example.com MAIL FROM / Return-Path: bounce@bounces.example.com DKIM signing domain (d=): example.com
Here, DMARC lookup starts at _dmarc.example.com. Publish SPF for bounces.example.com because SPF records do not inherit. With default relaxed SPF matching (aspf=r), the domains share the organizational domain example.com. With aspf=s, SPF cannot satisfy DMARC because the domain names differ. A passing DKIM signature with d=example.com can still satisfy DMARC.
For DKIM, adkim=r permits a shared organizational domain, while adkim=s requires an exact domain match. Changing only the Return-Path does not move the DMARC policy lookup to that subdomain.
Existing and non-existent subdomains
RFC 9989 separates existing subdomains from non-existent subdomains because the applicable inherited tag can differ. An existing subdomain without its own DMARC record uses sp when the organizational-domain record supplies it. A non-existent subdomain uses np when supplied.
Organizational-domain record with existing and non-existent subdomain policiesdns
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com"
|
|
|
|---|---|---|
Valid exact DMARC record | p on exact record | No inherited policy |
Existing subdomain, no exact record | sp on organizational record | p if sp is absent |
Non-existent subdomain | np on organizational record | sp, then p |
RFC 9989 policy selection for an Author Domain
For DMARC, a domain exists when any DNS resource record exists at that name. A missing A, AAAA, or MX record does not by itself make the name non-existent. An NXDOMAIN response means the name does not exist, while a NOERROR response with no data for the queried record type means the name still exists.
Receivers implementing only RFC 7489 use Public Suffix List discovery and ignore unknown tags. Keep p and sp safe for legitimate traffic; t=y is not a safeguard at receivers that ignore it. Check aggregate reports to see which policy receivers applied.
When a subdomain should have its own record
Publish an explicit subdomain DMARC record when that subdomain needs a different policy or reporting destination. Transactional and marketing mail often use separate senders, volumes, complaint controls, and owners, which can justify different policy or report routing.
Parent record is enough
- Same policy: The subdomain can use the same enforcement policy as the organizational domain.
- Same reporting: Aggregate reports can go to the same reporting destination.
- Simple sender map: Only a small number of approved platforms send for the domain.
- Low change rate: New vendors and new sending streams are rare.
Subdomain record helps
- Different policy: The subdomain needs quarantine while the parent is still at none, or the reverse.
- Different reports: Security, marketing, a vendor, or compliance needs separate aggregate report routing.
- Receiver compatibility: An exact record gives legacy and RFC 9989 receivers the same policy location.
- Vendor rollout: Change a vendor subdomain's policy without changing the parent's default for other subdomains.
Aggregate reports include the visible From domain even when the policy is inherited. A separate record is useful for different report routing, not simply to identify a subdomain's traffic.
A testing tool can report "no DMARC record found" after checking only the exact subdomain. That result is incomplete when an applicable policy exists higher in the DNS hierarchy. A complete RFC 9989 check starts at the exact Author Domain and performs policy discovery.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Use Suped's DMARC checker on both the organizational domain and the active subdomain. If the organizational-domain record exists and the subdomain has no exact record, identify which inherited policy applies and whether SPF or DKIM produced an aligned pass.
Why DMARC passes do not guarantee inbox placement
A missing subdomain record is easy to see, so it often gets blamed for spam placement. That can be wrong. Mailbox providers do not reward a domain just because it has a DMARC TXT record. DMARC checks whether SPF or DKIM authenticates a domain that matches the visible From domain under the published mode. It does not erase complaint history, low engagement, list quality problems, sudden volume spikes, or unwanted content.
|
|
|
|---|---|---|
No DMARC seen | Tool checked exact host only | Full policy discovery |
DMARC fail | Neither SPF nor DKIM passes with alignment | Authentication results and domain matching |
DKIM pass, DMARC fail | Signing domain not aligned | DKIM d= value |
Spam placement | Reputation or complaints | Complaint rate |
Mixed results | Multiple senders | Per-source report data |
Common causes of subdomain DMARC failure or spam placement
Do not treat a passing DMARC result as a deliverability guarantee. Passing DMARC means SPF or DKIM passed and aligned with the visible From domain. Inbox placement still depends on reputation, recipient behavior, complaints, list acquisition, volume pattern, and content.
DMARC DNS patterns for subdomains
Choose a pattern based on whether subdomains need the same policy or separate control.
Pattern 1: organizational domain onlydns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Use this when you are starting DMARC monitoring and want broad visibility before enforcement. It covers the organizational domain and subdomains without their own records. It is low maintenance, but gives less control over each subdomain.
Pattern 2: organizational domain with subdomain policydns
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"
Use this when the organizational domain is ready for one enforcement level and subdomains need another. This is common when corporate mail is ready for reject, but marketing or product subdomains still need staged enforcement.
Pattern 3: explicit subdomain recorddns
_dmarc.sender.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:sender-dmarc@example.com"
Use this when the subdomain needs its own reporting address, owner, policy stage, or exception handling. It does not make the subdomain automatically pass DMARC. SPF or DKIM must still pass with a domain that matches the Author Domain under the configured relaxed or strict mode.
Subdomain policy rollout
Monitor first, then enforce after verifying legitimate senders. Test mode depends on receiver support.
Monitor
p=none
Collect reports and identify legitimate senders.
Optional test mode
p=quarantine; t=y
RFC 9989 receivers reduce quarantine to none; receivers that ignore t=y still see quarantine.
Quarantine
p=quarantine
Apply quarantine after legitimate sources pass consistently.
Reject
p=reject
Request rejection after legitimate sources are aligned.
What to check before adding a record
Before adding a subdomain DMARC record, check real message headers and aggregate reports. DNS alone tells only part of the story. A message can have an applicable organizational-domain policy and still fail because neither SPF nor DKIM passed with alignment to the visible From domain.
- Visible From: Confirm whether the message uses the organizational domain or a subdomain in the From header.
- Exact DMARC: Check whether the exact Author Domain has a valid DMARC record.
- Policy discovery: If the exact subdomain has no record, walk the DNS hierarchy and identify the applicable p, sp, or np policy.
- SPF alignment: Compare the MAIL FROM domain with the visible From domain under the published alignment mode.
- DKIM alignment: Check the DKIM signing domain and confirm that a passing signature aligns with the visible From domain.
- Report evidence: Use aggregate reports to find recurring failures by visible From domain and source. Where present, discovery_method identifies psl or treewalk processing.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's DMARC monitoring brings the applied policy, authentication results, verified sources, and DNS diagnostics into one workflow. Use it to review failures by subdomain and source after a sender change. DMARC aggregate reports do not include recipient complaint rates; review complaint data separately.
How to create a subdomain DMARC record
If you decide to add a record, keep it simple. Do not copy a strict reject policy onto a busy subdomain until you have verified all legitimate senders. Start with reporting, fix domain alignment, then move toward enforcement.
Safe starting record for a sending subdomaindns
_dmarc.sender.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
In an example.com DNS zone, enter _dmarc.sender if the DNS panel appends the zone name. In a separately hosted sender.example.com zone, enter _dmarc. Confirm that the resulting TXT hostname is _dmarc.sender.example.com.
That record requests aggregate reports for the subdomain without requesting quarantine or rejection of failing mail. Include rua on the subdomain record because the parent's address is not inherited. A reporting destination outside the policy domain's organization needs external-report authorization. Once legitimate mail passes DMARC consistently, move the policy to quarantine and then reject. If the organizational domain has a stronger policy, an explicit subdomain record with p=none weakens enforcement for that Author Domain, so use it only during a deliberate rollout.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Do not publish more than one DMARC TXT record at the same hostname. Multiple DMARC policy records at one name are discarded during RFC 9989 discovery, so the intended exact-domain policy is lost and an inherited policy can apply instead. If you need to change policy, edit the existing record instead of adding another one.
If you are comparing this with other multi-record mistakes, the page on multiple DMARC records explains why duplicate policy records at one hostname are discarded.
When to publish a subdomain DMARC record
For a quick decision, use the table below. It keeps the answer tied to the operational requirement instead of a warning that checked only the exact host.
|
|
|
|---|---|---|
Organizational policy fits | No | Same policy |
Different reports | Yes | Cleaner routing |
Different policy | Yes | Local control |
Vendor testing | Often | Safer rollout |
High complaints | Not enough | Fix reputation |
Exact-host warning | Check first | Check inherited policy |
When to publish subdomain DMARC
When a subdomain needs explicit control, Suped's Hosted DMARC provides a workflow for staging its policy and reviewing authentication failures before enforcement.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Common mistakes to avoid
Most subdomain DMARC mistakes come from treating DNS records as the whole system. DMARC depends on DNS, but the result is decided by the message that gets sent.
- Checking only DNS: Inspect a real message header and aggregate report data before blaming the record.
- Ignoring alignment: An SPF pass does not support a DMARC pass unless the SPF domain aligns with the visible From domain.
- Copying reject too early: A reject policy on a subdomain can block legitimate vendor mail if DKIM or SPF alignment has not been fixed.
- Forgetting reports: A record without aggregate reporting gives you less evidence when something breaks later.
- Mistaking spam for DMARC: Spam placement after a DMARC pass usually points to reputation, complaints, list quality, or sending patterns.
A clean setup for important subdomains has explicit ownership, aligned DKIM, aligned SPF where practical, and DMARC reports that are reviewed after each sender change.
If a vendor says a subdomain record never matters, ask for specifics. Identify the domain in the From header, the DMARC record being applied, the passing authentication mechanism, its alignment result, and the report data that supports the answer. The correct result is visible in the message and the reports.
Views from the trenches
Best practices
Check the exact From domain first, then confirm the parent policy before changing DNS.
Use explicit subdomain records when reporting, policy, ownership, or rollout stages need separation.
Review DKIM and SPF domain matches before treating a missing subdomain record as causal.
Common pitfalls
A tool warning for the exact host can miss the parent DMARC record that still applies.
Adding a subdomain record will not fix complaint-driven spam placement or reputation by itself.
Copying reject to a vendor subdomain too early can block legitimate operational mail.
Expert tips
When np is absent, non-existent subdomains inherit sp if present, then fall back to p.
Keep each active sending subdomain tied to a named owner and a documented approved sender list.
Treat authentication as identity proof, then evaluate reputation and recipient behavior.
Expert view
Expert from Email Geeks says a parent domain DMARC record can cover subdomains when those subdomains do not need their own policy or report routing.
2023-11-13 - Email Geeks
Expert view
Expert from Email Geeks says a separate subdomain record becomes useful when the policy or aggregate report destination needs to differ.
2023-11-13 - Email Geeks
Frequently asked questions
It applies to subdomains that do not publish a valid record at the exact Author Domain. If the organizational-domain record has an sp tag, that tag sets the inherited policy for existing subdomains. If it has an np tag, that tag sets policy for non-existent subdomains. Without np, non-existent subdomains fall back to sp when present, then p.
Yes. If a valid record exists at the exact Author Domain used in the From address, receivers use its p policy instead of an inherited organizational-domain policy.
Not by itself. It can clarify policy and reporting, but spam placement depends on authentication alignment, complaint rates, reputation, list quality, and sending behavior.
Use a separate record when the marketing subdomain needs a different enforcement policy or reporting destination. Sending volume alone does not require another DMARC record.
Start with p=none for monitoring unless you have already verified all legitimate senders. Move to quarantine or reject after SPF or DKIM passes with alignment to the visible From domain consistently. If the parent already enforces quarantine or reject, an explicit p=none record weakens protection for that From domain during the rollout.
Under RFC 9989, an organizational-domain np tag supplies the policy for a subdomain that returns NXDOMAIN. If np is absent, the receiver uses sp when present, then falls back to p.
