DKIM Check: a beginner's guide
Discover and validate DKIM signing keys
DKIM: the wax-seal signature on every email you send
DKIM (DomainKeys Identified Mail) is a way of attaching a tamper-proof digital signature to every email message you send. The signature proves two things at the same time: that the message really came from your domain, and that it has not been changed in transit between your sending server and the recipient's inbox. Think of it as the wax seal on an old letter — if the seal is unbroken when the letter arrives, the recipient can be confident that nobody opened the envelope along the way and that the sender is who they claim to be. DKIM was created in 2007 (RFC 6376) by combining two earlier signing standards from Yahoo and Cisco, and it is now part of every serious email-authentication setup.
You should care because DKIM is the only one of the three email-authentication standards that actually proves the message itself was not modified in transit. SPF only proves that the sending server was authorized; it says nothing about whether the message body or headers were changed along the way. DKIM closes that gap with cryptography. Without DKIM, an attacker who could intercept your email could change the contents — replacing a wire-transfer instruction, swapping out a link, modifying an attachment — and the receiving server would have no way to detect the tampering.
The five things every DKIM check looks at:
Is a DKIM key published in DNS? DKIM public keys live in DNS as TXT records at a special location: `selector._domainkey.example.com`. The "selector" lets you have multiple keys at once.
Is the key the right length? Modern recommendations are 2048-bit RSA keys at minimum. 1024-bit keys are now considered weak.
Are outgoing messages actually being signed with that key? A published key with no actual signing means you have the appearance of DKIM with none of the protection.
Does the signature verify against the message body? This is what proves the message was not modified in transit.
Does the signing domain align with the visible From: address? This is the DKIM half of the DMARC alignment check, and it is the most common subtle failure mode.
Three questions a DKIM check answers:
Are my outgoing emails being properly signed by my email provider?
Has the signature key been rotated recently — and if so, did the new key get published correctly?
Is my DKIM signature aligning with my From: domain so that DMARC will accept it?
The cost of skipping DKIM is the absence of cryptographic proof that your messages haven't been tampered with — and the inability to use DMARC effectively, since DMARC depends on either SPF or DKIM passing alignment. The fix is usually a one-time setup with your email provider (Google Workspace, Microsoft 365, SendGrid, Mailchimp, etc.) and then a periodic check that the signing is still active and the key has been rotated on schedule.
The DKIM Check endpoint, in plain language
In one sentence: Discover and validate [DKIM (DomainKeys Identified Mail)](/guides/security-dkim) signing keys
Discovers and validates DKIM (DomainKeys Identified Mail) (DomainKeys Identified Mail, the official internet standard) records by probing 30+ common selectors including Google Workspace, Microsoft 365, Amazon SES, SendGrid, Mailchimp, Postmark, Fastmail, Salesforce, Mimecast, Proofpoint, and more. Analyzes key algorithm (RSA/Ed25519 per the official internet standard), key length (the official internet standard mandates 1024-bit minimum, 2048-bit recommended), detects revoked keys (empty p= tag), and identifies dual-signing setups. Supports custom selector input for targeted verification.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Tests 30+ common DKIM (DomainKeys Identified Mail) selectors (google, default, selector1, selector2, k1, s1, s2, mail, DKIM, zoho, fm1, fm2, fm3, mimecast, proofpoint, mandrill, ses, smtpapi, sf1, sf2, hs1, hs2, pm, etc.) by querying <selector>._domainkey.<domain> TXT records. For each discovered key, validates the DKIM record format (v=DKIM1), identifies the key algorithm (k=rsa or k=ed25519 per the official internet standard), estimates key length (RSA key lengths are estimated from base64-encoded public key size; Ed25519 keys are always exactly 256 bits), parses hash algorithms (h= tag), service type (s= tag), and testing flags (t=y), detects revoked keys (empty p= tag indicating key rotation), warns about multiple DKIM records at the same selector, and identifies dual-signing setups. Returns a security score (0-100) with recommendations for key strength, rotation practices, and migration to Ed25519.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the DKIM Check tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
DKIM (DomainKeys Identified Mail) provides cryptographic proof that an email hasn't been modified in transit (the official internet standard). It's required for DMARC (Domain-based Message Authentication, Reporting and Conformance) alignment and directly impacts email deliverability. RSA 1024-bit keys are now considered weak per the official internet standard — 2048-bit RSA is the industry standard minimum, with Ed25519 (the official internet standard) as the recommended next-generation algorithm. Google, Yahoo, and Microsoft mandate DKIM signing for bulk senders (5,000+ emails/day) as of 2024-2025. Selector discovery also reveals which email services a domain uses — valuable for security assessments and competitive intelligence.
Picture this in real life. Imagine an email administrator. Here's the situation they're walking into: After configuring DKIM (DomainKeys Identified Mail) for a new email service (Microsoft 365, Google Workspace, SendGrid), verify the DNS (Domain Name System) record is published and properly formatted. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the DKIM Check tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the DKIM Check tool is built for you:
Will the emails I send actually reach the inbox, or are they going to spam?
Can someone else send phishing emails pretending to be my domain?
Have I set up the three rulebooks (SPF, DKIM, DMARC) that mailbox providers now require?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Small-business owners worried about deliverability, marketing managers onboarding a new email service, IT admins prepping for a security audit, and brand teams protecting against phishing. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and your real emails risk landing in the spam folder while scammers find it easier to impersonate your brand. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the developer plan. The technical details: `GET /v1/security/dkim`.
When would I actually use this?
If you're still on the fence about whether the DKIM Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an email administrator, a security engineer, a security analyst, and a compliance auditor — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Email Authentication Setup Verification
Imagine you're an email administrator. After configuring DKIM (DomainKeys Identified Mail) for a new email service (Microsoft 365, Google Workspace, SendGrid), verify the DNS (Domain Name System) record is published and properly formatted.
Why it matters: Confirm DKIM (DomainKeys Identified Mail) is correctly configured before sending production email.
Story 2: Key Rotation Verification
Imagine you're a security engineer. During DKIM (DomainKeys Identified Mail) key rotation, verify both old and new keys are published before switching. Confirm old keys are revoked after rotation.
Why it matters: Ensure seamless key rotation without email delivery disruption.
Story 3: Email Infrastructure Discovery
Imagine you're a security analyst. Discover which email services a domain uses by finding their DKIM (DomainKeys Identified Mail) selectors (e.g., "google" for Gmail, "selector1" for Microsoft 365, "k1" for Mailchimp).
Why it matters: Map email infrastructure for security assessments or competitive analysis.
Story 4: Key Strength Assessment
Imagine you're a compliance auditor. Verify DKIM (DomainKeys Identified Mail) key lengths meet minimum requirements (RSA 2048-bit recommended by M3AAWG) and identify any legacy 1024-bit keys that need upgrading.
Why it matters: Ensure cryptographic key strength meets current security standards.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the DKIM Check tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
When setting up email on a brand-new domain.
After signing up for a new email-sending service (Mailchimp, SendGrid, HubSpot, etc.).
When a customer reports that your emails are landing in their spam folder.
Before a security audit, a SOC 2 review, or a major marketing campaign.
If you can see yourself in even one of those bullets, the DKIM Check tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the DKIM Check tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the DKIM Check tool to check google.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/security/dkim?domain=google.com"What you need to provide
You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to check DKIM (DomainKeys Identified Mail) records for | google.com |
selectors | string | Optional | Comma-separated list of custom DKIM (DomainKeys Identified Mail) selectors to check in addition to common selectors. | google,selector1,myapp |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
dkim.found | boolean | Whether any DKIM (DomainKeys Identified Mail) records were found |
dkim.selectors_checked | array | All selectors that were probed |
dkim.found_selectors | array | Discovered DKIM (DomainKeys Identified Mail) records with selector, record, key_type (rsa/ed25519), and key_length |
score | number | Security score 0–100 based on key strength and configuration |
grade | string | Letter grade A–F |
recommendations | array | Key strength and configuration recommendations |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.
DKIM (DomainKeys Identified Mail) — A digital signature added to every email you send. The receiving mail server checks the signature to make sure the message really came from you and was not changed in transit.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — An email rulebook you publish in your DNS. It tells receiving servers what to do with email that fails SPF or DKIM checks — ignore it, send it to spam, or block it entirely.
RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.