How to Verify DKIM Selector Records for Email Authenticity

A DKIM checker is a specialized diagnostic utility used to query the Domain Name System (DNS) and validate that a domain's public cryptographic keys are correctly published and formatted. When you send an email, your mail server cryptographically signs the message headers and body using a private key, while publishing the matching public key in your DNS records under a specific selector. If your DNS records contain typos, incorrect key types, or formatting errors, mailbox providers will reject your emails or route them straight to the spam folder.

Verifying your cryptographic signatures ensures your emails pass authentication and protects your brand from spoofing. In this guide, you will learn how DKIM works, how to perform manual lookups, how to use online diagnostic tools, and how to fix common configuration mistakes.

Understanding DKIM Selectors and DNS Records

DomainKeys Identified Mail (DKIM) relies on public-key cryptography. Because a single domain might send emails from multiple third-party providers—such as customer support platforms, marketing automation tools, and transactional relays—it needs a way to separate different signing keys. This is accomplished using a selector.

A selector is simply an arbitrary string identifier (e.g., s1, google, mailjet) appended to your domain name to form a unique DNS lookup path. The resulting DNS TXT record query looks like this:

selector._domainkey.example.com

When a receiving mail server processes your email, it reads the DKIM-Signature header, extracts the domain (d=) and the selector (s=), and queries the DNS for the corresponding TXT record to retrieve the public key. It then uses that key to verify the cryptographic hash of the message.

The Anatomy of a DKIM Record

A standard DKIM public key record is published as a DNS TXT record containing specific tags separated by semicolons. Here is an example of a modern 2048-bit RSA DKIM record for s1._domainkey.example.com:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA02...QIDAQAB

• v=DKIM1: Specifies the protocol version. It must be uppercase.
• k=rsa: Specifies the cryptographic algorithm key type (commonly rsa or ed25519).
• p=: Contains the base64-encoded public key data.

How to Use a DKIM Checker

Manually querying DNS records and decoding base64 keys can be tedious and prone to human error. Using a dedicated DKIM Checker simplifies this entire diagnostic process by automatically querying the correct DNS servers, parsing the tags, validating syntax, and confirming that the public key matches your email infrastructure's requirements.

Step-by-Step Verification Process

1. Identify Your Selector: Locate the selector string provided by your email service provider or generated on your mail server. Common examples include default, k1, smtp, or mail.
2. Open the Diagnostic Tool: Navigate to the verification utility in your browser.
3. Input Your Details: Enter your domain name (e.g., example.com) and your specific selector string into the input fields.
4. Run the Lookup: Click the check or lookup button to query the global DNS namespaces.
5. Review the Results: Examine the output to confirm whether the record exists, is syntactically valid, and meets recommended bit-length standards.

Manual Verification via Command Line Tools

If you prefer working directly from your terminal, you can use standard networking tools like dig or nslookup to inspect your DNS records.

Using dig on Linux and macOS

To query a DKIM TXT record using dig, specify the query type as TXT and construct the fully qualified domain name (FQDN) using your selector:

dig TXT s1._domainkey.example.com

Sample Output:

;; ANSWER SECTION:
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA02...QIDAQAB"

If your provider uses very long 2048-bit keys, the record string may be split into multiple quoted strings inside the DNS response. Standard DNS resolvers automatically concatenate these strings, but you must ensure your DNS provider's web interface handles string chunking properly.

Using PowerShell on Windows

If you are on a Windows machine, you can use PowerShell to query the DNS TXT record:

Resolve-DnsName -Name "s1._domainkey.example.com" -Type TXT

DKIM vs SPF vs DMARC Comparison

DKIM is just one pillar of a robust email authentication strategy. Understanding how it compares to Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting, and Conformance (DMARC) helps clarify your overall security posture.

Feature	DKIM	SPF	DMARC
Primary Purpose	Verifies message integrity and authorship via cryptography.	Authorizes which IP addresses can send mail for a domain.	Uses SPF and DKIM results to dictate policy and reporting.
DNS Record Location	selector._domainkey.example.com	example.com (root TXT)	_dmarc.example.com
Survives Forwarding?	Yes, because the signature is embedded in the headers.	No, because forwarding changes the sending IP address.	Relies on SPF and DKIM alignment rules.
Key Requirement	Public/private key pair generation.	Simple list of approved IPv4/IPv6 addresses and mechanisms.	Policy configuration string (p=none/quarantine/reject).

Common DKIM Configuration Mistakes and How to Fix Them

Even experienced engineers occasionally run into signature failures due to subtle syntax errors or DNS management quirks. Review these common pitfalls to keep your mail flowing smoothly.

1. Trailing Dots and Undefined Domains

When adding a TXT record in your DNS provider's dashboard (such as Cloudflare, Route53, or cPanel), many panels automatically append your root domain name to the record name.

• The Mistake: Entering s1._domainkey.example.com. results in a final query of s1._domainkey.example.com.example.com, causing the lookup to fail.
• The Fix: Enter only the selector prefix portion (s1._domainkey) if your DNS manager appends the zone automatically, or use the fully qualified domain name ending with a trailing dot (.) if your provider requires absolute FQDN entries.

2. Exceeding DNS Character Limits for 2048-bit Keys

A standard 2048-bit RSA public key is quite long and often exceeds the traditional 255-character limit for a single DNS string.

• The Mistake: Pasting the entire base64 string as one continuous block into a DNS provider that doesn't automatically split strings.
• The Fix: Break the public key string into multiple quoted substrings enclosed in parentheses or separated by whitespace, adhering to RFC 6376 guidelines. Most modern DNS management interfaces handle this automatically when you paste the key.

3. Using Deprecated Key Types or Weak Lengths

• The Mistake: Retaining old 512-bit or 1024-bit RSA keys that are vulnerable to computational cracking.
• The Fix: Generate and deploy modern 2048-bit RSA keys, or migrate to Ed25519 keys if your email infrastructure supports them.

DKIM Verification Checklist

• Identify all active selectors used by your email providers and marketing tools.
• Confirm that public keys are published as DNS TXT records under selector._domainkey.yourdomain.com.
• Verify that the v=DKIM1 tag is present and properly capitalized.
• Ensure long keys are correctly chunked without syntax or quote errors.
• Run an automated diagnostic lookup to confirm global DNS propagation.
• Pair your DKIM setup with a properly configured SPF record and DMARC policy.