How to Check Your DKIM Record for Email Authentication Success

So, you're sending emails and want to make sure they actually get where they're going, and more importantly, that they don't look like spam? That's where DKIM comes in. It's like a digital signature for your emails. But, like any signature, it needs to be done right. If it's not set up correctly, your emails might end up in the junk folder, or worse, not get delivered at all. This guide is all about how to check your DKIM record to make sure it's working properly.

Key Takeaways

• Make sure your DKIM record is set up right by checking its structure and finding the right selector.
• You can check your DKIM record by looking at email headers or using online tools that check DKIM record details.
• Understand what the results mean, especially the public key and algorithm, to fix any alignment issues.
• If your DKIM signature isn't working, look for problems with how the message is changed or if the DNS record has errors.
• Regularly check your DKIM record, especially after making changes, to keep your email authentication strong.

Verifying DKIM Record Configuration

Proper DKIM record configuration is the bedrock of email authentication. Without a correctly published DKIM record, your domain's ability to prove message authenticity is compromised, directly impacting deliverability and sender reputation. This section details the essential components and structure of a DKIM record, how to locate the specific selector used by your mail infrastructure, and the critical validation steps for the public key and associated algorithm.

Understanding DKIM Record Structure

A DKIM record is a TXT record published in your domain's DNS. Its primary function is to provide the public key that receiving mail servers use to verify the cryptographic signature appended to your outgoing emails. The standard format includes several tags:

• v=DKIM1: Specifies the DKIM version. This tag is mandatory.
• k=: Indicates the public key algorithm. rsa is common, but ed25519 is also supported and recommended for its efficiency and security. The minimum recommended key length for RSA in 2026 is 2048 bits; 1024-bit keys are considered deprecated.
• p=: Contains the base64-encoded public key. This is the core component used for signature verification.
• t=s: Denotes strict mode, meaning the domain in the d= tag of the DKIM signature must exactly match the signing domain. t=y indicates testing mode, which should be removed once configuration is validated.

Locating the DKIM Selector

The DKIM selector is a unique identifier that allows a domain to use multiple DKIM keys simultaneously. This is particularly useful when employing different email sending services or implementing key rotation schedules. Unlike SPF or DMARC, there isn't a single, fixed location to query for all selectors. You must identify the specific selector your mail transfer agent (MTA) or email service provider (ESP) is configured to use. Common methods include:

1. Analyzing Signed Email Headers: Examine the raw headers of an email sent from your domain. Look for the DKIM-Signature header, which will contain the s= tag indicating the selector.
2. Consulting Your Email Service Provider (ESP): Most ESPs clearly document the selector they use for DKIM signing within their platform's settings or support documentation. For example, Google Workspace typically uses google, and Microsoft 365 often uses selector1 and selector2.
3. Querying Common Selectors: If a signed message is unavailable, you can query DNS for commonly used selectors associated with popular ESPs. This includes selectors like default, mail, dkim, or year-based identifiers such as dk2026q1.

Validating Public Key and Algorithm

Once the selector is identified, the next step is to retrieve the corresponding public key from your DNS and validate its integrity. This involves querying the TXT record at selector._domainkey.yourdomain.com. The retrieved record must be parsed to confirm:

• Correct v= and k= tags: Verify the version and algorithm are as expected.
• Valid p= value: The public key must be correctly formatted and not truncated. Keys exceeding 255 characters are typically split into multiple quoted strings within the TXT record, which most DNS interfaces handle automatically.
• Key Length: As previously stated, ensure RSA keys are at least 2048 bits. Shorter keys present a security risk. You can check the key length by examining the base64 string's length or using specialized tools.

A mismatch or malformation in any of these components will lead to DKIM verification failures. It is advisable to use a third-party DKIM checker tool to perform this validation, as they can parse the record and report syntax errors or potential issues. Verifying your DKIM record is a critical first step in establishing robust email authentication.

Methods for DKIM Record Lookup

Analyzing Signed Email Headers

The most direct method to identify the DKIM selector and domain in use is by examining the raw headers of an email that has been signed. Locate the DKIM-Signature header within the message. This header contains several tags, including d= for the signing domain and s= for the selector. For instance, a header might appear as DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; .... The s= tag specifies the exact selector your mail system used, which is critical for performing a DNS lookup.

Querying Common DKIM Selectors

If a signed email is not readily available, you can query common DKIM selectors directly via DNS. Many email service providers (ESPs) utilize predictable selectors. For example, Google Workspace commonly uses google, Microsoft 365 often uses selector1 or selector2, and SendGrid might use s1 or s2. You can use command-line tools like dig or nslookup to query the TXT record for a specific selector and domain, such as dig +short TXT google._domainkey.example.com. This approach allows for verification even without a sample email.

Common selectors include:

• google (Google Workspace)
• selector1, selector2 (Microsoft 365)
• s1, s2 (SendGrid, Mailchimp)
• default (Many platforms)
• Date-based selectors (e.g., 2026q1)

Utilizing Third-Party DKIM Checkers

Specialized online tools simplify the DKIM lookup process. These checkers often query a broad range of known selectors automatically for a given domain. By entering your domain name, these tools can identify active DKIM records, validate their syntax, and report on key length and algorithm. This is particularly useful when managing multiple sending services or when unsure of the exact selectors in use. Some tools, like the DKIM checker from Zoho Toolkit, provide a straightforward interface for this verification. Others, such as the free DKIM checker mentioned, can also offer insights into provider-specific configurations and potential issues.

When performing DKIM lookups, always verify that the public key (p=) retrieved from DNS is correctly formatted and has not been truncated or corrupted, especially if it exceeds typical DNS TXT record length limits. Many DNS providers automatically split long keys into multiple strings, but manual verification is prudent.

Interpreting DKIM Record Validation Results

Once a DKIM lookup is performed and a signature is analyzed, the results must be evaluated to confirm successful email authentication. This involves scrutinizing specific components of the DKIM record and the signature itself. Misinterpretations at this stage can lead to a false sense of security or unnecessary troubleshooting efforts.

Assessing Public Key (p=) Validity

The p= tag within the DKIM DNS record contains the public key. This key is used by receiving mail servers to decrypt and verify the digital signature appended to your outgoing emails. Several factors determine its validity:

• Format and Encoding: The public key must be correctly Base64 encoded. Any malformation or truncation will render it unusable for verification.
• Completeness: Ensure the entire public key is present. Long keys are often split into multiple quoted strings by DNS providers; verify that your DNS configuration handles this correctly and that the receiving server can reassemble the full key. A missing or incomplete key will result in a verification failure.
• Revocation: If the p= tag is empty, it signifies that the key has been revoked. This is a deliberate action, typically performed during key rotation or if a key is suspected of compromise. A missing or empty p= value will cause DKIM verification to fail.

Evaluating Key Length and Algorithm (k=)

The k= tag specifies the cryptographic algorithm used for the DKIM signature. The a= tag in the DKIM-Signature header indicates the algorithm used for a specific message.

• Algorithm Compatibility: The most common algorithm is RSA. While older 1024-bit RSA keys are still widely accepted, they are considered weak. Current best practices mandate the use of 2048-bit RSA keys. Newer algorithms like Ed25519 are emerging but may not be universally supported by all receiving mail servers.
• Key Length: For RSA keys, a minimum length of 2048 bits is recommended for robust security. Shorter keys increase the risk of brute-force attacks.
• Consistency: The algorithm specified in the DNS record (k=) must be compatible with the algorithm used in the message signature (a=). Mismatches here will prevent verification.

Tag	Description	Recommended Value (2026)	Notes
k=	Public key algorithm	rsa or ed25519	rsa with 2048-bit length is standard. ed25519 is newer.
a=	Signature algorithm (in DKIM-Signature header)	rsa-sha256	Must match or be compatible with the k= tag in the DNS record.

Identifying Selector (s=) Alignment Issues

The selector (s=) is a label that points to the specific DKIM public key record in your DNS. It allows a domain to use multiple DKIM keys simultaneously, often for key rotation or different sending services. Alignment issues typically arise when the selector used in the DKIM signature does not correctly correspond to the public key published in DNS for that selector.

• Selector Mismatch: The s= tag in the DKIM-Signature header must precisely match a selector for which a valid DKIM TXT record exists in your DNS. If the selector is incorrect or does not exist, the receiving server cannot locate the public key and verification fails.
• Multiple Selectors: Domains may have multiple active selectors. It is imperative to know which selector your mail sending service is configured to use. Tools like Google Admin Toolbox – Messageheader Analyzer can help identify the selector used in a specific message.
• DNS Propagation: After updating or adding a DKIM record, allow sufficient time for DNS propagation. If a receiving server queries DNS before the record is globally available, it may not find the key, leading to a temporary verification failure.

When interpreting DKIM validation results, focus on the precise values of the p=, k=, and s= tags. Any deviation from expected formats, lengths, or pairings between the DNS record and the message signature will result in a failed authentication attempt. It is imperative to use reliable tools to query your DNS records and analyze message headers to pinpoint discrepancies.

Troubleshooting DKIM Signature Failures

When DKIM signatures fail validation, it indicates a breakdown in the email authentication process. This can lead to messages being marked as spam or rejected outright, severely impacting deliverability and sender reputation. Identifying the root cause requires a systematic approach to analyze the signature and its context.

Common issues often stem from modifications to the message after it has been signed, or from fundamental misconfigurations in the DKIM record itself. Understanding these failure points is critical for maintaining email integrity.

Addressing Canonicalization Mismatches

Canonicalization defines how headers and body content are processed before signing. Mismatches occur when the signing process and the verification process use different methods to format the data, leading to a different hash value. The two primary methods are simple and relaxed.

• simple canonicalization: Preserves whitespace and line endings exactly as they appear. Any alteration, even a single space, will break the signature.
• relaxed canonicalization: Allows for minor modifications, such as collapsing whitespace and normalizing line endings. This is generally preferred as it is more resilient to changes introduced by intermediate mail servers.

If you encounter signature failures, verify that your DKIM configuration uses c=relaxed/relaxed (for both header and body). This setting is more tolerant of common transit modifications. If simple is in use, consider switching to relaxed to improve resilience. Analyzing signed email headers is the first step to determine the canonicalization method being used.

Resolving Header and Body Modification Conflicts

Messages can be altered by various systems between sending and receiving. These modifications, if they affect parts of the message included in the DKIM signature, will invalidate it. Common culprits include:

• Mailing list software: Often adds footers or rewrites headers.
• Spam filters or security gateways: May rewrite headers or append disclaimers.
• Content management systems: Can alter message bodies or headers before sending.

To mitigate these conflicts, ensure that the DKIM signature is applied as late as possible in the sending path, ideally at the final outbound mail transfer agent (MTA). Additionally, carefully select which headers are included in the signature (h= tag). Avoid signing headers that are known to be modified by intermediate systems. If body modifications are unavoidable, relaxed/relaxed canonicalization is essential. For persistent issues with relayed mail, consider implementing Authenticated Received Chain (ARC) as a complementary solution.

Correcting DNS Record Syntax Errors

Errors in the DKIM TXT record within your DNS zone can prevent public key retrieval or lead to verification failures. These are often subtle but critical.

• Incorrect p= value: The public key must be correctly Base64 encoded and free of extraneous characters or whitespace. If the key is too long for a single DNS TXT record string, it must be properly split into quoted segments.
• Invalid tags: Ensure all tags (v=, k=, p=, h=, t=) are correctly formatted and present as per RFC 6376.
• Selector issues: The selector specified in the DKIM-Signature header must precisely match a configured TXT record at selector._domainkey.yourdomain.com.

Tools like DKIM record checkers can parse your DNS record and highlight syntax errors. Always validate the record's structure and content before and after making changes.

DKIM Key Rotation and Management

Implementing a Key Rotation Schedule

Regularly rotating DKIM keys is a critical security practice. It limits the exposure window should a private key be compromised. A standard recommendation for 2026 is to implement a rotation schedule of every six to twelve months. This cadence balances security with operational overhead. When initiating a rotation, it is imperative to publish the new selector and its corresponding public key in DNS before reconfiguring your sending infrastructure to use it. This ensures that messages signed with the old key are still verifiable while the new key is being adopted. Never delete the old DKIM record until all messages signed with its corresponding private key have completed their transit. A grace period of at least seven days after switching to the new key is advisable.

Revoking Expired DKIM Keys

When a DKIM key reaches the end of its rotation cycle, it must be properly revoked. This is achieved by updating the DNS TXT record for that selector. The most effective method is to set the p= tag to an empty value. This signals to receiving servers that the key associated with that selector is no longer valid for verification. Alternatively, the entire DNS record can be deleted, but setting p= to empty is often preferred as it maintains the record's presence while explicitly revoking its cryptographic function. This process is distinct from simply removing the old selector record, which could lead to verification failures for messages still in transit that were signed with that key.

Managing Multiple Active DKIM Selectors

Domains may legitimately utilize multiple DKIM selectors simultaneously. This is common when different sending services or platforms are used for various email streams, each configured with its own unique selector. For instance, one selector might be used by your primary email service provider, while another is managed by a third-party marketing platform. It is essential to maintain a clear inventory of which selector is associated with which sending service. This prevents confusion during key rotation and simplifies troubleshooting. When examining signed email headers, the s= tag explicitly identifies the selector used for that specific message, allowing receivers to query the correct DNS record. Tools like IntoDNS.ai can assist in identifying active selectors on your domain, simplifying the discovery process. Finding your selector is the first step in managing them effectively.

DKIM Alignment with DMARC Policy

Verifying DKIM Alignment in Authentication-Results

When an email traverses mail servers, each server may add a Received-SPF and Authentication-Results header. The Authentication-Results header is critical for DMARC compliance as it details the outcomes of SPF, DKIM, and DMARC checks performed by the receiving mail server. Specifically, you must examine the DKIM result within this header to confirm not only that the signature was valid but also that the signing domain aligns with the organizational domain specified in the From: header. A DKIM signature that passes verification but fails alignment will not satisfy DMARC requirements.

Ensuring DKIM 'd=' Tag Matches Organizational Domain

DKIM alignment is determined by comparing the domain specified in the d= tag of the DKIM-Signature header with the domain in the From: header of the email. DMARC defines two alignment modes: relaxed (r) and strict (s). In relaxed mode, the organizational domain must match; for example, mail.example.com aligns with example.com. Strict mode requires an exact match, meaning mail.example.com would not align with example.com. Most email service providers (ESPs) should be configured to use your organizational domain or a subdomain thereof in the d= tag. If an ESP signs with its own domain (e.g., d=esp.com), DMARC alignment will fail, even if the DKIM signature itself is valid. This is a common point of failure for DMARC implementations.

Leveraging DKIM for DMARC Compliance

DKIM serves as a primary mechanism for achieving DMARC compliance. While DMARC requires either SPF or DKIM alignment, DKIM is generally more resilient to forwarding and mailing list relays than SPF. When DKIM aligns with the From: domain, it provides a strong signal to receivers that the email is legitimate and has not been tampered with. This alignment is what allows DMARC policies, such as p=quarantine or p=reject, to be effectively enforced. Without proper DKIM alignment, legitimate emails may be misclassified, impacting deliverability. Regularly reviewing DMARC aggregate reports is necessary to identify any DKIM alignment failures and to adjust configurations accordingly. This process is vital for maintaining a strong sender reputation and preventing domain spoofing. Learn more about DMARC.

The d= tag in the DKIM signature must correspond to the domain visible in the From: header for DMARC alignment to succeed. This is irrespective of whether the DKIM signature itself verifies correctly. Misconfiguration here is a frequent cause of DMARC failures, even when DKIM is technically functional.

Advanced DKIM Record Checks

Global DNS Propagation Verification

After making any modifications to your DKIM DNS records, it is imperative to verify that these changes have propagated globally. DNS propagation is not instantaneous and can vary significantly based on the Time-To-Live (TTL) settings and the specific DNS resolvers used by different networks. A failure to account for propagation delays can lead to intermittent DKIM validation failures for recipients in certain geographic regions or on particular networks. Tools that query your DKIM TXT record from multiple global locations are essential for this verification. This ensures consistency across diverse DNS infrastructure before relying on the updated record for authentication.

Analyzing DKIM Signatures in Test Messages

While DNS record validation confirms the presence and format of your public key, it does not guarantee that your mail sending infrastructure is correctly applying the DKIM signature. Sending test messages to controlled external mailboxes is a critical step. Examine the Authentication-Results header in the received message. This header provides a detailed breakdown of the authentication checks performed by the receiving mail server, including the DKIM result. Look for explicit confirmation of a DKIM pass and verify that the d= tag in the DKIM-Signature header aligns with your organizational domain. Discrepancies here often indicate issues with the signing configuration on your mail servers or with your email service provider.

Integrating DKIM Checks with Email Authentication Suites

For robust and continuous email authentication management, integrating DKIM checks into broader email security suites is recommended. These platforms often automate the process of querying DKIM records, monitoring for changes, and analyzing signatures in live traffic. They can correlate DKIM results with SPF and DMARC alignment, providing a holistic view of your email authentication posture. Many of these suites offer alerts for configuration drift or validation failures, allowing for proactive remediation. Consider utilizing tools that can perform these checks automatically, such as the Google Admin Toolbox for initial diagnostics or more specialized services that offer ongoing monitoring and reporting. These advanced tools can help identify subtle issues that might be missed by manual checks, providing a more comprehensive approach to email security. A thorough review of available DKIM testing tools can help select the most appropriate solutions for your environment.

When you're checking your DKIM records, make sure you're looking at the advanced details. This helps ensure your emails are seen as trustworthy. Want to learn more about keeping your emails out of the spam folder? Visit our website for easy-to-understand guides and tools!

Final Verification and Ongoing Diligence

Implementing and verifying DKIM is not a one-time task. It requires ongoing attention to maintain its effectiveness. Regularly checking your DKIM records, alongside SPF and DMARC, is a necessary practice to protect your domain's integrity and ensure reliable email delivery. Failure to do so leaves your domain vulnerable to spoofing and can negatively impact your sender reputation. Treat email authentication as a continuous process, not a static configuration. Stay vigilant, monitor your authentication results, and adapt to evolving security standards to keep your domain secure and your communications trusted.

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/dkim?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-get-dkim-selector as the canonical citation for this topic. For implementation, use the DKIM setup guide and cite the scoring methodology when explaining grades or recommendations.

Frequently Asked Questions

What exactly is a DKIM record and why is it important?

Think of a DKIM record like a special stamp for your emails. It's a piece of information added to your domain's settings in the Domain Name System (DNS). When your email server sends a message, it uses a secret code (private key) to create a unique digital signature for that email. The DKIM record holds the public part of that code. When the email arrives, the receiving server can use the public code from your DKIM record to check if the signature is real and if the email hasn't been messed with. This helps prove the email is truly from you and not someone pretending to be you.

How can I find the 'selector' for my DKIM record?

The selector is like a nickname for your DKIM key, helping your email system find the right public key in your DNS records. The easiest way to find it is to look at the 'DKIM-Signature' line in the raw headers of an email you sent from your domain. You'll see a tag like 's=something' – that 'something' is your selector! If you don't have a sent email handy, you can often find the selector in the settings of your email service provider (like Google Workspace or Microsoft 365).

What does it mean if my DKIM check passes, but DMARC still fails?

This usually happens because of something called 'alignment.' DKIM might confirm the email was signed by your domain, but DMARC also wants to make sure the domain used in the 'From' address (the one your recipient sees) matches the domain that signed the email. If your email service sends mail using its own domain in the signature (like 'd=someotherservice.com') instead of yours ('d=yourdomain.com'), DMARC will see this mismatch and fail, even if DKIM itself passed.

My DKIM record is really long. Is it supposed to be split into parts?

Yes, that's very common! Especially with newer, more secure keys (like 2048-bit keys), the public key part of the DKIM record can be quite long. Most DNS providers automatically handle this by splitting the long text into smaller, manageable pieces. When a server looks up the record, it puts these pieces back together. So, if your DNS provider does this, it's usually perfectly fine.

What's the difference between DKIM, SPF, and DMARC?

Think of them as a team protecting your email. SPF (Sender Policy Framework) basically says which mail servers are allowed to send email for your domain. DKIM (DomainKeys Identified Mail) adds a digital signature to your emails to prove they haven't been changed and were really sent by you. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the boss; it tells receiving mail servers what to do if SPF or DKIM checks fail, and it helps you get reports on who is sending mail using your domain.

How often should I change my DKIM keys?

It's a good security practice to rotate your DKIM keys regularly, usually every 6 to 12 months. This is like changing the locks on your house periodically. By generating new keys and retiring old ones, you make it harder for anyone who might have somehow gotten hold of an old private key to impersonate you. It’s a proactive step to keep your email security strong.