Can DKIM be set up on a subdomain, and which domain should be used for signing?
Published 12 Jul 2025
Updated 19 Oct 2026
12 min read
Summarize with
Updated on 19 Oct 2026: We clarified subdomain DKIM publishing, selector conflicts, and the domain matching needed for DMARC.
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, use d=email.example.com. A valid signature using example.com satisfies relaxed DKIM alignment when both domains have the same organizational domain. It fails strict DKIM alignment, where the DKIM signing domain must match the Header From domain exactly. DMARC can still pass through SPF if SPF passes with the required domain match.
Parent-domain signing is a valid choice for relaxed DMARC. Exact subdomain signing makes strict DKIM alignment possible, but strict mode is optional.
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
DKIM-Signature: v=1; a=rsa-sha256; d=email.example.com; s=s1; ... Host: s1._domainkey.email.example.com Type: CNAME Value: s1-email-example-com._domainkey.esp.example.net
- DKIM key: Receivers retrieve the public key at the selector hostname, following a CNAME if one is present.
- 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.
Publish DKIM in the correct DNS zone
Publish the selector at the authoritative DNS provider. For signing domain email.example.com and selector s1, the final hostname is s1._domainkey.email.example.com. When the DNS interface appends the zone name, enter the relative host below.
|
|
|---|---|
example.com | s1._domainkey.email |
email.example.com (delegated zone) | s1._domainkey |
Both entries produce s1._domainkey.email.example.com. Use the zone that is authoritative for the subdomain.
Avoid selector record conflicts
Use either a CNAME or a direct TXT record at the selector hostname. Do not publish both. If two services request the same hostname, choose another selector for one service instead of replacing an active key.
For direct TXT setup, publish one public-key record per selector. A long key can use multiple quoted strings within that record, each limited to 255 bytes. Do not create separate TXT records for the chunks. RFC 6376 specifies that a receiver joins the strings without adding spaces.
Look up the subdomain selectorbash
dig +short CNAME s1._domainkey.email.example.com dig +short TXT s1._domainkey.email.example.com
The CNAME query shows an alias when one is configured; the TXT query follows it to the public key. Check the saved hostname before waiting for cached DNS answers to expire.
Which domain should sign
The right signing domain depends on the Header From domain, not the bounce address by itself. DMARC checks whether a valid DKIM signature uses a domain that matches the visible From domain under the required alignment mode. 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 when both share an organizational domain, but fails strict. |
From is example.com | email.example.com | Passes relaxed when both share an organizational domain, but fails strict. |
Provider signs with its domain | Provider domain | Does not satisfy DKIM alignment for your domain. |
These results assume the DKIM signature validates. DMARC passes when DKIM or SPF passes with the required domain match.
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. DKIM alignment uses the signature's d= value, regardless of the bounce 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 domain is example.com, example.com is the recommended DKIM signing domain. If the visible From domain is email.example.com, use email.example.com as the signing domain when the provider supports it.
DKIM signing domain selection and DNS setup ending with a DMARC check.
Relaxed and strict DKIM alignment
DMARC has two matching modes for DKIM. Relaxed mode is the default. Under RFC 9989, relaxed alignment compares organizational domains found through a DNS tree walk. A parent domain and subdomain, or sibling subdomains such as news.example.com and email.example.com, satisfy relaxed matching when they have the same organizational domain. Strict mode requires the DKIM d= domain to be exactly the same as the Header From domain.
Relaxed DKIM alignment
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; adkim=r; aspf=r; " "rua=mailto:dmarc@example.com" )
Strict DKIM alignment
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; adkim=s; aspf=r; " "rua=mailto:dmarc@example.com" )
The adkim=s tag enables strict DKIM alignment. It does not require strict SPF alignment or a reject policy. Check _dmarc.email.example.com for a subdomain policy before assuming the parent record's adkim setting applies.
DKIM match outcomes
DKIM alignment for a valid signature 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 with relaxed alignment when both domains have the same organizational domain.
Provider domain
d=provider.test
This signature does not satisfy DKIM alignment. SPF can independently provide a DMARC pass.
Only one authenticated path needs to pass DMARC alignment: DKIM or SPF. Relying on SPF alone is fragile for marketing and product mail because forwarding commonly breaks SPF, while DKIM survives when the body and signed headers remain unchanged.
Before choosing strict alignment, confirm which sources can sign with the exact visible From domain. The page on DKIM alignment explains 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 the UI only accepts example.com as the account domain. Sometimes the platform signs every message with example.com. The support team might also be describing 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, a valid root-domain signature satisfies DKIM alignment only when both domains have the same organizational domain under relaxed mode. Strict DKIM alignment requires exact subdomain signing for DKIM to count. DMARC can still pass through SPF when SPF passes with the required domain match.
The same decision comes up when one account sends with more than one Header From domain. Configure custom DKIM for each visible From domain that sends real mail. For more detail on multi-domain sending, see different Header From domains.
Plan selectors and key rotation
Use a separate selector and private key for each sending service and signing domain. For RSA, sign with rsa-sha256 and use a 2048-bit key where the platform supports it. Current DKIM rules require RSA keys of at least 1024 bits, and verifiers treat smaller RSA keys as invalid. Ed25519-SHA256 is standardized, but provider and receiver support should be confirmed before relying on it. Keep the private key on the sending system; publish only the public key or the provider's CNAME target.
- Separate ownership: Give each sending service its own selector for each domain it signs.
- Stage the key: Publish the new selector and verify that it resolves before the signer starts using it.
- Keep an overlap: Leave the old public key available during the transition for delayed mail and cached DNS responses.
- Retire safely: For routine rotation, remove the old selector after delayed messages have cleared. Revoke a compromised key promptly, and remove provider access when offboarding a service.
DKIM does not prescribe one rotation interval for every sender. Document who owns each key, which selector is active, and how the provider handles rotation. A scheduled review is more useful than an arbitrary interval that nobody verifies.
Set up and test subdomain DKIM
A reliable implementation pattern is to inventory the domains people see, sign with those domains, publish the selector records exactly where the provider asks, then test a real message. DNS propagation alone is not proof. The received headers show what the sender used and what the receiver validated. After publishing DNS, complete the provider's verification and enable custom DKIM signing for the subdomain. A published key alone does not add signatures to outgoing mail.
- 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 toward quarantine after legitimate mail passes. Use reject only when the domain's mail use and failure handling make it appropriate.
After publishing the selector, use Suped's DKIM checker with the signing domain and selector shown in a real message. A DNS lookup checks whether the public key resolves; received headers confirm that the sender used it successfully.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Suped's domain health checker provides a broader check of public authentication DNS. Use received headers and aggregate reports to confirm legitimate sending sources pass before enforcing DMARC.
Check DKIM and DMARC in received headers
Once DKIM is enabled, send a message to a mailbox you can inspect. Read the Authentication-Results header added by the receiving mailbox provider, rather than trusting a sender-supplied copy. 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 alignment 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: A passing SPF result with the required Mail From domain match is an alternative DMARC path, not a requirement when DKIM already qualifies.
- 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.
A message can have multiple DKIM signatures. DMARC can pass when one valid signature has the required domain match, even if another signature uses the provider's domain or fails validation.
Common DKIM subdomain mistakes
Most DKIM subdomain problems come from mixing up identity and DNS location, especially when a provider applies account defaults. The fix has to be applied to the exact signing 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 name: Entering a full hostname in a DNS interface that appends the zone can publish the selector under the domain twice.
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.
Monitor subdomain signing with Suped
Suped is our DMARC reporting and email authentication platform. It connects aggregate report data to sending sources, so teams can verify whether each source signs with the expected root domain or subdomain. This is useful when several email platforms and internal systems send with different subdomains.
With DMARC monitoring in Suped, teams can see which source is signing with each domain, whether DKIM or SPF is carrying the DMARC pass, and where a selector/CNAME update or provider-side signing change is needed.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Use source-level results to find new authentication failures after a provider change or selector rotation. Multi-domain views also keep subdomain signing issues grouped with the domain and team responsible for fixing them.
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 view
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 view
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
Frequently asked questions
Yes. Publish the DKIM selector under the signing domain, such as selector._domainkey.email.example.com. The provider will give either a CNAME target or a TXT value.
A valid signature using d=example.com satisfies relaxed DKIM alignment for email.example.com when both domains have the same organizational domain. It fails strict DKIM alignment because the domains are not an exact match. DKIM validation itself is separate from this domain comparison.
DKIM uses the signing domain in the DKIM-Signature header. DMARC compares that signing domain with the Header From domain. SPF uses Mail From.
No. A DKIM key for example.com does not automatically apply to email.example.com. Each signing domain needs its own selector record.
Yes. Separate selectors make provider changes and key rotation safer, and they make DMARC reports easier to interpret when more than one system sends mail. The same selector label can be used under different signing domains because each creates a different DNS hostname.
Not necessarily. If no subdomain record is published, DMARC policy discovery can find an applicable parent policy. Publish at _dmarc.email.example.com when that subdomain needs its own policy settings. Publishing a DKIM selector does not create a DMARC record.
