How do I set up DMARC records for subdomains?
Updated on 24 Oct 2026: We clarified subdomain policy inheritance, reporting overrides, and testing, and added protection for subdomains that never send email.
To set up DMARC records for subdomains, first check whether you need a separate record. If your organizational 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, domain-matching settings, or your ESP asks for it.
An A record is not required just to publish DMARC. It 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 groups authentication results by sending subdomain so teams can review each mail stream before changing policy.
When subdomains need a DMARC record
Publish DMARC at the organizational domain first, add reporting, then create a subdomain DMARC record only when that subdomain needs to behave differently. A subdomain record also works independently when the organizational domain has no DMARC record. If domain.com has _dmarc with p=none and no sp policy, then alert1.domain.com also gets that monitoring policy unless a valid DMARC record exists at that exact From domain.
- 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 organizational-domain policy for shared settings
Keep subdomain DMARC records simple unless a mail stream needs separate control. Newsletter and transactional subdomains can inherit one organizational-domain 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 DMARC record without a reporting address still requests policy handling, but it does not request aggregate reports. Add rua at the start, then use reports to check which subdomains pass DMARC 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 (RFC5322.From) domain, the DKIM signing domain, and the Return-Path (RFC5321.MailFrom) domain determine whether DMARC passes through an SPF domain match, a DKIM domain match, or both.
|
|
|
|---|---|---|
DMARC TXT | _dmarc.alert1.domain.com | Separate policy or reporting for alert1.domain.com |
SPF TXT | Actual Return-Path domain | Authorize the sending servers for that domain |
DKIM TXT or CNAME | Selector under the DKIM signing domain, such as s1._domainkey.alert1.domain.com | Publish the signing key or provider-supplied target |
MX | Domain receiving email or bounces | Route incoming messages as required by the provider |
A or AAAA | Host requiring an IP address | Address mapping, not a DMARC prerequisite |
DNS items to confirm for each sending subdomain
SPF records do not inherit the root-domain policy. Publish SPF at the actual Return-Path domain, not automatically at every visible From subdomain. A shared Return-Path under the same organizational domain can satisfy relaxed SPF domain matching. See RFC 7208. DKIM keys are looked up using the signature's s= selector and d= signing domain, rather than inheriting a parent key. See RFC 6376.
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.
Subdomain enforcement after testing, with the root still monitoringdns
Organizational domain (domain.com zone): Host: _dmarc TXT: v=DMARC1; p=none; rua=mailto:d@domain.com Tested alert subdomain: Host: _dmarc.alert1 TXT: v=DMARC1; p=reject; rua=mailto:d@domain.com
A dedicated subdomain record replaces the inherited settings; its reporting addresses are not combined with the parent's. Include rua in the subdomain record even when reports should go to the same mailbox. Omit a dedicated record when the inherited settings already fit.
In the domain.com DNS zone, some editors want the host as _dmarc.alert1. Others want the full host name; in a separately delegated alert1.domain.com zone, the relative host is _dmarc. Do not publish both. The final DNS name must resolve to one DMARC TXT record at _dmarc.alert1.domain.com.
If rua sends reports to another organizational domain, that destination must authorize the domain where the policy was retrieved, using a specific or wildcard TXT authorization record. For a policy at alert1.domain.com and reports sent to d@example.net, the authorization name is alert1.domain.com._report._dmarc.example.net with the value v=DMARC1. When mail inherits the domain.com policy instead, use domain.com as the authorization prefix. Without valid authorization, report generators must ignore that external destination. See RFC 9990.
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.
DMARC TXT record placement for a root domain and sending subdomains, with DKIM selectors 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 requests quarantine for failing root-domain mail and rejection for failing subdomain mail. For existing subdomains, if sp is absent, subdomains use the p policy.
The np tag sets policy for non-existent subdomains when the organizational-domain record is used. If np is absent, those names fall back to sp, then p. Existing sending subdomains use sp or p unless they have an exact-domain override.
Publish sp on the organizational-domain policy. A dedicated record at _dmarc.alert1.domain.com applies its own p value to that Author Domain, so adding sp there does not create a second policy layer for its children. For a nested From domain such as news.alert1.domain.com, do not assume the nearest parent record at _dmarc.alert1.domain.com supplies the inherited policy.
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.
- An enforcing 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.
Control delegated subdomain access
A parent sp=reject policy cannot overrule a valid DMARC record published for an exact subdomain. A team or contractor with DNS control for a delegated subdomain can publish p=none at that subdomain, which weakens the inherited handling for mail using that From domain.
Delegated DNS can also affect relaxed domain matching. Control of an SPF domain or DKIM selector below the organizational domain can produce a matching identifier for root-domain mail. To require exact matches for both authentication paths, use aspf=s and adkim=s together, after testing legitimate senders. Making only one strict leaves the other authentication path available.
Treat subdomain DMARC as a governed DNS change
- Record which team controls every delegated sending subdomain and its authentication records.
- Require review before publishing a weaker exact-domain DMARC policy.
- Audit dedicated subdomain records for stale p=none exceptions after migrations.
- Remove abandoned DNS delegations and vendor records when a sending relationship ends.
Protect subdomains that never send email
Existing subdomains used only for websites can still appear in forged From addresses. np=reject applies to non-existent names that return NXDOMAIN, so it does not cover an existing subdomain simply because it sends no mail.
If the inherited policy already requests reject for these subdomains, keep inheritance. Otherwise, publish an exact-domain p=reject record after confirming that no legitimate service sends with that From domain. For unused.domain.com:
DMARC for an existing subdomain that never sends emaildns
Host: _dmarc.unused.domain.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:d@domain.com
A DMARC reject policy does not disable incoming email. Keep the existing MX records if the subdomain receives messages.
RFC 9989 changes for subdomains
RFC 9989 defines DMARC and obsoletes RFC 7489 and RFC 9091. Aggregate and failure reporting are defined separately in RFC 9990 and RFC 9991. For subdomain setup, the practical changes are DNS Tree Walk policy discovery and revised testing guidance. The record type is still TXT.
- DNS Tree Walk checks the exact Author Domain, then walks upward to find the organizational domain or a public suffix policy when needed. The walk is bounded to eight DNS queries for deeply nested names.
- The np tag can set handling for non-existent subdomains, while psd identifies public suffix policy cases.
- The pct tag was removed. Do not use it to apply enforcement to a percentage of failures.
- The t=y tag requests one level less enforcement: quarantine becomes none, and reject becomes quarantine. It does not change reporting and has no effect on a none policy.
- Use aggregate reports and controlled traffic before moving policy from p=none to enforcement. A receiver still decides how it handles a DMARC result.
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 each sending subdomain. First confirm how the ESP authenticates 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 rua in every dedicated DMARC record, and verify external reporting authorization when required, so reporting continues after an override.
- Move to quarantine or reject after legitimate mail passes through an SPF domain match or DKIM domain match. If you used t=y during testing, remove it or set t=n when enabling the full requested policy.
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.
Test DNS and real message authentication
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 DMARC record does not ensure that messages pass 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
Check the exact subdomain and organizational-domain recordsbash
dig +short TXT _dmarc.alert1.domain.com dig +short TXT _dmarc.domain.com
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.
Illustrative message headers with passing DMARCtext
From: update@alert1.domain.com Return-Path: <bounce@bounce.alert1.domain.com> DKIM-Signature: v=1; d=alert1.domain.com; s=s1; ... Authentication-Results: receiver.example; spf=pass smtp.mailfrom=bounce.alert1.domain.com; dkim=pass header.d=alert1.domain.com; dmarc=pass header.from=alert1.domain.com
In this example, DKIM matches the From domain exactly, while SPF matches in relaxed mode only. Either passing method with the required domain match is sufficient for DMARC. Read the Authentication-Results header added by the receiving service.
Allow cached DNS answers to expire according to their TTL before judging a change. Aggregate reports generally arrive daily, so inspect a test message immediately and review reports after a reporting cycle. See RFC 9990.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product groups DMARC sources by subdomain, flags unauthenticated senders, shows SPF and DKIM diagnostics, and sends alerts when failures cross a configured threshold. That shortens the loop between publishing a record and deciding 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 records at one host are discarded at that host; discovery can still find an applicable organizational-domain 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 t=y to keep new mail in monitoring. Receivers implementing RFC 7489 ignore that newer tag and still see the published policy. Start at p=none when you need monitoring across receiver versions.
Policy readiness for a new subdomain
Policies request handling for DMARC failures; receivers still apply their local rules.
Monitoring
p=none
Use while sources and domain matching are still being confirmed.
Quarantine policy
p=quarantine
Use after legitimate traffic passes and failure volume is understood.
Reject policy
p=reject
Use after legitimate senders pass DMARC and remaining failures have been investigated.
Frequently asked questions
No. Subdomains inherit the organizational domain DMARC policy by default. Add a subdomain DMARC record only when the subdomain needs a different policy, reporting destination, or identifier-match setting.
Publish it at _dmarc.alert1.domain.com. In many DNS editors, that means entering _dmarc.alert1 as the host in the domain.com zone. In a separately delegated alert1.domain.com zone, use _dmarc as the relative host.
No. An A record points a host name to an IP address. DMARC requires SPF or DKIM to pass with the required match to the visible From domain. Both are recommended, but one matching pass is sufficient.
Use sp when you want the root record to apply a different policy to existing subdomains. Use np when you want a policy for non-existent subdomains. An exact subdomain record uses its own p value.
Use reject after testing shows legitimate mail passes DMARC. New subdomains usually start with reporting, then move to quarantine or reject after domain matching is stable. RFC 9989 also defines t=y as a test-mode signal for an enforcement policy, but receivers retain control over message handling.
No. A CNAME owner name cannot share that same owner name with MX, TXT, A, or AAAA records. Use a separate verification host, direct records from the ESP, or the CNAME target if the verifier accepts it.
