DKIM checker
A DKIM signature proves that a message was sent by someone who holds your key and was not changed on the way. The signature is only worth anything if the public key that checks it is published where receivers will look. Enter your domain and your selector and see whether that record is there and what it says.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
What a DKIM record is, in one paragraph
When your mail system sends a message it signs it with a private key and adds a DKIM-Signature header that names the domain and a selector. The receiving server takes those two names, looks up the TXT record at selector._domainkey.yourdomain and uses the public key found there to check the signature. This checker inspects that published DNS key and its tags; it does not verify the signature on a particular email or prove that every mail stream uses this selector.
Five reasons to check your own DKIM record
01
Find out whether the key is really published
Mail providers ask you to add a DKIM record, and it is easy to add it in the wrong place: under the wrong name, on the wrong domain, or on a DNS zone the domain no longer uses. The setup page says "done" and the signatures still fail, because the record a receiver asks for is not there.
02
The selector is the one name you cannot guess
A domain can have many DKIM keys at once - one per provider, one per mail stream, one per year. The selector tells a receiver which one to fetch, and it is set by whoever configured your mail. It is in the DKIM-Signature header of any message you send, as s=. Checking the wrong selector finds nothing, which is why this page asks for it.
03
A revoked or empty key looks like a missing one
A record with an empty p= value is a key that has been revoked on purpose. That is correct when you retired a provider, and a bug when it is the record your current provider signs with. Seeing the record exactly as published is what separates the two.
04
Old keys outlive the providers that used them
Every mail tool you have tried left a selector behind. Some are still published, still valid and no longer used by anybody who works with you. A key nobody rotates is a key whose private half has had years to leak, and one more place your records quietly disagree with your mail setup.
05
DKIM is the half of DMARC that survives forwarding
SPF breaks the moment a message is forwarded. DKIM usually does not, because the signature travels with the message. That is why a DMARC policy that insists on enforcement needs a DKIM record that really works behind it.
Know the day your record changes
DKIM keys are rotated, replaced and deleted by whoever manages the mail platform, and the change reaches the DNS a few minutes later.
Scheduled scans turn that into a difference you are told about: this selector disappeared, this record changed, this grade dropped. Alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the domain
A domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Let the check run
DKIM records are public, so this reads rather than probes. It looks the record up the way a receiving mail server would.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F, next to the other DNS records that belong to the same mail setup.
What this is part of
DKIM is one of several mail-related records AYAsec checks as part of its DNS scan, alongside SPF, DMARC, MTA-STS, TLS-RPT and DNSSEC. It is one scan, and this page is about one part of what it looks at.
DNS carries 20% of the composite grade. The others are HTTP at 30%, TLS and ports at 20% each, and domain credibility at 10%. All of them together are what attack surface management means in practice.
Questions before you check
What may I check?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the domain to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
How do I find my selector?
Send a message from the system you want to check to a mailbox you control, open the full headers and find the DKIM-Signature line. The value after s= is the selector and the value after d= is the domain it signs for. Many providers use fixed names such as google or selector1.
The record I see is a CNAME. Is that wrong?
No. Several providers publish the key on their own name servers and ask you to point your selector at it with a CNAME. The key is then read through that name and rotated by the provider.
Does one passing selector mean my mail is signed?
It means that one key is published. Whether each mail stream you send actually signs with it is a question for the sending system; the way to check is to read the headers of a real message.
Is DKIM enough on its own?
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the domain to an AYAsec account instead, and every scan is kept - a series that tells you which edit broke it. Retention depends on your plan.
Keep the history, not just the result
Run the full DNS check against your own domains, on a schedule, with every change flagged to whoever needs to see it.