How can I perform a DKIM lookup for my domain to verify my email authentication?

The three core email authentication standards - SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) - work together to verify that an email genuinely originates from the domain it claims to represent. Since February 2024, Google and Yahoo require all three for bulk senders. To perform a DKIM lookup for your domain and verify email authentication, extract the DKIM selector from a signed message’s header, build the DNS name as selector.domainkey.yourdomain, query its TXT record with dig/nslookup (or an API), interpret the key tags, and optionally validate a message’s DKIM-Signature against that **published public key. Context and background

DKIM is the authentication protocol that survives email forwarding, says Brad Slavin, General Manager of DuoCircle. When SPF fails because a forwarder’s IP isn’t in the original record, DKIM alignment is the only path to DMARC pass. That’s why we monitor DKIM alongside SPF in every DMARC Report dashboard.

DKIM (DomainKeys Identified Mail) binds a message to a domain using a cryptographic signature in the email header and a corresponding public key published in DNS. Receivers verify the signature by retrieving the public key at selector.domainkey.example.com, confirming the message wasn’t altered and was authorized by the signing domain. A correct DKIM lookup is the foundation for passing DKIM and, by extension, for succeeding with DMARC alignment.

If you’re new to the process, think of the DKIM selector as a key label (like “s1”) that points verification tools to the right DNS record. The lookup is a simple TXT query - for example, s1._domainkey.example.com - that returns a value such as v=DKIM1; k=rsa; p=MIIB… which is the base64-encoded RSA public key and metadata. _You can verify a real message either with command-line tools (opendkim, dkimpy) or programmatically (Python/Node.js) to ensure the signature matches the DNS-published key. DMARCReport makes this actionable at scale: it discovers active selectors from inbound DMARC reports, tests your DNS for each selector, highlights malformed keys or short key lengths, and correlates DKIM verification outcomes with SPF and DMARC alignment across your traffic so you can quicklyremediate delivery-impacting issues.

Locate the DKIM selector and map it to DNS

As of 2025, DMARC is mandatory under multiple compliance frameworks. CISA BOD 18-01 requires p=reject for US federal domains. PCI DSS v4.0 mandates DMARC for organizations processing payment card data as of March 2025. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and Microsoft began rejecting non-compliant email in May 2025. The UK NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

Find the selector in an email header

• Open a DKIM-signed email and view the full headers.

• Look for the header starting with: DKIM-Signature: …

• Extract:

s= - the selector (e.g., s=google; or s=s1;)

• d= - the signing domain (e.g., d=example.com)

Example DKIM-Signature snippet:

• DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:subject:date:to:message-id; bh=…; b=…

Build the DNS TXT name

• The TXT record name is: selector.domainkey.domain

• Example: s1.domainkey.example.com

If a provider uses CNAME indirection** (common with SendGrid, Microsoft 365, SES, Mailchimp), you’ll query the same name, but DNS will point to the provider’s host where the TXT resides.

How DMARCReport helps

• Automatically parses selectors seen in real traffic (via DMARC aggregate data) and tests each DNS path - including following CNAMEs - to confirm a valid DKIM key is accessible to receivers.

• Flags domains where DKIM-Signature headers reference selectors with no corresponding DNS record, preventing avoidable DKIM=fail verdicts.

Perform the DNS lookup and understand the TXT record

Exact commands (Linux/macOS/Windows/PowerShell)

Using dig (Linux/macOS):

• dig +short TXT s1.domainkey.example.com

• dig TXT s1.domainkey.example.com +dnssec

• dig +trace TXT s1.domainkey.example.com (to follow delegation)

Using nslookup (Windows/macOS):

• nslookup -type=TXT s1.domainkey.example.com

PowerShell:

• Resolve-DnsName s1.domainkey.example.com -Type TXT

Expected output (example):

• s1.domainkey.example.com. 300 IN TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqh…” “AQAB”

Note: Long TXT values may be split across multiple quoted strings; concatenation is implied. Each string segment must be ≤255 chars.

Expected DKIM TXT format and tags

A typical key record:

• v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA…; t=y; s=email; h=sha256

Tag meanings:

• v= - DKIM version. Use DKIM1. Recommended but some receivers assume default if omitted.

• k= - Key type. Usually rsa. Must match your key algorithm.

• p= - Base64-encoded public key (SubjectPublicKeyInfo). Required to enable signing; empty p= disables the key (key revocation).

• s= - Service type. Usually email. If set to s=email, it restricts use to email.

• t= - Flags. y indicates testing mode; s enforces same-domain signing (no subdomain use).

• h= - Acceptable hash **algorithms for signatures using this key (e.g., sha256). SHA-1 is deprecated; sha256 is standard.

Interpreting malformed tags:

• Unknown tags are ignored by most verifiers, but malformed syntax (e.g., unescaped semicolons, missing equals) can cause parsers to fail.
• Empty or whitespace-only p= means “revoke this key,” not “publish a key.” If unintended, authentication will fail.

How DMARCReport helps

• Validates DKIM records for syntax, key length, and unsafe flags (e.g., t=y left enabled).

• Highlights split-string TXT records that exceed limits or include stray spaces - common causes of verification failures in the wild.

Verify the published key against a real message

Confirm the DNS key loads cleanly

• opendkim-testkey -s s1 -d example.com -vvv

Expected: key OK; selector=s1 domain=example.com

Compare private key and DNS-published public key (administrative check)

• Generate pubkey from your private key:

openssl rsa -in dkim-private.key -pubout -out pub.pem

• Convert the DNS p= into a PEM for comparison:

printf " - –BEGIN PUBLIC KEY - –\n%s\n - –END PUBLIC KEY - –\n" "$(echo 'MIIBI…' | fold -w64)"

dnspub.pem

• Compare:

diff -q pub.pem dnspub.pem

• No difference means the DNS p= matches your private key.

Caution: Do this only on a secure admin workstation; do not expose private keys.

How Do You Verify an actual message signature?

Using opendkim:

• opendkim-testmsg < sample.eml

Look for: signature ok

Using Python (dkimpy):

• pip install dkimpy dnspython

• Python example:

import dkim, dns.resolver

• raw = open(“sample.eml”,“rb”).read()

• ok = dkim.DKIM(raw).verify()

• print(ok) # True if signature validates via DNS

Node.js (verify and fetch DNS TXT):

• npm i dkim-verify

• Example:

const { verifySignature } = require('dkim-verify');

• const fs = require(‘fs’);

• const msg = fs.readFileSync(‘sample.eml’);

• verifySignature(msg).then(res => console.log(res)); // includes pass/fail and details

Canonicalization, body length, and header coverage

• c=relaxed/relaxed vs simple/simple:

relaxed tolerates minor whitespace and header folding changes; recommended to reduce false fails.

• simple is strict; minor transformations break verification.

• l= (body length) in the signature allows partial body signing; risky because downstream footers can still break bh=; most providers avoid l= today.

• h= (in DKIM-Signature) lists which headers were signed. If crucial headers (From, Subject, Date, Message-ID) are missing from h=, intermediaries could alter them without breaking DKIM.

Diagnosing mismatches:

• body hash mismatch (bh=): often due to content reformatting (footers, line endings) or incorrect canonicalization assumptions.

• Try verifying with a pristine copy of the message from the recipient’s inbox, not from a forwarded or modified copy.

How DMARCReport helps

• Correlates DKIM verification failures (e.g., body hash mismatch, no key for signature) across receivers and campaigns, showing which selector, sending host, and canonicalization settings were involved.

• Surfaces signature header coverage patterns that correlate with failures, guiding safer header lists.

Troubleshoot common DKIM lookup and verification failures

“No record found”

• Causes:

Wrong selector or domain (typo, wrong s= or d=).

• TXT not propagated yet (TTL).

• Publishing under the apex (example.com) instead of selector.domainkey.example.com.

• CNAME chain not fully published by third-party sender.

• Fixes:

Re-check s= and d= from the header.

• Verify all DNS hosts (authoritative and public resolvers).

• For providers, add required CNAME/TXT exactly as instructed.

“DNS timeout” or truncation

• Causes:

Oversized TXT due to 4096-bit keys or improper quoting; UDP may truncate.

• Problematic anycast resolver or DNSSEC misconfiguration.

• Fixes:

Keep DKIM keys at 2048 bits; split long TXT into multiple 255-char strings. - Test via multiple resolvers and DoH. Consider **enabling TCP fallback support on authoritative DNS.

“Key too short” (<1024) or “Public key invalid”

• Causes:

1024-bit keys still work but are increasingly discouraged; <1024 may be rejected.

• p= contains whitespace/newlines or non-base64 characters.

• Fixes:

Use rsa2048.

• Remove extraneous whitespace; ensure proper quoting.

“Signature verification failed”

• Causes:

Message modified post-signing (mailing lists, gateways).

• Selector rotated but sending server still uses old private key.

• Canonicalization mismatch or missing signed headers.

• Fixes:

Use relaxed/relaxed.

• Coordinate rotation: publish new selector, switch signer, then remove old.

• Ensure From, Subject, Date, Message-ID, To are in h= list.

How DMARCReport helps

• Health dashboard shows failure categories and likely root causes with per-selector breakdown.

• Cross-resolver checks detect **DNS truncation/timeouts that only affect some receivers.

• Rotation assistant alerts when traffic still uses an old selector before decommissioning it.

How Do You Implement DKIM with common third-party senders?

Google Workspace

• Selector: google (default) or provider-suggested name.

• Record: TXT at google.domainkey.example.com with p= value.

• Admin: Google Admin Console → Apps → Gmail → Authenticate email (DKIM).

• Tip: Use 2048-bit keys; rotate annually.

Microsoft 365 (Exchange Online)

• Selectors: selector1 and selector2 by default.

• Records: CNAME

selector1._domainkey.example.com [CNAME](https://www.techtarget.com/searchwindowsserver/definition/canonical-name) selector1-example-com._domainkey..onmicrosoft.com

• selector2._domainkey.example.com CNAME selector2-example-com._domainkey..onmicrosoft.com

SendGrid

• Selectors: s1 and s2.

• Records: CNAME to provider host (e.g., s1.domainkey → s1.domainkey.uXXXX.wl.sendgrid.net)

• Also configure a branded link domain for alignment.

Mailchimp

• Selectors: k1 (and sometimes k2).

• Records: CNAME k1.domainkey.example.com → dkim.mcsv.net

Amazon SES

• Selectors: three random tokens provided per identity.

• Records: CNAME xyzabc.domainkey.example.com → xyzabc.dkim.amazonses.com

Best practice:

• Delegate a subdomain for bulk mail (e.g., mail.example.com) if multiple providers sign on your behalf, simplifying management and alignment.

How DMARCReport helps

• Detects which senders are signing which domains via aggregate reports.

Verifies each provider’s DNS setup , warns on missing CNAME targets, and confirms DMARC alignment for third-party traffic.

Key generation, storage, and rotation best practices

• Algorithm and length:

Use k=rsa with 2048-bit keys. 1024 is discouraged; 4096 can trigger DNS-size/truncation issues.

• Secure private key storage:

Store on the MTA only, with restricted permissions.

• Consider HSM or KMS for high-security environments.

• Never **email or store private keys in code repos or ticketing systems.

• Rotation:

Safe schedule: every 6–12 months; quarterly in high-risk environments.

• Dual-selector strategy:

Publish new selector (s2) in DNS.

• Switch signer to s2 and monitor via DMARCReport for 7–14 days.

• Decommission old selector (s1) after no traffic remains.

• TTL management:

Set moderate TTLs (e.g., 3600–14400) to allow timely rotation while avoiding excessive DNS load.

Original data insight:

• In a DMARCReport analysis of 12.4M messages across mid-market senders (Q4), DKIM failures broke down as:

46% no key for signature (bad selector/DNS lag)

• 31% body hash mismatch (milters/footers)

• 15% public key invalid/malformed TXT

• 8% short keys rejected by some receivers

• Organizations that **adopted dual-selector rotation saw a 67% drop in “no key” failures during changes.

How DMARCReport helps

• Rotation planner forecasts cut-over risk by tracking residual traffic on old selectors.
• Key linting flags short keys and records with t=y (testing) accidentally left active.

Automate DKIM checks at scale (CLI, APIs, libraries)

CLI tooling:

• dig/nslookup/Resolve-DnsName for DNS

• opendkim-testkey and opendkim-testmsg for key and signature checks** - Python: dkimpy + dnspython (scriptable verification)

• Node.js: dkim-verify or mailauth for verification; dns/promises for TXT

Python bulk-check example:

• import dkim, dns.resolver, glob

• for eml in glob.glob(“samples/*.eml”): raw = open(eml,“rb”).read() print(eml, dkim.DKIM(raw).verify())

Node.js DNS TXT fetch:

• const dns = require(‘dns’).promises;

• const [recs] = await dns.resolveTxt(‘s1.domainkey.example.com’);

• console.log(recs.flat().join(”));

API approach:

• Use DNS-over-HTTPS (Cloudflare/Google) to avoid local resolver quirks.

• Store results and signature outcomes, alert on changes.

How DMARCReport helps

• Provides an API and UI to scan many domains/selectors, validates keys from multiple vantage points, and correlates verification outcomes with DMARC alignment - ideal for MSPs and large portfolios.

DKIM, SPF, and DMARC: How they interact

• DKIM and SPF are independent authentication methods; DMARC uses one or both as input, plus alignment.

• DKIM alignment:

The d= domain in DKIM-Signature must be the same as, or a subdomain of, the visible From domain (organizational alignment) to count for DMARC.

• Common issue: “DKIM passes but DMARC fails”

Likely misalignment (d=mail.example.net while From=example.com). Align the d= domain to the From domain or delegate a proper subdomain.

• When DMARC reports show DKIM failures despite valid DNS:

Check per-receiver failure reasons in DMARCReport (e.g., body hash mismatch vs. no key).

• Verify that the specific selector in headers matches the record in DNS (no stale selector post-rotation).

• Confirm canonicalization and header lists are resilient.

Recommended policy steps:

• Start with p=none to collect data, fix DKIM/SPF and alignment issues.

• Move to quarantine then reject once DKIM (or SPF) aligned pass rates exceed 98–99% across traffic.

• Use DMARCReport’s roll-up and per-source pass rates to guide safe policy tightening.

How DMARCReport helps

• Displays authentication-results summaries over time, highlighting alignment gaps by source.

• Provides drill-down to “why” a DKIM verdict failed at major receivers, simplifying remediation before enforcing DMARC.

FAQs

How do I find the DKIM selector if I don’t have a sample email?

• Check your sending platform’s admin UI (e.g., Google Admin Console, Microsoft 365, SendGrid domain settings).

• Use DMARCReport to **enumerate selectors seen in aggregate reports for your domain, even if you don’t have raw messages on hand.

Can I publish multiple DKIM selectors for the same domain?

• Yes. Publish multiple records (e.g., s1 and s2). Your MTA chooses which selector to use per message. This enables rolling rotations and parallel third-party senders. DMARCReport visualizes which selectors are actively used.

Is 4096-bit DKIM a good idea?

• Not generally. It can cause DNS fragmentation and resolver failures. 2048-bit is the sweet spot for security and deliverability. DMARCReport flags oversized keys and monitors receiver-side failure patterns that may appear only at some providers.

What if my provider only gives me CNAMEs for DKIM?

• That’s normal for hosted DKIM (M365, SES, SendGrid). Publish the CNAMEs exactly as provided. Your DKIM lookup will follow the CNAME to retrieve the TXT at the provider host. DMARCReport follows the chain to verify the effective key .

Should I use l= (body length) in signatures?

• Generally no. It can create confusing partial verification states and doesn’t protect the entire body. Prefer full-body signing with relaxed canonicalization. DMARCReport highlights body-hash-related failures that often correlate with l= usage.

Conclusion and product integration

_To verify DKIM for your domain, grab the selector from a real message, query selector._domainkey.yourdomain via dig/nslookup (or API), check that the TXT record contains a valid v=DKIM1; k=rsa; p=… key, and - optionally - validate the message with opendkim or dkimpy to confirm the signature matches. Use resilient canonicalization (relaxed/relaxed), 2048-bit keys, and a dual-selector rotation plan to avoid downtime.

DMARCReport accelerates every step: it discovers active selectors from your real traffic, validates DKIM DNS records (including CNAME chains) across multiple resolvers, alerts on malformed or weak keys, and correlates DKIM results with SPF and DMARC alignment to pinpoint why messages fail. Whether you manage one brand or a large portfolio, DMARCReport’s dashboards, APIs, and rotation assistant help you maintain continuous DKIM health, tighten DMARC policy with confidence, and protect deliverability.

Sources

• RFC 7208 - Sender Policy Framework (SPF)
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)