Do I need separate DKIM records for my root domain and subdomains?

Yes, DKIM records are not inherited. Each domain or subdomain that sends email and needs DKIM authentication must have its own specific DKIM record published in its respective DNS zone. The domain specified in the DKIM signature's "d=" tag must match the domain or subdomain where the public key is hosted.

What is a DKIM selector and why is it important for subdomains?

A DKIM selector is a unique identifier (e.g., "s1") that forms part of the DKIM record's DNS name (e.g., s1._domainkey.subdomain.yourdomain.com ). It allows you to have multiple DKIM keys for a single domain or subdomain, often used when you send email through different services, each with its own key. This is crucial for maintaining distinct authentication for various sending sources.

If I send marketing emails from a subdomain, where should the DKIM record be?

If your marketing emails use a From address from a subdomain (e.g., marketing@mail.yourdomain.com ), the DKIM record for these emails should be published for the mail.yourdomain.com subdomain. This ensures that the DKIM signature aligns with the sending domain, which is essential for DMARC pass and optimal deliverability.

How can I check if my DKIM record is correctly published for a subdomain?

You can verify your DKIM record's publication and correctness using online DKIM checker tools. Simply enter your domain or subdomain and the DKIM selector, and the tool will perform a lookup to confirm the record's existence and validity. Additionally, monitoring your DMARC reports, especially with a tool like Suped, will show you detailed authentication results, including DKIM pass or fail status for all your sending domains.

Is a DKIM record published in the root domain or subdomain? - DKIM - Email authentication - Knowledge base

Two servers representing root and subdomain, with mail and a key, illustrating DKIM record placement

When delving into email authentication, one of the most common questions we encounter is about the proper placement of a DKIM record. Specifically, should a DKIM record be published in the root domain or a subdomain? This isn't just a technical detail, it fundamentally impacts how your emails are authenticated and perceived by receiving mail servers.

The distinction between root and subdomain DKIM publication is crucial for maintaining a strong sender reputation and ensuring your legitimate emails reach the inbox. Misconfiguration can lead to DMARC failures, increased spam scores, and ultimately, poor deliverability. We often see domains struggling with authentication because of a misunderstanding here.

This guide will clarify the nuances of DKIM record placement, explaining how DKIM works in relation to different parts of your domain, and why proper configuration is key to effective email security and deliverability.

Understanding DKIM records

DKIM, or DomainKeys Identified Mail, is an email authentication method that uses cryptographic signatures to verify that an email was indeed sent by the authorized owner of that domain and that the message content hasn't been tampered with in transit. It's a critical component of a robust email security posture, working hand-in-hand with SPF and DMARC to combat email spoofing and phishing.

The core of DKIM involves a pair of cryptographic keys, a private key and a public key. The private key resides on the sending mail server and is used to digitally sign outgoing emails. The public key is published in your domain's DNS as a TXT record. Receiving mail servers retrieve this public key to verify the email's signature against the signed header in the email.

Key role of DKIM

Authentication: Confirms the email originated from the declared sender's domain.
Integrity: Ensures the email content hasn't been altered since it was signed.
Deliverability: Improves trust signals for receiving servers, boosting inbox placement.

The public key is stored in a special kind of DNS record, known as a DNS DKIM record. This record is always a TXT record and follows a specific naming convention: selector._domainkey.yourdomain.com. The 'selector' is a unique name chosen by the sender or email service provider, allowing multiple DKIM keys for a single domain.

DKIM and subdomains

This is where the root domain versus subdomain question becomes pertinent. DKIM records are not inherited. A DKIM record published for example.com will not automatically apply to mail.example.com or newsletter.example.com. Each domain or subdomain that sends email and needs DKIM authentication must have its own DKIM record published at the appropriate DNS level.

The specific domain where your DKIM record is published is determined by the "d=" tag in the DKIM signature, which specifies the signing domain identifier (SDID). This SDID must match the domain or subdomain where the public key is published. We often get asked, "Can DKIM be set up on a subdomain?" The answer is yes, absolutely. If you send emails from a subdomain, you will typically publish the DKIM record for that specific subdomain.

Root domain DKIM

A DKIM record published directly on your root domain (e.g., yourdomain.com) is used to authenticate emails where the From address also uses the root domain. This is common for general corporate emails or primary marketing communications.

Example: Email from info@yourdomain.com.
Record name: selector._domainkey.yourdomain.com

Subdomain DKIM

If you send emails from a subdomain (e.g., for transactional emails, marketing, or support), the DKIM record should be published for that specific subdomain. This allows for granular control and better isolation of sender reputation.

Example: Email from support@mail.yourdomain.com.
Record name: selector._domainkey.mail.yourdomain.com

This granular control is particularly beneficial when using third-party email services (ESPs). Many ESPs will instruct you to add DKIM records to a specific subdomain they provide, such as s1._domainkey.email.yourdomain.com. This ensures that only emails sent through that specific service are signed with their DKIM keys, preventing potential conflicts or misuse.

Setting up DKIM records

Setting up DKIM records involves generating the public and private key pair, typically provided by your email service provider. Once you have the public key, you'll need to publish it as a TXT record in your DNS. The exact location in your DNS depends on whether you're authenticating emails from your root domain or a specific subdomain. For organizations using third-party services, it's common to set up SPF and DKIM records for new subdomains.

Example DKIM TXT record for a subdomainDNS

Host: selector1._domainkey.mail.yourdomain.com
Type: TXT
Value: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGMUaL1cR6x...QIDAQAB"

The most important part is that the "Host" or "Name" field in your DNS record matches the format selector._domainkey.subdomain.yourdomain.com or selector._domainkey.yourdomain.com, depending on your sending configuration. This defines what DNS record type is used for DKIM. After publishing, it's essential to verify the record's propagation and correctness using a DKIM checker or through your DMARC reports.

Many email providers, like Microsoft, offer guidance on how to configure DKIM for their services. Always consult their documentation or your ESP's instructions to ensure you're setting up the DKIM record correctly for your specific sending scenario.

Why this matters for email deliverability

Email envelopes showing successful and failed authentication checks

The proper placement and configuration of your DKIM records directly influence your email deliverability. When a DKIM record is correctly set up for the domain or subdomain from which you're sending, your emails are more likely to pass authentication checks, leading to higher inbox placement rates. Conversely, a missing or misconfigured DKIM record can cause your emails to fail authentication, potentially landing them in spam folders or being rejected outright.

This is especially critical for DMARC alignment. DMARC relies on both SPF and DKIM to authenticate emails. If your DKIM signature's domain (d= tag) does not align with your From header domain, your DMARC check will fail, regardless of whether a valid DKIM signature exists. We help many businesses monitor and improve their DMARC compliance, ensuring that DKIM (and SPF) are correctly aligned to pass DMARC policies.

To effectively manage your email authentication and ensure proper DKIM setup, we recommend utilizing a robust DMARC monitoring solution. Suped provides AI-powered recommendations to help you fix issues and strengthen your policy, real-time alerts, and a unified platform for DKIM, SPF, and DMARC. Our platform also includes features like SPF flattening and an MSP dashboard for managing multiple domains efficiently.

Suped advantage for DKIM management

AI-Powered Recommendations: Actionable insights to optimize DKIM and DMARC settings.
Real-Time Alerts: Get notified immediately of any DKIM authentication failures.
Unified Platform: Monitor DKIM alongside SPF, DMARC, and blocklist data.
MSP Dashboard: Manage DKIM for multiple clients from a single, intuitive interface.

Ensuring proper DKIM implementation

In summary, a DKIM record is published at the specific domain or subdomain from which emails are being sent and signed. There is no inheritance, meaning a root domain's DKIM record will not automatically apply to its subdomains, and vice versa. Each sending identity requires its own properly configured DKIM record in the corresponding DNS zone.

Correct DKIM implementation is a non-negotiable step for modern email security and deliverability. It validates your sending authority, protects your brand from spoofing, and significantly increases the likelihood of your emails reaching the intended inboxes. Always ensure your DKIM setup aligns with your email sending architecture.

Proactive monitoring of your DKIM status through DMARC reports is essential. Tools like Suped can provide the visibility and actionable insights needed to ensure your DKIM records are always correctly configured and performing optimally, protecting your email ecosystem.