DKIM Record Checker

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It gives your domain a way to show that an email was actually sent by someone who controls the DNS settings. The sending system puts a digital signature on the message, and receivers check it by looking up a public key in DNS.

It does not take much crypto knowledge to use it. Think of it like a seal on a package that shows if anything was messed with. If the seal lines up with what the domain published, then the message looks more reliable. Missing or broken signatures just make inbox providers more careful.

The record lives in DNS as a TXT entry at something like mailapi._domainkey.example.com (Mails.now / mailapi.tech) or google._domainkey.example.com. A checker can read that and point out issues that might hurt delivery.

Why DKIM matters

Inbox providers want proof that mail from your domain went through systems you control. DKIM gives them that proof in a way that can be checked automatically. Without it, legitimate messages end up in spam more often, and later DMARC checks get harder.

It also helps protect the brand, because attackers can fake the From address but they cannot fake a valid signature without the private key. When it is used with SPF and DMARC, it becomes one of the main parts of email authentication. For a business, the real benefit shows up in fewer support tickets about weird emails and better placement for normal mail.

What a DKIM record looks like

A DKIM public key is a TXT record under selector._domainkey.yourdomain.com. For Mails.now, the selector is typically mailapi, so the host looks like mailapi._domainkey. Providers often give you either a TXT value or a CNAME that points to their hosted key.

Here is a simplified Mails.now TXT example (the p= value is shortened):

Host: mailapi._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…

Real DKIM record examples

Exact hostnames and values come from your provider. These show the patterns you will publish in DNS.

How to check DKIM on this site

Use the checker at the top of this page to inspect a selector’s public key, key length, and common setup issues.

1. Scroll to the DKIM Record Checker form at the top of this page.
2. Enter your domain in the Domain Name field (for example, mailapi.tech or a domain that sends through Mails.now).
3. Enter the Selector Name your provider uses (for Mails.now use mailapi; other common values are google, selector1, or default).
4. Click Check DKIM Record.
5. Review the status badge, the published record, parsed tags, and key strength details.
6. If multiple selectors were discovered, switch between them in the report, then fix DNS and re-check after propagation.

How DKIM works

1. Your email provider signs selected headers and the body with a private key that never goes in DNS.
2. The signature header names the selector and domain receivers should look up.
3. The receiving server fetches the public key from selector._domainkey.domain.
4. If the signature matches, DKIM passes; if signed content changed in transit, it fails.

What is a DKIM selector?

A selector is just a label that points to one particular key. Common ones are mailapi (Mails.now / mailapi.tech), default, google, or selector1. They let a domain run several keys at once so different tools can sign mail without sharing the same record. The selector shows up both in the header and in the DNS name, so you have to use the right one when checking.

How public and private keys work

Public and private keys work as a pair. The private one stays with the email provider while the public one sits in DNS under the p= tag. Receivers only need the public part. An empty p= value usually means the selector was taken down on purpose.

DKIM vs SPF and DMARC

SPF checks the sending IP against the envelope address, while DKIM checks the actual content signature. Forwarding often breaks SPF, but DKIM can survive it, which is why DMARC leans on aligned DKIM results. DMARC itself just looks at whether SPF or DKIM passed in line with the visible From domain and then applies whatever policy you set.

Common DKIM mistakes

1. Publishing the key under the wrong hostname or selector.
2. Pasting an incomplete key because a DNS panel truncated the value.
3. Enabling DKIM in the provider without publishing DNS for the From domain.
4. Leaving old selectors behind after switching tools.
5. Keeping weak 1024-bit keys longer than necessary.

How to create and publish a DKIM record

1. Open your email provider dashboard and enable DKIM for the domain.
2. Copy the exact hostname (selector) and TXT or CNAME value they provide.
3. Add that record in your DNS host without changing the key text.
4. Wait for DNS to propagate, then verify with the checker on this page.
5. To rotate keys, publish a new selector first, switch signing, then remove the old one.

Key size and popular providers

Key size matters a bit. 2048-bit keys are the practical choice for most cases now, while longer ones create bigger DNS records that not every system likes. Providers like Mails.now (mailapi.tech), Google Workspace, or Microsoft 365 each have their own common selectors and record types, so you follow what they document.

Troubleshooting DKIM failures

1. Confirm the selector in the email header matches the DNS hostname you published.
2. Check that the public key is complete and the record parses cleanly.
3. If DNS looks fine but messages still fail, review alignment between the signature domain and the From address.
4. Keep a simple list of active selectors and when they were last changed.

Frequently asked questions