How to Check Your DKIM Record: A Step-by-Step Guide

Ever get an email that just feels a little... off? Like maybe it's not from who it says it's from? Or maybe you're sending out emails and they're landing in the spam folder more often than you'd like. A lot of this comes down to how well your domain's email is set up to prove it's actually you sending those messages. One of the big players in this is DKIM. It's a way to digitally sign your emails. This guide will walk you through how to check your DKIM record, which is pretty important for making sure your emails are seen as legit.

Key Takeaways

• Finding your DKIM selector is the first step, usually by looking at a signed email's headers or by trying common selectors for your email provider.
• You can check your DKIM DNS record using command-line tools like `dig` or `nslookup`, paying attention to the record's structure and tags like `v=DKIM1`, `k=rsa`, and `p=`.
• Troubleshooting DKIM failures often involves checking for accidental changes to email content or headers after signing, or issues with multiple TXT records at the same selector.
• Managing DKIM keys includes secure rotation practices and understanding the specifications for key length and algorithms to maintain security.
• Using third-party tools like online DKIM checkers can automate the process of verifying your DKIM setup and identifying potential problems.

Locating Your DKIM Selector

The DKIM selector is a critical component for email authentication. It functions as a pointer, directing the receiving mail server to the correct public key within your domain's DNS records for signature verification. Without identifying the active selector(s), validating DKIM signatures on actual messages becomes impossible. This section details methods for discovering these selectors.

Interpreting DKIM-Signature Headers

The most direct method to identify an active DKIM selector is by examining the DKIM-Signature header of an email that has been signed by your domain. This header is appended by the sending mail server and contains vital information, including the selector used for signing.

• Locate a recently sent email from your domain. Ideally, this should be a message sent through your primary mail infrastructure or a known sending service.
• View the raw source or full headers of this email. The method varies by email client (e.g., "Show original" in Gmail, "View message source" in Outlook).
• Search for the DKIM-Signature: header. Within this header, find the s= tag. The value immediately following s= is the DKIM selector.

For example, a DKIM-Signature header might appear as:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=dkim202601; t=1704902432; ...

In this instance, dkim202601 is the selector. This value is essential for querying the corresponding public key in your DNS records.

Querying Common DKIM Selectors

If you do not have a signed email readily available, or if you suspect multiple selectors are in use, you can query common selector patterns. Many email service providers (ESPs) adhere to predictable naming conventions for their DKIM selectors.

Common selectors include:

• default (frequently used by various platforms)
• google (for Google Workspace)
• selector1, selector2 (often used by Microsoft 365)
• s1, s2 (common with services like Mailchimp)
• Date-based selectors (e.g., 2026q2, jan2026)

To query these, you will use DNS lookup tools. For instance, using dig on a Linux or macOS system:

dig +short TXT google._domainkey.yourdomain.com
dig +short TXT selector1._domainkey.yourdomain.com
dig +short TXT s1._domainkey.yourdomain.com

Replace yourdomain.com with your actual domain. A successful query will return the DKIM TXT record. An empty response typically indicates that the selector is not in use or does not exist for that domain. Many ESPs, such as Google Workspace and Microsoft 365, provide documentation detailing their specific selector naming conventions. You can also consult online DKIM checkers which often probe a wide range of common selectors automatically.

Enumerating DKIM Records via DNS

While DNS does not inherently support wildcard enumeration for DKIM selectors in the same way it might for other record types, you can systematically check for the presence of DKIM records. This is particularly useful when managing multiple sending services or when a provider's documentation is unclear.

• Identify potential selectors: Compile a list of selectors used by all your email sending services. This includes your primary mail server, marketing platforms, transactional email providers, and any third-party applications that send email on your behalf.
• Construct DNS query names: For each selector, construct the full DNS query name. This follows the pattern: <selector>._domainkey.<yourdomain.com>.
• Perform DNS lookups: Use command-line tools like dig or nslookup, or an online DNS lookup tool, to query for TXT records at each constructed name.

For example, if you use Google Workspace (selector google) and SendGrid (selector s1), you would query:

dig +short TXT google._domainkey.yourdomain.com
dig +short TXT s1._domainkey.yourdomain.com

A response indicating a valid TXT record confirms the presence of a DKIM record for that selector. This process helps identify all active DKIM keys associated with your domain. It is important to note that some services, like Microsoft 365, may use CNAME records pointing to their own infrastructure, which you would also need to resolve to find the ultimate DKIM record. Understanding SPF records is also part of a complete email authentication strategy.

Validating DKIM DNS Records

DomainKeys Identified Mail (DKIM) strengthens the legitimacy of outbound email. For DKIM to function, every domain must publish a DNS TXT record under the selector namespace. This segment details how to review, parse, and confirm the health of your DKIM DNS records.

Understanding DKIM Record Structure

A DKIM DNS record is a TXT record located at [selector]._domainkey.[domain]. Its value contains a series of tag/value pairs—each meaningful for signature validation or policy signaling.

A typical, abbreviated DKIM DNS record:

Tag	Meaning	Example Value
v	DKIM version	DKIM1
k	Key type	rsa
t	Flags (s=strict, y=test)	s
p	Public key (base64)	MIIBIjANBgkqhkiG9w...

• v=DKIM1 always comes first, marking this as a DKIM record.
• The p= value is the actual public key—without it, validation is impossible.
• Split keys (long p=) across multiple quoted strings as needed. DNS UIs normally handle this automatically.

Always confirm only one TXT record exists at each selector. Multiple TXT records break DKIM for most receivers.

Utilizing Command-Line Tools for DNS Queries

DKIM records are public, so basic dig or nslookup queries are the primary method for checking setup. Specific commands:

1. To look up a selector:
   • dig +short TXT s1._domainkey.example.com
   • nslookup -type=TXT s1._domainkey.example.com
2. Confirm the TXT record starts with v=DKIM1 and that the p= key is present and at least 2048 bits (400+ base64 characters for RSA).
3. For recurring monitoring or bulk checks across multiple selectors and domains, pick an automated tool or consider this DKIM verification utility.

If you see no result, the selector is unpublished, wrong, or DNS has not propagated. Review your DKIM deployment or selector origin.

Interpreting DKIM Record Tags

Proper DKIM functionality depends on correct tag usage. Key points:

• The v=DKIM1 tag must be present and alone for versioning.
• The k= algorithm tag will usually be rsa in 2026. If ed25519 appears, be sure your entire mail chain supports it.
• The t= tag's flags: y (testing mode, for rollout) and s (strict—requires exact match between sender domain and selector domain). Remove test mode outside staging, or validation will be ignored.
• The p= tag's value must never be blank unless intentionally revoking the key.

Important checks for each record:

• One active TXT record per selector.
• Minimum 2048-bit key length. Anything shorter can lead to mail failures or score penalties. See eight mechanism verification steps.
• Tags are ordered and formatted as per RFC 6376—no line breaks or unescaped semicolons inside tag values.

Mistakes here are often subtle and break mail silently. Even an extra space, missing semicolon, or malformed tag means DKIM will not validate no matter what the sender does.

Rigorous, periodic validation—manual and automated—saves hours of forensics after a silent mail rejection or spoofing incident.

Troubleshooting DKIM Failures

When DKIM authentication fails, it indicates a breakdown in the email validation process. This can significantly impact your email's deliverability and sender reputation. Identifying the root cause requires a systematic approach to examine the DKIM signature, DNS records, and mail server configurations.

Diagnosing Body and Header Modifications

DKIM signatures are sensitive to changes made to the email's content after it has been signed. Modifications to the email body or certain headers can invalidate the signature, leading to a DKIM failure. Common culprits include automatic footer additions by mailing list software, spam filters that alter content, or mail servers that rewrite headers.

• Body Modification: If the email body is altered (e.g., whitespace changes, line ending conversions), the calculated hash will not match the signature. Using c=relaxed/relaxed canonicalization in your DKIM record helps mitigate minor changes, but substantial alterations will still cause a failure.
• Header Modification: Headers included in the DKIM signature (such as From, To, Subject, Date) must remain unchanged. If a mail server or intermediary service modifies one of these headers, the signature verification will fail. Reviewing the DKIM-Signature header's h= tag will show which headers were signed.
• Signature Verification: Examine the Authentication-Results header on the receiving end. This header often provides specific details about why DKIM failed, such as "body hash failure" or "header mismatch." Analyzing the raw email headers is essential for this step.

Resolving Multiple TXT Records at a Selector

A DKIM selector is designed to allow a domain to use multiple keys simultaneously, for instance, during key rotation. However, having more than one active DKIM TXT record published under the same selector for a given domain is problematic. DNS resolvers may arbitrarily select one of the records, leading to intermittent verification failures because the public key used for verification will not match the private key used for signing.

• Identify Duplicates: Use DNS query tools (like dig or nslookup) to check for multiple TXT records associated with your DKIM selector (e.g., selector._domainkey.yourdomain.com).
• Consolidate Records: Ensure only one valid DKIM TXT record exists for each active selector. If you have old keys or records from previous configurations, remove them.
• DNS Propagation: After making corrections, allow sufficient time for DNS changes to propagate across the internet before re-testing.

Addressing DMARC Alignment Issues with DKIM

DKIM can pass cryptographic verification, yet still fail DMARC alignment. This occurs when the domain used in the d= tag of the DKIM-Signature header does not match or align with the domain in the From: header of the email. This is a common scenario when using third-party email service providers (ESPs) that sign emails with their own domain.

• Alignment Check: Inspect the Authentication-Results header. It will explicitly state if DKIM alignment passed or failed. For example, a DKIM signature with d=sendgrid.net will not align with a From: header of [email protected].
• Custom DKIM Configuration: To achieve alignment, configure your ESP to use a custom DKIM signature with your domain. This typically involves publishing a public key provided by the ESP in your domain's DNS records under a specific selector. This process is often referred to as "custom domain authentication" or similar. See ESP documentation for specific instructions.
• Policy Impact: DMARC policies (p=quarantine or p=reject) rely on alignment. If DKIM alignment fails, and SPF alignment also fails (e.g., due to forwarding), the DMARC policy will be enforced, potentially leading to emails being rejected or sent to spam. Ensuring DKIM alignment is critical for robust email authentication [eb79].

Troubleshooting DKIM failures requires meticulous examination of email headers and DNS records. It is not uncommon for issues to arise from subtle configuration errors or unexpected modifications during mail transit. A structured approach, focusing on the integrity of the signature and the accuracy of the DNS record, is paramount.

DKIM Key Management and Rotation

Implementing Secure DKIM Key Rotation Procedures

DKIM keys require periodic rotation to maintain security. This process involves generating a new key pair, publishing the public key in DNS, and configuring mail servers to use the new private key. The recommended interval for DKIM key rotation is between six to twelve months. Failure to rotate keys can lead to outdated cryptographic strength, increasing vulnerability. When rotating keys, it is imperative to publish the new selector alongside the existing one. The mail sending infrastructure should then be configured to utilize the new selector. After a transition period, typically two weeks, during which mail is signed with both old and new keys, the old key can be revoked. Revocation is achieved by either removing the DNS record or setting the p= tag to an empty value. It is critical to never delete the old selector record until all mail signed with it has completed transit, as this would cause verification failures for legitimate messages.

Understanding Key Length and Algorithm Specifications

In 2026, the industry standard for DKIM key length is 2048 bits. While 1024-bit keys may still be accepted by some mail providers, they are considered weak and may be penalized by major services like Gmail. For new key generation, RSA or Ed25519 algorithms are recommended. RSA is widely supported, whereas Ed25519 is newer and offers performance benefits but may not be universally implemented yet. The algorithm used is specified in the DKIM DNS record with the k= tag (e.g., k=rsa). The public key itself is published in the p= tag. If the p= tag is empty, it signifies that the key has been revoked. When configuring DKIM, ensure that the chosen key length and algorithm meet current security best practices and are supported by your email service provider.

Revoking DKIM Keys Safely

Revoking a DKIM key is a necessary security measure, particularly if a private key is suspected of compromise. The process involves updating the DNS TXT record associated with the selector for the key to be revoked. Specifically, the p= tag, which contains the public key, should be set to an empty value. For example, if the record was v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..., it would be changed to v=DKIM1; k=rsa; p=. Alternatively, the entire DNS record for that selector can be deleted. It is critical to allow a sufficient grace period after revoking a key before it is fully deactivated. This ensures that any mail still in transit, signed with the old key, can still be successfully verified by recipient servers. A minimum grace period of seven days is a conservative recommendation. Failure to observe this grace period will result in DKIM verification failures for legitimate emails, impacting deliverability.

DKIM Verification in Practice

Analyzing Authentication-Results Headers

Upon receipt, mail servers append an Authentication-Results header to incoming messages. This header provides a consolidated view of the authentication checks performed, including SPF, DKIM, and DMARC. Careful examination of this header is paramount for diagnosing authentication failures. A typical entry might appear as dkim=pass header.s=selector. If DKIM fails, the header will indicate dkim=fail or dkim=temperror, often accompanied by diagnostic information. Understanding the specific tags within this header, such as header.s= (the selector used) and header.d= (the domain that signed the message), is critical for pinpointing the root cause of a failure.

Validating DKIM Signatures on Sent Messages

To proactively verify your DKIM implementation, it is imperative to inspect the headers of messages you send. Send a test email from your domain to an external address that you control, such as a Gmail or Outlook account. After receiving the message, access its raw headers. Locate the DKIM-Signature header. This header contains several tags, including v= (version), a= (signing algorithm), c= (canonicalization method), d= (the signing domain), and s= (the selector). The presence and correctness of these tags, particularly the d= tag aligning with your sending domain, are indicators of proper DKIM configuration. For instance, if you are using Google Workspace, you should observe d=yourdomain.com and s=google (or your custom selector). If the d= tag shows a third-party provider's domain, it signifies a failure in DMARC alignment, even if DKIM itself passes.

Correlating DKIM with DMARC Alignment

DKIM verification is not an isolated process; its effectiveness is intrinsically linked to DMARC alignment. DMARC alignment requires that the domain used in the DKIM signature (d= tag) matches or aligns with the domain in the From: header of the email. This alignment is typically evaluated in a 'relaxed' mode by default, allowing for subdomain alignment. However, strict alignment requires an exact match. When analyzing authentication results, observe the Authentication-Results header for both DKIM and DMARC status. A DKIM pass is necessary but not sufficient for DMARC to pass if alignment fails. For example, if your From: header is [email protected] but the DKIM signature shows d=mailservice.com, DMARC alignment will fail. To rectify this, you must configure your sending service to use a DKIM selector associated with your own domain, such as d=example.com using custom domain authentication. This ensures that the DKIM signature cryptographically validates the domain presented to the recipient, reinforcing trust and improving deliverability.

Leveraging Third-Party Tools for DKIM Checks

While manual verification of DKIM records is possible, specialized third-party tools offer a more efficient and often more thorough approach to validation. These services are designed to automate the process of querying DNS, analyzing record structures, and identifying potential configuration issues that might be overlooked during manual inspection.

Utilizing Online DKIM Checkers

Online DKIM checkers provide a straightforward method for verifying your DKIM record's presence and correctness. By inputting your domain name, these tools query the relevant DNS records, typically using common selectors, and present the findings in a human-readable format. This immediate feedback loop is invaluable for rapid troubleshooting. Many of these checkers also analyze the DKIM record's tags, such as v, k, and p, to ensure they conform to expected standards.

• Automated Selector Discovery: Some advanced checkers can automatically detect active DKIM selectors associated with your domain, saving you the effort of manually identifying them. This is particularly useful when multiple services are configured to send email on your behalf, each potentially using a different selector.
• Record Structure Analysis: These tools parse the DKIM TXT record, validating its syntax and identifying any malformed elements that could lead to verification failures.
• Key Verification: They confirm that the public key (p= tag) is present and correctly formatted, which is fundamental for the cryptographic verification process.

For instance, a tool like Sendmarc's DKIM record checker can fetch and analyze your DKIM records, helping to confirm proper configuration for email authentication [e600].

When using online checkers, always cross-reference findings with actual email authentication results. A passing check in a tool is a strong indicator, but real-world message headers provide the ultimate confirmation.

Automated DKIM Scanning with Specialized Services

Beyond simple online checkers, specialized services offer more robust, automated scanning capabilities. These platforms often integrate with DMARC reporting or provide their own reporting dashboards to monitor DKIM health over time. They can identify issues such as:

• Selector Drift: Detecting when a sending service begins using a different DKIM selector than what is published in DNS.
• Key Rotation Issues: Highlighting potential problems during DKIM key rotation, such as the old key being removed prematurely or the new key not being published correctly.
• Alignment Failures: While not strictly a DKIM check, these services often correlate DKIM results with DMARC alignment, flagging instances where DKIM passes but does not align with the From: header domain, which is critical for DMARC policy enforcement [7fc8].

These services are particularly beneficial for organizations managing multiple domains or complex email sending infrastructures, where manual oversight becomes impractical.

Integrating DKIM Validation into Workflows

For continuous assurance, integrating DKIM validation directly into operational workflows is the most effective strategy. This can involve:

1. API-driven Checks: Utilizing APIs provided by DKIM validation services to programmatically check DKIM records as part of deployment pipelines or regular system audits.
2. Monitoring and Alerting: Setting up alerts for any detected DKIM record anomalies or failures, enabling rapid response to potential deliverability impacts.
3. Regular Audits: Scheduling periodic, in-depth reviews of DKIM configurations, especially after changes to email sending platforms or DNS infrastructure.

By embedding DKIM validation into established processes, organizations can proactively maintain a strong email authentication posture and mitigate risks associated with misconfigurations or operational oversights.

Using outside tools can make checking your DKIM records much simpler. These tools help you quickly see if your email setup is correct, saving you time and hassle. Want to make sure your emails are sent the right way? Visit our website to learn more about how we can help you with DKIM checks and other email security needs.

Final Considerations

Verifying your DKIM record is not a one-time task. It requires ongoing attention to maintain email security and deliverability. Regularly checking your DKIM setup, alongside SPF and DMARC, is critical. If you encounter issues, such as DKIM failures or DMARC alignment problems, systematically investigate the authentication results and the message headers. Remember that DNS propagation can take time, and changes to your email sending platforms may necessitate updates to your DKIM configuration. Staying vigilant with these checks helps protect your domain from spoofing and ensures your legitimate communications reach their intended recipients.

Verify Your DKIM Setup with IntoDNS.ai

• DNS & Email Security Scan — Full domain analysis with AI-assisted explanations
• DKIM Configuration Guide — Step-by-step DKIM setup for any provider
• SPF Setup Guide — Complement DKIM with proper SPF records
• SPF Record Generator — Build valid SPF records
• DMARC Policy Generator — Enforce authentication with DMARC
• DMARC Implementation Guide — Complete the authentication trifecta

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 selector and why do I need one?

Think of a DKIM selector as a unique name tag for your email's digital key. It helps email receivers find the right public key in your domain's DNS records to check if an email is really from you and hasn't been messed with. Domains can have multiple selectors, which is super handy for managing different email sending services or for rotating your keys without causing problems.

How can I find out which DKIM selectors my domain is currently using?

The easiest way is to look at the raw code (headers) of an email you've sent from your domain. Find the line that starts with 'DKIM-Signature:' and look for the 's=' part – that tells you the selector! If you don't have a signed email handy, you can try guessing common selectors used by popular email services like Google or Mailchimp, or use online tools that scan for them.

What does a DKIM record actually look like, and what do all those letters and numbers mean?

A DKIM record is a bit like a secret code in your domain's DNS settings. It usually starts with 'v=DKIM1;' which means it's a DKIM record. Then you'll see 'k=rsa;' (or similar) showing the type of encryption used, and the most important part is 'p=', which holds your public key. This public key is what other email servers use to verify emails sent from your domain.

My DKIM check is failing, even though I'm sure I set it up correctly. What could be wrong?

There are a few common culprits! Sometimes, there might be extra spaces in your public key, or the key itself might be too long and split incorrectly by your DNS provider. Another big reason is if the email's content or certain headers were changed after it was signed – this could happen if a mailing list adds a footer. Make sure your DKIM settings allow for 'relaxed' changes to avoid this.

Can I have more than one DKIM record for my domain?

Absolutely! It's actually a good practice. Having multiple DKIM records, each with a different selector, allows you to manage keys for different email services (like one for your main email and another for marketing campaigns) or to rotate your keys safely. Just make sure each record uses a unique selector name.

What's the difference between DKIM and SPF, and why do I need both?

SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are like two different security guards for your email. SPF checks if the email came from an IP address that your domain has approved. DKIM, on the other hand, uses a digital signature to prove the email hasn't been tampered with and was actually sent by your domain. They work together to give email receivers more confidence that your emails are legitimate.