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, I first collect the ESP-supplied SPF, DKIM, bounce, tracking, and reply-handling records. Then I decide whether the subdomain needs a dedicated DMARC TXT record.
For ongoing reporting, Suped's DMARC monitoring is the practical overall choice for most teams because it 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: If no exact subdomain DMARC TXT record exists, receivers check the organizational domain DMARC record.
Separate control: Publish a subdomain record when you want separate policy staging, reporting, or identifier-match controls.
ESP records: Ask the ESP for the exact DKIM, SPF, Return-Path, click tracking, and reply records for each subdomain.
No A record shortcut: Do not treat an A record as an email authentication record. It solves a different DNS problem.
Use the parent policy unless you need a reason not to
I keep subdomain DMARC records boring 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.
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.
Item
Where it goes
When needed
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.
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.
Infographic showing root DMARC, subdomain DMARC, DKIM selector, and ESP records.
How inheritance and sp work
DMARC policy discovery is specific before general. Receivers check the exact From domain first. If alert1.domain.com has its own DMARC record, that record wins. If it does not, the organizational domain record at _dmarc.domain.com supplies the policy.
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.
Using root policy only
Best fit: Several subdomains use the same enforcement plan and reporting mailbox.
DNS load: One DMARC record is easier to maintain than repeated copies.
Main risk: A strict parent policy affects any subdomain that lacks an override.
Using subdomain records
Best fit: A mail stream needs separate policy staging or separate report routing.
DNS load: Each subdomain record needs ownership and review.
Main risk: A stale override can leave one stream weaker than the rest.
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. I use overrides deliberately and remove them when the subdomain catches up.
Step-by-step setup
I 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 senders: Write down every ESP and internal system that sends using the subdomain.
Confirm domains: Ask which domain appears in the visible From, DKIM signature, Return-Path, tracking links, and reply path.
Publish ESP DNS: Add the provider's DKIM, SPF, bounce, tracking, and reply records exactly as supplied.
Choose scope: Use root inheritance for shared policy, or publish a subdomain DMARC record for separate control.
Start reports: Include aggregate reporting before enforcement so you can see real pass and fail sources.
Raise policy: Move to quarantine or reject after legitimate mail passes through an SPF domain match or DKIM domain match.
If you need 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.
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.
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, I test in two layers. First, I validate the DNS record itself. Then I 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 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
A record only: An A record does not create SPF, DKIM, or a DMARC domain match.
Missing reports: A monitoring policy without aggregate reporting leaves you blind.
Wrong host: Putting the TXT value on the subdomain itself is not the same as putting it under the DMARC host.
Duplicate records: Multiple DMARC TXT values at one host cause receivers to ignore the policy.
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.
I also 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.
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. That is the difference between publishing DMARC and actually operating it.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
