What is the primary purpose of a DKIM record?

The primary purpose of a DKIM record is to verify the authenticity of an email sender and ensure that the email content has not been tampered with during transit. It uses a cryptographic signature and a public key published in DNS to achieve this.

Can DKIM records use CNAME records instead of TXT records?

While DKIM records are fundamentally TXT records, some email service providers use CNAME records. These CNAMEs point to TXT records hosted by the provider, simplifying management for their customers. However, the underlying public key is still in a TXT format.

What happens if my DKIM record is misconfigured or missing?

A misconfigured or missing DKIM record can lead to authentication failures, causing your emails to be marked as spam, rejected by recipient servers, or even impacting your domain's sending reputation. It also makes your domain more susceptible to impersonation and phishing attacks. To prevent this, implement DMARC monitoring .

How does DKIM work with SPF and DMARC?

DKIM, SPF, and DMARC work together to provide comprehensive email authentication. SPF verifies the sender's IP address, DKIM confirms the email's integrity and sender's authorization, and DMARC defines policies for how receiving servers should handle emails that fail either SPF or DKIM checks. Together, they form a powerful defense against email fraud. You can learn more about this in our simple guide to DMARC, SPF, and DKIM .

Does a DKIM record use the 'TXT' DNS record type? - DKIM - Email authentication - Knowledge base

Abstract illustration of DNS records and email security

When setting up email authentication, one of the first questions people often have is about the specific DNS record types involved. Technologies like SPF, DMARC, and DKIM all rely on DNS to publish critical information that receiving mail servers use to verify outgoing emails. Understanding which record type corresponds to each authentication method is key to proper implementation and preventing deliverability issues.

DomainKeys Identified Mail (DKIM) is a vital email authentication standard designed to detect email spoofing. It allows the recipient to check that an email claiming to come from a specific domain was indeed authorized by the owner of that domain. This verification happens by signing emails with a digital signature and then publishing a corresponding public key in your domain's DNS.

The short answer is yes, a DKIM record primarily uses the 'TXT' DNS record type. This is a common practice across various email authentication methods, including SPF and DMARC. These TXT records hold the necessary cryptographic information that mail servers need to validate the authenticity of your emails. Without it, your emails are vulnerable to being marked as spam or rejected entirely.

Understanding the DKIM TXT Record

A DNS TXT record is a simple, versatile type of Domain Name System record that allows domain administrators to store arbitrary text data in the DNS. While it sounds straightforward, the content within these records is highly structured and crucial for various internet services, including email authentication. For DKIM, the TXT record contains the public key that corresponds to the private key used to sign outgoing emails.

When an email is sent, the sending server digitally signs the email's headers and body. The receiving mail server then looks up your domain's DKIM record in the DNS, specifically searching for a TXT record that contains the public key. This public key is used to decrypt the email's signature. If the decryption is successful, and the hashes match, the email is considered authentic and untampered. If you want a more detailed look into this, check out our guide on what DNS record type is used for DKIM.

The format of a DKIM TXT record is specific and includes several tags that convey different pieces of information. The most important parts are the DKIM version and the public key itself. Here's a typical example of what a DKIM TXT record might look like in your DNS settings. You might also want to explore what DNS record type is used for DMARC to understand how it relates to DKIM.

Example DKIM TXT RecordDNS

selector1._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDj6Y9..."

Anatomy of a DKIM record

The structure of a DKIM TXT record is quite specific, involving several tags that provide essential information to receiving mail servers. These tags communicate details about the DKIM policy and the public key itself. The selector, such as selector1 in the example above, is a crucial part, allowing you to have multiple DKIM keys for a single domain, which is useful for rotating keys or using different keys for various sending services. You can find more information about this in our article about DKIM selector name examples.

The primary tags you'll encounter are v for the version, k for the key type, and most importantly, p which holds the actual public key. There are other optional tags, but these three are fundamental. Misconfigurations, such as a missing or incorrect public key, can lead to DKIM authentication failures, negatively impacting your email deliverability. For more details on these tags, Cloudflare provides a good explanation of DNS DKIM records.

Tag	Description	Example
v	Version of the DKIM record, typically DKIM1.	v=DKIM1
k	Key type used for generating the public key. Commonly RSA.	k=rsa
p	The public key itself, a long string of characters.	p=MIGfM...
s	Selector name used to locate the DKIM public key.	s=selector1

Ensuring the correct syntax and publishing the record in the correct subdomain are critical. An improperly formatted or located record is equivalent to having no record at all, leading to authentication failures. This is why how a missing DKIM DNS TXT record affects email deliverability can be quite significant for your email sending reputation.

DKIM and CNAME records: an important distinction

While most DKIM implementations rely on TXT records, there's a notable exception. Some providers, particularly those managing email for large organizations, sometimes use CNAME records that point to their own DKIM TXT records. This approach simplifies DKIM management for their customers, as the provider can rotate keys without requiring each customer to update their DNS. However, this is not the standard for direct DKIM setup and is usually a specific provider feature.

Standard DKIM with TXT records

Self-managed: You directly publish the public key in a TXT record for your domain.
Full control: You manage key rotation and policy changes yourself.
Direct verification: Receiving servers directly query your domain for the public key.

DKIM with CNAME records (Provider managed)

Provider managed: Your CNAME record points to a DKIM TXT record hosted by your email service provider (e.g., Microsoft). Read more about Microsoft DKIM configuration.
Simplified management: The provider handles key rotation and updates automatically.
Indirect verification: Receiving servers resolve the CNAME to the provider's TXT record.

Comparison of TXT and CNAME DKIM record paths

While CNAMEs can simplify things, it's essential to understand that the underlying public key information is still stored in a TXT record, just not directly on your domain. This distinction is important for troubleshooting and ensuring proper setup, as a misconfigured CNAME can prevent DKIM from functioning correctly, just as a direct TXT record misconfiguration would.

The importance of proper DKIM configuration

Correctly configuring your DKIM TXT record (or CNAME if applicable) is paramount for several reasons. Firstly, it significantly boosts your email deliverability. Mail servers, especially major ones like Gmail, Outlook, and Yahoo, increasingly prioritize authenticated email. Without DKIM, your emails are more likely to land in spam folders or be rejected outright. Postmark provides an excellent guide on what DKIM is.

Secondly, DKIM protects your domain's reputation and your recipients from phishing and spoofing attacks. By ensuring that only authorized senders can send emails on behalf of your domain, you reduce the risk of malicious actors impersonating your brand. This directly impacts trust and engagement with your audience.

Best practices for DKIM records

Use strong keys: Always use 2048-bit RSA keys for better security.
Regular rotation: Rotate your DKIM keys periodically, typically every 6-12 months.
Monitor reports: Use a DMARC monitoring tool to track your DKIM authentication results.
Alignment with DMARC: Ensure your DKIM domain aligns with your 'From' domain for DMARC pass.

Finally, DKIM works in conjunction with SPF and DMARC to form a robust email authentication framework. While DKIM verifies the email's integrity and sender's authorization, SPF verifies the sending IP address, and DMARC ties them together, instructing receiving servers on how to handle emails that fail authentication. Together, these protocols provide comprehensive protection against email fraud.

Final thoughts on DKIM DNS records

In conclusion, DKIM records primarily utilize the 'TXT' DNS record type to publish public cryptographic keys. These keys are fundamental for email authentication, enabling recipient servers to verify the authenticity and integrity of incoming messages. Proper configuration of these TXT records is essential for maintaining strong email deliverability and protecting your domain from spoofing and phishing attacks.

For complete email security, combining DKIM with SPF and DMARC is crucial. Monitoring your DMARC reports, which detail DKIM authentication results, is the best way to ensure your configuration is effective and identify any potential issues. Suped provides AI-powered recommendations, real-time alerts, and a unified platform for DMARC, SPF, and DKIM monitoring, helping you easily manage and secure your email ecosystem. Suped also offers an extremely generous free plan for DMARC monitoring, making advanced email security accessible to everyone.