Can DKIM be set up on a subdomain, and which domain should be used for signing?
Matthew Whittaker
Co-founder & CTO, Suped
Published 12 Jul 2025
Updated 15 Aug 2025
8 min read
Many email senders often wonder if DomainKeys Identified Mail (DKIM) can be set up on a subdomain, and more importantly, which domain should be used for signing. This is a common point of confusion, especially when dealing with various email service providers (ESPs) or complex email infrastructures. Understanding how DKIM interacts with subdomains is crucial for maintaining good email deliverability and ensuring proper authentication.
The short answer is yes, DKIM can definitely be set up on a subdomain. In fact, it is a recommended practice for many organizations to segregate their email sending by using different subdomains for various types of email traffic, such as transactional emails, marketing newsletters, or system notifications. This segmentation helps manage sender reputation more effectively.
When you configure DKIM for a subdomain, you're essentially creating a cryptographic signature linked to that specific subdomain. This signature allows recipient mail servers to verify that an email was indeed sent by an authorized sender and that its content hasn't been tampered with in transit. This authentication is a fundamental layer of modern email security, working alongside SPF and DMARC to prevent spoofing and phishing.
DKIM works by adding a digital signature to the email header. This signature is generated using a private key kept on the sending server. The corresponding public key is then published in your domain's DNS as a TXT record. Recipient mail servers use this public key to decrypt the signature and verify the email's authenticity.
For subdomains, the process is largely the same. You'll generate a key pair for the specific subdomain you intend to send emails from, and then publish the public key in the DNS records for that subdomain. For example, if you send emails from marketing.yourdomain.com, your DKIM record would typically be located at something like selector1._domainkey.marketing.yourdomain.com. This allows for granular control over authentication for different email streams.
Some ESPs or DNS providers might offer CNAME records instead of direct TXT records for DKIM setup. This often points to a canonical name managed by the ESP, simplifying key rotation and management for you. This approach is perfectly valid and achieves the same authentication outcome. You can delve deeper into how to set up SPF and DKIM records for new subdomains when using third-party email services by checking out our dedicated guide on the topic.
The signing domain and DMARC alignment
The critical part of your question, and where much confusion lies, is about which domain should be used for signing. For DKIM to contribute to DMARC alignment (which is essential for preventing spoofing and ensuring inbox placement), the domain specified in the DKIM signature's `d=` tag must align with the Header From (or RFC 5322 From) domain.
The Header From domain is the email address that users actually see in their email client, for example, newsletter@marketing.yourdomain.com. If this is your sending domain, then your DKIM signature should ideally be for marketing.yourdomain.com or yourdomain.com. DMARC alignment requires either an exact match (strict alignment) or a match between the organizational domains (relaxed alignment). For instance, if your Header From is email.example.com and your DKIM is signed by example.com, this will align under relaxed DMARC policy. You can find more details in the DKIM with Subdomains guide.
It's important to distinguish the Header From domain from the Mail From (or RFC 5321.From, also known as the Envelope From or Return-Path) domain. While SPF authenticates the Mail From domain, DKIM's primary alignment with DMARC relies on the Header From domain. For effective email authentication, both SPF and DKIM should be set up correctly and align with the visible From address. For a deeper dive into these distinctions, explore our article When changing subdomains for email.
This table illustrates the key differences:
Header Type
Role in Email
DKIM Alignment
Header From (RFC 5322 From)
The address displayed to the recipient.
Primary domain for DKIM DMARC alignment.
Mail From (RFC 5321.From / Envelope From)
Used by mail servers for delivery and bounces.
Authenticated by SPF, not directly by DKIM for DMARC.
For the best email deliverability and DMARC compliance, it is always recommended that the DKIM signing domain aligns with the Header From domain. If you are sending from email.example.com as your Header From, you should ideally sign with email.example.com. However, signing with example.com will also achieve DMARC alignment in relaxed mode, as email.example.com is a subdomain of example.com. Most ESPs simplify this by setting the signing domain to align automatically with your sending domain.
Practical DKIM setup and selectors
Best practice: dedicated subdomains
Using dedicated subdomains for different types of email (e.g., transactional, marketing) is a best practice. This isolation helps protect your primary domain's reputation, especially if one email stream encounters deliverability issues like being placed on a blacklist or blocklist.
For example, t.yourdomain.com for transactional emails and m.yourdomain.com for marketing emails allows for distinct reputation management. You'll need to configure separate DKIM records for each, ensuring each subdomain's emails are properly signed.
The DKIM selector is a critical part of your DKIM record. It is a unique name that identifies the public key used to sign your email. You can have multiple DKIM selectors for a single domain or subdomain, which is useful if you send email through different services or need to rotate keys without downtime. For example, if you use selector1._domainkey.yourdomain.com for one service and selector2._domainkey.yourdomain.com for another, this allows for independent management. You can learn more about these names in our guide to DKIM selector names.
Here's a typical DKIM DNS record entry. The selector part is what differentiates multiple keys for the same domain or subdomain.
Troubleshooting DKIM failures and deliverability impact
Misconfigured DKIM can lead to significant email deliverability issues. If your emails fail DKIM authentication, they are more likely to be flagged as spam, rejected outright by recipient mail servers, or even land your domain on a blocklist (also known as a blacklist). This can severely impact your sender reputation and the effectiveness of your email campaigns.
A common cause for DKIM failure is an incorrect DNS record, where the public key isn't published correctly or has errors. Another reason could be if the email content or headers are modified in transit after being signed. This is why it's crucial to verify your DKIM setup after any changes.
To troubleshoot, send a test email to an email address you control and then examine the email headers. Most email clients allow you to view the raw message headers, where you can see the results of SPF, DKIM, and DMARC authentication checks. Look for entries like DKIM-Status: pass or Authentication-Results headers. If you see fail or permfail, it indicates an issue that needs to be addressed. Our guide Why is DKIM failing can provide further assistance.
Remember that DKIM works best when combined with SPF and DMARC. DMARC policies rely on both SPF and DKIM authentication to pass. If your DKIM fails, DMARC will too, potentially leading to your emails being quarantined or rejected depending on your DMARC policy. The goal is always to achieve DMARC alignment through successful SPF and DKIM authentication.
Views from the trenches
Best practices
Ensure that the DKIM signing domain (d= tag) aligns with your Header From domain to achieve DMARC compliance.
Utilize unique DKIM selectors for each third-party sending service to prevent conflicts and facilitate management.
Separate your email streams using different subdomains (e.g., marketing.example.com, transactional.example.com) for better reputation management.
Common pitfalls
Incorrectly publishing the DKIM public key in your DNS records, leading to authentication failures.
Assuming that a DKIM record on the main domain automatically signs emails from all subdomains.
Ignoring DMARC reports, which can provide critical insights into DKIM authentication failures.
Expert tips
For optimal reputation management, consider warming up new subdomains used for email sending, especially for high-volume campaigns.
Implement a DMARC policy with a 'p=none' setting initially to gather data on your DKIM performance before moving to stricter policies.
If your email service provider manages your DKIM, confirm their alignment practices and whether they sign with the Header From domain or a different domain.
Expert view
Expert from Email Geeks says: You need to DKIM sign all domains separately with their own keys for granular control and optimal authentication.
2020-06-20 - Email Geeks
Expert view
Expert from Email Geeks says: The signing domain should align with the Header From domain to ensure proper DMARC alignment, which is crucial for deliverability.
2020-06-21 - Email Geeks
Key takeaways for DKIM and subdomains
Setting up DKIM on subdomains is not only possible but often beneficial for robust email authentication and deliverability. The key takeaway is to ensure that your DKIM signing domain, which is identified by the `d=` tag in the signature, aligns with the Header From domain, the email address visible to your recipients.
This alignment, especially when combined with SPF and DMARC, creates a strong defense against email spoofing and phishing, significantly improving your chances of reaching the inbox. Always verify your setup by checking email headers and monitoring DMARC reports to catch any issues early. Properly configured DKIM across your subdomains is a cornerstone of modern email security.