Yes. DKIM can be set up on a subdomain, and a subdomain can have its own DKIM CNAME or TXT record. The record name is built under the signing domain, so a signature using d= email.example.com points receivers to a selector under email.example.com, not only the root domain.
The domain you should use for DKIM signing is usually the domain in the visible Header From address. If the message From address is news@email.example.com, the cleanest DKIM signature uses d= email.example.com. If the provider can only sign with example.com, that still passes DMARC in relaxed DKIM alignment because both domains share the same organizational domain. It fails in strict DKIM alignment, where the DKIM signing domain must match the Header From domain exactly.
I treat parent-domain signing as a valid fallback for relaxed DMARC, not as the best long-term setup. Exact subdomain signing gives clearer reports, cleaner source ownership, and an easier path to strict alignment later.
How DKIM works on subdomains
A DKIM signature has two fields that decide the DNS lookup. The d= field names the signing domain, and the s= field names the selector. Receivers combine those values into a DNS name like selector._domainkey.signing-domain. That signing domain can be example.com, email.example.com, news.example.com, or another subdomain you control.
Root-domain DKIM lookup
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ... DNS name: s1._domainkey.example.com
Subdomain DKIM CNAME
Host: s1._domainkey.email.example.com Type: CNAME Value: s1-email-example-com._domainkey.esp.example.net
- DKIM key: The public key lives at the exact DNS name derived from the signing domain.
- Selector: The selector lets a provider rotate keys without changing the visible From address.
- No inheritance: A key under example.com is not automatically a key for email.example.com.
- CNAME setup: Many ESPs ask for a CNAME so they can host and rotate the public key.
Which domain should sign
The right signing domain depends on the Header From domain, not the bounce address by itself. DMARC checks whether DKIM authentication uses a domain that is aligned with the visible From domain. SPF checks the SMTP Mail From, also called the Return-Path or bounce domain.
|
|
|
|---|---|---|
From is email.example.com | email.example.com | Passes relaxed and strict DKIM alignment. |
From is email.example.com | example.com | Passes relaxed, fails strict. |
From is example.com | email.example.com | Passes relaxed, fails strict. |
Provider signs with its domain | Provider domain | Does not satisfy DKIM alignment for your domain. |
DKIM signing choices when the visible From domain changes.
Header From
This is the address people see in the message, such as news@email.example.com. DMARC compares this domain with the DKIM signing domain and the SPF-authenticated Mail From domain.
Mail From
This is the SMTP return path used for bounces. SPF authenticates this domain. It does not decide DKIM alignment unless the provider also uses it as the DKIM signing domain.
That difference explains why a sender can use email.example.com as the Mail From domain while still signing with example.com. If the visible From address is example.com, example.com is the correct DKIM signing domain. If the visible From address is email.example.com, I prefer email.example.com as the signing domain.
A five-step flow from Header From domain to DMARC validation.
Relaxed and strict DMARC matching
DMARC has two matching modes for DKIM. Relaxed mode is the default. In relaxed mode, email.example.com and example.com are treated as the same organizational domain. In strict mode, they are not. Strict mode requires the DKIM d= domain to be exactly the same as the Header From domain.
Relaxed DMARC policy
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; adkim=r; aspf=r; " "rua=mailto:dmarc@example.com" )
Strict DMARC policy
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=reject; adkim=s; aspf=s; " "rua=mailto:dmarc@example.com" )
DKIM match outcomes
What a receiver sees when the visible From domain is email.example.com.
Exact subdomain
d=email.example.com
Works in relaxed and strict mode.
Parent domain
d=example.com
Works only with relaxed DKIM alignment.
Provider domain
d=provider.test
Does not count for your domain unless SPF covers DMARC.
Only one authenticated path needs to pass DMARC alignment: DKIM or SPF. I still avoid relying on SPF alone for marketing and product mail because forwarding commonly breaks SPF, while DKIM survives when the body and signed headers remain unchanged.
If you are deciding how strict to be, first confirm which sources can sign with the exact visible From domain. The page on DKIM alignment is useful when you need to explain why this match matters for authentication.
When an ESP only supports the root domain
When an ESP says DKIM can only be set up on the main domain, ask what that means in the account. Sometimes it means the UI only accepts example.com as the account domain. Sometimes it means the platform signs every message with example.com. Sometimes it means the support team is talking about where the CNAME has to be created, not what the final DKIM d= value will be.
Do not confuse the CNAME host with the signing domain
- DNS host: The selector host is where the public key or CNAME is published.
- Signature domain: The DKIM d= value is the domain DMARC checks against Header From.
- Provider target: The CNAME target can be provider-owned and still validate correctly.
- Header domain: The visible From domain is the domain used for DMARC matching.
If the visible From domain is email.example.com and the ESP cannot sign with that subdomain, root-domain signing is acceptable only while DMARC uses relaxed DKIM alignment. If you run strict DKIM alignment, that provider needs exact subdomain signing or you need a different sending configuration.
The same decision comes up when one account sends with more than one Header From domain. The practical answer is to configure custom DKIM for each visible From domain that sends real mail. For more detail on multi-domain sending, see different Header From domains.
A practical setup pattern
The safest implementation pattern is simple: inventory the domains people see, sign with those domains, publish the selector records exactly where the provider asks, then test a real message. I do not treat DNS propagation as proof. The received headers are the proof.
- Inventory: List every visible From domain used by newsletters, billing, product mail, and support.
- Choose: Use the exact Header From domain as the DKIM signing domain whenever the sender supports it.
- Publish: Add the selector CNAME or TXT record under the signing domain, not a nearby domain.
- Test: Send a real email and inspect Authentication-Results for DKIM and DMARC.
- Monitor: Review aggregate reports by source so you know which systems still fail.
- Tighten: Move policy toward quarantine or reject after legitimate mail is passing.
After publishing the selector, I check the DNS record with the DKIM checker before relying on production mail. That catches missing CNAMEs, malformed TXT records, weak selector placement, and records that resolve at the wrong host.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For a broader check across SPF, DKIM, and DMARC on the same domain, the domain health checker is a faster way to see whether the domain is ready for enforcement.
How to read the headers
Once DKIM is enabled, send a message to a mailbox you can inspect. Look for Authentication-Results. A passing DKIM result tells you the cryptographic signature validated. The important DMARC question is whether the DKIM signing domain matches the Header From domain closely enough for your policy mode.
Exact subdomain signing
Authentication-Results: mx.example.net; dkim=pass header.d=email.example.com header.s=s1; spf=pass smtp.mailfrom=bounces.email.example.com; dmarc=pass header.from=email.example.com
Parent-domain signing under relaxed DKIM alignment
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=s1; dmarc=pass header.from=email.example.com
What success looks like
- DKIM pass: The signature validates against the DNS key at the selector host.
- Header match: The DKIM domain matches Header From exactly or by relaxed organizational-domain rules.
- SPF backup: SPF passes with a Mail From domain that also matches Header From for DMARC.
- DMARC pass: At least one authenticated path passes the required domain match.
If the second example runs under strict DKIM alignment, DMARC will not count that DKIM pass because example.com and email.example.com are not an exact match. That does not make the DKIM signature invalid. It means the signature is not the right identity for that strict DMARC policy.
Common mistakes I see
Most DKIM subdomain problems come from mixing up identity, DNS location, and provider defaults. The fix is rarely complicated, but it has to be applied to the exact sending domain.
Mistakes
- Root assumption: Publishing a key at example.com does not create a key for email.example.com.
- Provider domain: A DKIM pass with a provider domain does not protect your DMARC result.
- Strict mode: Parent-domain signing breaks DKIM alignment when the policy uses strict matching.
- DNS typo: A missing selector label gives receivers nothing useful to query.
Fixes
- Exact signing: Sign with the exact visible From domain when the ESP supports it.
- Separate keys: Create selectors per sending domain and per provider.
- Report review: Use aggregate reports to confirm which domains authenticate.
- Header test: Send a message and inspect Authentication-Results before enforcement.
Where Suped fits
Suped is the best overall DMARC platform for this workflow when you need more than a one-time DNS lookup. Suped's product connects the DNS record, the actual mail source, the authentication result, and the fix steps in one place. That matters when several ESPs, product systems, and support tools all send with different subdomains.
With DMARC monitoring in Suped, I can see whether each source is signing with the expected domain, whether DKIM or SPF is carrying DMARC, and which sources need a selector, CNAME, or provider-side custom domain change.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The main advantage is operational. Real-time alerts catch new failures, automated issue detection points to the affected source, and hosted SPF or hosted DMARC can reduce DNS change friction for teams that manage many domains. MSPs and agencies also get multi-tenant views, so subdomain signing issues do not get buried across client accounts.
Views from the trenches
Best practices
Sign each visible From domain with its own DKIM selector and document who owns key rotation.
Test with a real sent email, then read Authentication-Results before changing DMARC policy.
Keep parent-domain signing only when relaxed DKIM alignment is intentional for that stream.
Common pitfalls
Assuming DKIM keys inherit across subdomains leaves selectors published in the wrong place.
Treating Mail From as Header From causes teams to solve the wrong authentication issue.
Relying on provider-domain DKIM creates a DMARC gap when SPF fails after forwarding.
Expert tips
Use separate selectors per provider so key rotation never disrupts another sending path.
Move to strict DKIM alignment only after every subdomain signs with the exact domain.
Review DMARC reports by source before deciding that root-domain DKIM is enough for mail.
Marketer from Email Geeks says DKIM can be configured on subdomains, but each domain should have its own key and selector.
2020-06-20 - Email Geeks
Marketer from Email Geeks says DMARC checks the Header From domain, so confusing it with Mail From leads to the wrong signing choice.
2020-06-20 - Email Geeks
My final recommendation
If the From address uses a subdomain, set up DKIM on that subdomain and sign with that exact subdomain whenever possible. If your ESP only signs with the root domain, it can still pass DMARC in relaxed mode, but it is not strict-DKIM ready.
For a domain like email.example.com, the best practical setup is a DKIM selector under email.example.com, a DKIM signature using email.example.com, and DMARC reports that confirm the source is passing. That setup keeps authentication understandable for the next person who has to troubleshoot it.
