DKIM Lookup
DKIM Lookup helps you check domainkeys identified mail records, for email authentication analysis, policy checks, and delivery troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
DKIM (DomainKeys Identified Mail) Check verifies cryptographic signatures in email headers that prove the email was sent by an authorized server and hasn't been tampered with in transit.
Why It Matters
- →Email Integrity: Guarantees messages haven't been modified
- →Authentication: Cryptographically proves sender identity
- →Deliverability: Major providers require DKIM for inbox placement
- →Trust: Recipients can verify emails genuinely came from your domain
How to Read Results
- Selector: A label for the specific DKIM key (e.g., "default", "google", "sendgrid")
- Public Key: The RSA or Ed25519 cryptographic key used to verify message signatures
- Key Length: RSA-2048 bits minimum recommended; RSA-1024 is deprecated and insecure
- v=DKIM1: Version identifier that must appear at the start of every DKIM key record
- h=: Hash algorithm — sha256 is required; sha1 is deprecated and must not be used
- p=: Base64-encoded public key value — empty p= means the key has been revoked
Technical Background
DomainKeys Identified Mail (DKIM, RFC 6376) uses public-key cryptography to authenticate email messages. The sending mail server signs the email's headers and body using a private RSA or Ed25519 key, appending a DKIM-Signature header containing the signature, selector, domain, and signed fields. The receiving server looks up the public key from DNS at selector._domainkey.domain.com, verifies the signature, and confirms the email has not been modified since signing. A DKIM selector allows multiple keys for different mail systems (e.g., "google" for Google Workspace, "sendgrid" for SendGrid). Key rotation is a security best practice — old keys should be retired after 6-12 months.
The DKIM-Signature header fields include: b= (base64-encoded signature), bh= (hash of the email body), c= (canonicalization algorithm: "relaxed/relaxed" is most common), d= (signing domain), s= (selector), and h= (list of signed headers). For DMARC alignment, the d= domain must match the RFC5322.From domain either exactly (strict alignment) or as a subdomain (relaxed alignment). DKIM key sizes: RSA-1024 is deprecated; RSA-2048 is the current minimum; Ed25519 keys (32 bytes) provide equivalent security to RSA-3072 with much smaller DNS records.
Common DKIM deployment issues include: missing DKIM records (selector not found in DNS), expired or rotated keys that still appear in email headers, oversized keys that exceed DNS packet limits, and canonicalization mismatches that cause signature verification failures. Email providers like Gmail, Outlook, and Yahoo require DKIM for inbox placement and use DKIM alignment in their DMARC enforcement. Organizations using multiple email sending services (transactional email, marketing platforms, CRMs) should maintain separate DKIM selectors for each service to enable precise audit trails and revocation without disrupting other mail flows.
When rotating DKIM keys (a recommended security practice every 6-12 months), administrators should: publish the new selector in DNS, configure the mail server to use the new key, wait for DNS propagation (up to 48 hours), then decommission the old selector. DKIM signing policy is complemented by DMARC (RFC 7489), which instructs receiving servers on what to do when DKIM and SPF fail. Without DKIM, domains are vulnerable to email spoofing and brand impersonation attacks. A DKIM pass combined with SPF pass and DMARC alignment is the gold standard for email authentication and deliverability.
Common Errors and How to Fix Them
- ProblemThe check reports no record because it queried the 'default' selector, while the sending platform uses a different one.
- FixOpen a message you sent, find the DKIM-Signature header and read the s= value (for example s=google or s=selector1). Enter that selector here; the record lives at <selector>._domainkey.<domain>.
- ProblemThe public key was pasted with line breaks, stray quotes or spaces inside p=, so the Base64 no longer decodes.
- FixPublish the key as one continuous Base64 value. If the DNS panel limits strings to 255 characters, split it into several quoted strings in the same TXT record rather than adding newlines.
- ProblemThe domain still signs with a 1024-bit RSA key generated years ago.
- FixGenerate a 2048-bit key (for example 'openssl genrsa -out dkim.key 2048'), publish it under a new selector, switch signing to that selector and retire the old one. Most DNS providers handle the longer TXT value without issue.
- ProblemDuring key rotation the old selector was deleted the same day signing switched, and messages still in transit or queued failed verification.
- FixKeep the old public key published for several days after the switch. When you finally revoke it, publish the selector with an empty 'p=' instead of leaving a dangling reference.
- ProblemA newsletter or CRM platform signs with its own domain (d=platform.example), so DKIM passes but DMARC alignment fails.
- FixEnable the vendor's custom-domain DKIM. Usually that means adding CNAMEs like s1._domainkey.example.com pointing to the vendor, so signatures carry d=example.com.
- ProblemThe record was published with 't=y' during setup and never cleaned up.
- FixThe testing flag asks verifiers to treat failures leniently, and this tool warns about it. Remove 't=y' once signatures validate consistently.
Frequently Asked Questions
How do I find my DKIM selector?
Send a message to an external mailbox, open the original source and locate the DKIM-Signature header. The s= tag is the selector and d= is the signing domain. Common examples are google for Google Workspace, selector1 and selector2 for Microsoft 365, and k1 or s1 for many marketing platforms. Your provider's admin console also lists it.
Is a 1024-bit DKIM key still acceptable?
It still verifies at most receivers, but 1024-bit RSA is considered weak and RFC 8301 sets 1024 as the bare minimum while recommending at least 2048 bits for signers. Use 2048-bit RSA for broad compatibility. Ed25519 keys (RFC 8463) are short and strong, but not every receiver verifies them, so they are normally added as a second signature.
How often should DKIM keys be rotated?
Industry guidance such as M3AAWG suggests rotating at least every six months, and immediately if a key may have leaked. Rotation is painless with two selectors: publish the new key, wait for DNS to propagate, switch signing, then revoke the old selector a few days later. Many hosted providers rotate automatically through CNAME-delegated selectors.
Can a domain have more than one DKIM record?
Yes, one per selector. A domain might publish google._domainkey for staff mail, s1._domainkey for a newsletter tool and pm._domainkey for transactional mail, each with its own key pair. Each sender signs with its own selector, and receivers fetch only the key named in the signature, so multiple selectors never conflict.
Why does DKIM fail even though the DNS record is correct?
The signature covers the body and selected headers, so anything that alters them after signing breaks it: mailing lists appending footers or subject tags, security gateways rewriting links, or relays re-encoding content. Check whether the failure happens only on certain paths. 'Relaxed' canonicalization tolerates whitespace changes but not content edits; ARC helps receivers trust modified mail.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/dkim-check
curl -X POST https://epcybertools.com/api/tools/dkim-check \
-H "Content-Type: application/json" \
-d '{"domain":"google.com","selector":"google"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Check DKIM record for selector "default"
dig TXT default._domainkey.example.com
# Short output
dig TXT default._domainkey.example.com +short
# Query Google selector
dig TXT google._domainkey.example.com +short