How do I set up DMARC records for subdomains?
Updated on 23 Jun 2026: We updated this guide for the current DMARC RFCs, DNS Tree Walk behavior, and CNAME conflicts on sending subdomains.
To set up DMARC records for subdomains, first check whether you actually need separate subdomain DMARC records. If your root domain already has a valid DMARC record, subdomains inherit that policy by default. A separate TXT record at _dmarc.alert1 is only needed when that subdomain needs its own policy, reporting address, identifier-match settings, or your ESP asks for it.
The most common mistake is starting with an A record. An A record points a host name to an IP address. It does not authenticate email. For a sending subdomain such as alert1.domain.com, collect the ESP-supplied SPF, DKIM, bounce, tracking, and reply-handling records first. Then decide whether the subdomain needs a dedicated DMARC TXT record.
For ongoing reporting, Suped's DMARC monitoring connects DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, and blocklist (blacklist) monitoring in one workflow. That matters once subdomains multiply and each stream needs its own evidence.
The direct setup answer
The direct answer is this: publish DMARC at the organizational domain first, add reporting, then create a subdomain DMARC record only when that subdomain needs to behave differently. If domain.com has _dmarc with p=none, then alert1.domain.com also gets that monitoring policy unless a more specific subdomain DMARC record exists.
- Default inheritance means receivers use the organizational domain DMARC record when no valid subdomain record exists.
- Separate control is useful when a subdomain needs its own policy staging, reporting destination, or identifier-match controls.
- ESP records should be requested for the exact DKIM, SPF, Return-Path, click tracking, and reply hosts used by each subdomain.
- An A record is not an email authentication record, so it does not replace SPF, DKIM, or DMARC.
Use the parent policy unless you need a reason not to
Keep subdomain DMARC records simple unless the mail stream needs isolation. A newsletter subdomain, transactional alert subdomain, and support subdomain can inherit one parent policy during early monitoring. Dedicated records become useful when one stream is ready for enforcement before another.
Root DMARC record with reportingdns
Host: _dmarc TXT: v=DMARC1; p=none; rua=mailto:d@domain.com
A root record with no reporting address is technically a DMARC record, but it gives you little operational value. Add aggregate reports at the start, then use those reports to decide which subdomains pass SPF or DKIM in real mail.
What to add in DNS
A sending subdomain usually needs more than DMARC. The exact records depend on how your ESP sends mail. The visible From domain, the DKIM signing domain, and the Return-Path domain determine whether DMARC passes through an SPF domain match, a DKIM domain match, or both.
|
|
|
|---|---|---|
DMARC | Policy host | Override or reports |
SPF | Bounce host | SPF pass path |
DKIM | Selector host | Signed mail |
MX | Mail host | Inbound mail |
A or AAAA | Web host | Web traffic |
DNS items to confirm for each sending subdomain
For update@alert1.domain.com, the DMARC lookup starts at the visible From domain. Receivers first look for a record at the subdomain. If they do not find one, they move up to the organizational domain. That inheritance behavior is the main reason you do not need to copy the same DMARC record to every subdomain.
Recipients also see the subdomain when it appears in the visible From address. Mail from support.domain.com or alerts.domain.com can be a good separation pattern, but it should be an intentional sender identity choice.
Optional subdomain DMARC recordsdns
Root domain: Host: _dmarc TXT: v=DMARC1; p=none; rua=mailto:d@domain.com Alert subdomain 1: Host: _dmarc.alert1 TXT: v=DMARC1; p=none; rua=mailto:d@domain.com Alert subdomain 2: Host: _dmarc.alert2 TXT: v=DMARC1; p=none; rua=mailto:d@domain.com
Some DNS editors want the host as _dmarc.alert1. Others want the full host name. Do not publish both. The final DNS name must resolve to one DMARC TXT record at _dmarc.alert1.domain.com.
Check the exact owner name before adding ESP records. If alert1.domain.com already has a CNAME, do not add MX, TXT, A, or AAAA at alert1.domain.com. Use a separate verification host such as verify.alert1.domain.com, ask the ESP for direct records, or confirm whether the ESP checks the CNAME target. DMARC for that sender still lives at _dmarc.alert1.domain.com, which is a different owner name.
Infographic showing root DMARC, subdomain DMARC, DKIM selector, and ESP records.
How inheritance, sp, and np work
DMARC policy discovery is specific before general. Receivers check the exact From domain first. If alert1.domain.com has its own valid DMARC record, that record wins. If it does not, receivers use DNS Tree Walk behavior to find the organizational domain record at _dmarc.domain.com.
The sp tag lets the root DMARC record set a different policy for subdomains. For example, p=quarantine with sp=reject tells receivers to quarantine failing root-domain mail and reject failing subdomain mail. If sp is absent, subdomains use the p policy.
The np tag handles non-existent subdomains when the parent record is used. Active sending subdomains usually need sp or their own DMARC record; np is mainly for made-up names under the domain.
Using root policy only
- This fits when several subdomains use the same enforcement plan and reporting mailbox.
- One DMARC record is easier to maintain than repeated copies.
- A strict parent policy affects any subdomain that lacks an override.
Using subdomain records
- This fits when a mail stream needs separate policy staging or separate report routing.
- Each subdomain record needs ownership and review.
- A stale override can leave one stream weaker than the rest.
Root record with subdomain and non-existent name policiesdns
Host: _dmarc TXT: v=DMARC1; p=quarantine; sp=none; np=reject; rua=mailto:d@domain.com
A dedicated subdomain record also overrides the parent. That subdomain override is useful when a new alert stream needs monitoring while the parent domain already runs quarantine or reject. Use overrides deliberately and remove them when the subdomain catches up.
RFC 9989 changes for subdomains
DMARC is now defined by RFC 9989. RFC 7489 is obsolete, and aggregate and failure reporting are split into RFC 9990 and RFC 9991. For subdomain setup, the practical change is clearer policy discovery and staging guidance, not a new TXT syntax for ordinary records.
- DNS Tree Walk means receivers check the exact Author Domain, then walk toward the organizational domain and public suffix when needed.
- The np tag can set handling for non-existent subdomains, while psd is for public suffix policy cases.
- Do not use pct for staged enforcement in new records. It is historic under the current DMARC specification.
- Use reporting, subdomain overrides, limited traffic, and policy changes from p=none to p=quarantine to p=reject instead.
What stays the same
The operational setup remains familiar: publish one valid TXT record at the correct DMARC owner name, make SPF or DKIM pass with the visible From domain, collect aggregate reports, and raise policy after legitimate traffic is clean.
Step-by-step setup
Use the same order for newsletter subdomains, product alert subdomains, and notification subdomains. DMARC comes after you know how the ESP wants to authenticate the mail.
- List every ESP and internal system that sends using the subdomain.
- Confirm which domain appears in the visible From, DKIM signature, Return-Path, tracking links, and reply path.
- Publish the provider's DKIM, SPF, bounce, tracking, and reply records exactly as supplied.
- Use root inheritance for shared policy, or publish a subdomain DMARC record for separate control.
- Include aggregate reporting before enforcement so you can see real pass and fail sources.
- Move to quarantine or reject after legitimate mail passes through an SPF domain match or DKIM domain match.
For a clean starting point, use the Suped DMARC record generator to create a record, then adjust the host name for the exact subdomain only when an override is needed.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
For teams managing several domains or client accounts, Suped's Hosted DMARC reduces direct DNS edits after the initial setup. That is useful when subdomain policy staging changes often, because the operational work moves into controlled policy settings instead of repeated zone-file edits.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Do not skip SPF and DKIM
DMARC does not authenticate by itself. It checks whether SPF or DKIM passed and matched the visible From domain. A subdomain DMARC record without working SPF or DKIM produces reports, but it does not make the mail trustworthy.
Testing before traffic
After DNS is published, test in two layers. First, validate the DNS record itself. Then send real email through the ESP and inspect the authentication result in the headers and DMARC reports. Both checks matter because a syntactically valid record can still fail the domain-match check.
Use the Suped DMARC checker to confirm that the record resolves, has one DMARC TXT value, and parses cleanly.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Then send a small batch through each new subdomain. Check that DKIM passes with a matching signing domain or SPF passes with a matching Return-Path domain. With relaxed mode, the organizational domain match is enough. With strict mode, the domains must match exactly.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product helps here by grouping DMARC sources, flagging unauthenticated senders, showing SPF and DKIM diagnostics, and sending real-time alerts when failures cross a threshold. That shortens the loop between publishing a record and knowing whether the subdomain is ready for more traffic.
Common mistakes
Most subdomain DMARC problems come from mixing DNS concepts together. The zone editor accepts many record types, but email authentication is picky about host names, record counts, and the domain in the actual email headers.
Mistakes that break subdomain DMARC
- An A record does not create SPF, DKIM, or a DMARC domain match.
- A monitoring policy without aggregate reporting leaves you blind.
- Putting the TXT value on the subdomain itself is not the same as putting it under the DMARC host.
- Multiple DMARC TXT values at one host cause receivers to ignore the policy.
- Adding MX, TXT, A, or AAAA beside a same-name CNAME creates invalid DNS and can break ESP verification.
If you see failures after publishing, check for multiple DMARC records, DNS host-name expansion errors, and ESP records copied from the root domain without subdomain-specific values.
Avoid jumping straight to p=reject on a new sending subdomain. Rejection is the right endpoint for a mature stream, but the first step is usually reporting. Once the ESP records are stable and reports show legitimate mail passing, enforcement becomes a measured change instead of a guess.
Do not rely on pct for staged enforcement in new DMARC records. Under RFC 9989 it is historic, so stage with monitoring, limited traffic, subdomain-specific policy, and then enforcement.
Policy readiness for a new subdomain
A practical way to stage enforcement after the subdomain starts sending real traffic.
Monitoring
p=none
Use while sources and domain matching are still being confirmed.
Partial enforcement
p=quarantine
Use after legitimate traffic passes and failure volume is understood.
Full enforcement
p=reject
Use after unauthorized sources are removed or fixed.
Views from the trenches
Best practices
Start each sending subdomain at p=none, then raise policy after reports show clean matching.
Keep ESP-provided DKIM and bounce records separate for each subdomain unless told otherwise.
Use a root sp tag only after every active subdomain has authenticated mail flow checked.
Common pitfalls
Adding an A record and skipping DKIM leaves the subdomain without reliable DMARC matches.
Copying the root DMARC record to every subdomain hides which stream has a problem.
Publishing two DMARC TXT records at one host makes many receivers ignore the policy.
Expert tips
Ask the ESP which domain appears in the Return-Path before deciding where SPF belongs.
Keep alert streams on separate subdomains when reputation or reporting needs clearly differ.
Use Suped alerts to catch new unauthenticated subdomain traffic before enforcement.
Expert from Email Geeks says DMARC alone usually needs no new subdomain record when the organizational policy already matches the intended policy for the new sender.
2024-04-18 - Email Geeks
Expert from Email Geeks says a DMARC record without reporting gives little operational value because teams cannot see which sources pass or fail.
2024-06-02 - Email Geeks
The practical answer
Set up DMARC for subdomains by starting at the root domain, adding reporting, and letting subdomains inherit that policy unless a separate policy is needed. For alert1.domain.com and alert2.domain.com, that means you usually do not add a DMARC TXT record just because the subdomain exists. You add it because the subdomain needs different policy behavior.
The DNS work you almost always need is the ESP-specific authentication setup: DKIM selectors, SPF or Return-Path records, tracking records, and reply handling when replies matter. After that, publish or adjust DMARC, test real mail, and raise enforcement only after the reports show clean matching.
Suped fits this workflow when you need more than a static DNS record. Its product shows which subdomains are sending, which sources are authenticated, which ones need fixes, and when a policy can move forward.
