Blog · Dmarc
How to Enforce DMARC for All Subdomains (The Wildcard DKIM Method)
Does Root DMARC Protect Subdomains?
No. A DMARC record published on your root domain (_dmarc.example.com) only covers mail from that exact domain. Subdomains such as mail.example.com or newsletter.example.com are not automatically protected just because the root domain has a DMARC record.
This trips up a lot of people. They set up DMARC, run it for a while, and then discover that a subdomain has been sending unauthenticated email for months without them knowing. The root DMARC policy never applied to it.
The fix is deliberate: you need to either add a separate DMARC record for each subdomain you care about, or use DNS wildcards to cover all of them at once. Wildcards are faster and scale better.
The Wildcard DKIM Method - Step by Step
Wildcard DKIM works by pointing a DNS CNAME record at your existing DKIM selector. Any subdomain that does not have its own DKIM key will inherit the wildcard signature automatically, as long as your mail system is configured to sign with that selector.
Step 1: Create the Wildcard DKIM CNAME Record
Add this DNS record to your root domain:
Host: *._domainkey
Type: CNAME
Value: selector1._domainkey.example.com.
Replace selector1 with whatever selector name your email provider uses. For Google Workspace, that is typically selector1. For Microsoft 365, it depends on the DKIM configuration in the Exchange admin center.
What this does: when a receiving mail server looks for a DKIM signature from newsletter.example.com, it will first check for newsletter._domainkey.example.com. If that record does not exist, it will follow the wildcard CNAME and find selector1._domainkey.example.com instead. As long as your mail system signs newsletter.example.com with the same selector, DKIM will pass.
Step 2: Add the Subdomain Policy Tag to Your DMARC Record
Update your root DMARC record to include the sp tag, which sets the policy for subdomains separately from the root domain:
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:aggregate@example.com; aspf=s;
The sp=quarantine tag tells receiving servers to treat DMARC failures on subdomains the same way they treat failures on the root domain. Change quarantine to reject only after you have confirmed all legitimate subdomain senders are passing authentication.
The aspf=s tag sets strict alignment mode. This means the From domain and the RFC5321.MailFrom domain must match exactly (for SPF) or the From domain and the DKIM signing domain must match exactly (for DKIM). Strict mode is safer but requires more thorough testing before rollout.
Step 3: Verify SPF Alignment for Subdomains
SPF alignment for subdomains works through a concept called the organizational domain. A receiving server determines the organizational domain for any subdomain by examining the domain suffix. For newsletter.example.com, the organizational domain is example.com.
When a subdomain does not have its own explicit SPF record, the SPF lookup follows the CNAME chain up to the organizational domain. As long as the From domain and the RFC5321.MailFrom domain share the same organizational domain, SPF alignment is satisfied automatically under aspf=s.
If a subdomain uses a different sending infrastructure (for example, a marketing platform that uses its own sending domain), that subdomain needs its own explicit SPF record. You also need to verify that the RFC5321.MailFrom domain's organizational domain matches the From domain's organizational domain for DMARC alignment to pass.
How to Check That Subdomain Protection Is Working
After deploying wildcard DKIM and the sp tag, send a test email from a subdomain to an external address that provides authentication feedback. Gmail and Outlook.com both show authentication results in the message headers.
Look for these headers in the received email:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=selector1;
spf=pass google.com: example.com;
dmarc=pass header.from=@example.com
If DKIM shows pass for your subdomain using the wildcard selector, the CNAME is working. If it shows fail, either the subdomain is not being signed by your mail system, or the wildcard CNAME is misconfigured.
Common Mistakes That Break Subdomain DMARC
Mistake 1: Your mail system does not sign all subdomains
The wildcard DKIM CNAME only helps if your mail system actually signs outbound email from each subdomain. Some email platforms only sign the root domain by default and require a separate opt-in per subdomain. Check your platform's documentation for subdomain signing.
Mistake 2: You set p=reject before verifying subdomain coverage
Setting DMARC to reject before confirming all legitimate subdomain senders are passing authentication will break legitimate email. Start with p=quarantine, monitor aggregate reports, fix failures, then move to p=reject.
Mistake 3: The wildcard CNAME points to the wrong selector
If the CNAME target (selector1._domainkey.example.com) does not match the selector your mail system actually uses, DKIM verification will fail. Verify the selector name in your email platform's DKIM settings before creating the wildcard CNAME.
Mistake 4: You forgot the trailing dot in the CNAME value
DNS CNAME records must end with a trailing dot. Without it, the resolver appends the origin domain again, creating an invalid loop. Always write selector1._domainkey.example.com. with the trailing dot.
Mistake 5: You set sp= but forgot aspf=s
The sp tag only sets the subdomain policy. The aspf tag controls alignment mode. Without aspf=s, alignment mode defaults to relaxed, which can allow subtle mismatches to pass when you intended strict checking.
What Aggregate Reports Tell You About Subdomain Health
Aggregate reports (sent to the rua address in your DMARC record) show which servers are sending email on behalf of your domain, whether they pass authentication, and which subdomains are generating failures. Without monitoring these reports, subdomain DMARC failures are invisible until a sender calls to complain that their email is not arriving.
This is where tools like DMARCFlow help. Aggregate reports arrive as XML, which is not human-readable by default. DMARCFlow parses these reports and shows you per-subdomain pass/fail rates, new sources that have appeared, and sudden changes in authentication behavior across your entire domain portfolio.
If you see a subdomain with a high DMARC failure rate, the first place to check is whether that subdomain is actually being signed with your wildcard selector. If it is not, either enable subdomain signing in your email platform or add an explicit DKIM record for that subdomain.
FAQ
Q: Does the wildcard DKIM CNAME work for every subdomain?
A: It works for any subdomain that does not have its own explicit DKIM record. If a subdomain has its own DKIM record, that takes precedence. Wildcard is a fallback, not an override.
Q: Can I set different policies for different subdomains?
A: Yes. You can publish individual DMARC records on specific subdomains. For example, newsletter.example.com could have p=reject while internal.example.com has p=none. Subdomain records take precedence over the wildcard sp= policy.
Q: Does the sp tag cover subdomains of subdomains?
A: Yes. The sp tag applies to all subdomains at any level under the domain where the DMARC record is published, unless a subdomain has its own explicit DMARC record.
Q: Do I need a wildcard DKIM record for each email platform I use?
A: If you use multiple platforms that each sign with different selectors, you need a wildcard DKIM CNAME for each selector. Some platforms use their own selector namespace and you cannot use a single wildcard to cover all of them.
The Short Version
Root DMARC does not protect subdomains automatically. To cover all subdomains at once: add a wildcard DKIM CNAME pointing to your existing selector, set sp= in your root DMARC record to apply the same policy to subdomains, and verify that your mail system signs all outbound subdomains with that selector. Then monitor aggregate reports to catch failures before they become problems.