How it works · DKIM

DKIM: proof a message is really yours

DKIM attaches a cryptographic signature to every message you send. Receiving servers use it to confirm the mail genuinely came from your domain and wasn't tampered with on the way.

2

Keys: one private, one public

Every

Message signed, one by one

All

Selectors discovered and checked

A tamper-proof seal on every message

DKIM stands for DomainKeys Identified Mail. As each message leaves your sending service, DKIM adds an invisible cryptographic signature to it, a bit like a wax seal that’s unique to that exact message. The seal is created with a private key only your service holds.

The matching public key is published in your DNS for anyone to read. When a receiving server gets the message, it uses that public key to test the seal. If it matches, two things are proven at once: the message genuinely came from your domain, and nothing inside it was altered in transit. If even a character of the signed content changed along the way, the seal breaks and the check fails.

Where SPF and DKIM differ

  • SPF checks the sending server: was this server allowed to send?
  • DKIM checks the message itself: is it authentic and unchanged?
  • DKIM survives forwarding, where SPF often quietly breaks
  • Together they give DMARC two independent ways to confirm a message is real

The selector: how receivers find the right key

You don’t have just one key. Each sending service usually has its own, and each one is published under a label called a selector. The signature on a message names the selector it used, so the receiver knows exactly which public key to fetch from your DNS to test the seal. Get the selector wrong, or never publish it, and the whole check falls apart.

1 · The message is signed

Your sending service signs the message with its private key and stamps the signature with its selector name, for example s1._domainkey.yourdomain.com.

2 · The receiver looks it up

The receiver reads the selector from the signature and fetches the matching public key from your DNS, the half of the pair you publish for the world to see.

3 · The seal is tested

If the public key verifies the signature, DKIM passes: proof the message is yours and untouched. If not, it fails, and DMARC decides what happens next.

Where it quietly goes wrong

DKIM rarely fails loudly: it fails silently

The trouble with DKIM is that a broken setup looks identical to a working one from the outside. Mail still leaves, inboxes still receive, right up until a receiver tightens its rules or an attacker exploits the gap. By then the weakness has been there for months.

The usual culprits are easy to miss by eye: a key that’s too short to be trusted by modern receivers, a deprecated hash algorithm that’s no longer considered safe, a stale key never rotated for years, or a selector missing on one sender out of many, so most of your mail signs cleanly while one important service slips through unsigned.

The four that catch people out

  • Keys too short to meet modern strength expectations
  • Deprecated hash algorithms that receivers distrust
  • Stale keys that were never rotated
  • A selector missing on some senders: unsigned mail nobody spots

What “good” looks like

Every service that sends as you signs with DKIM, using strong, current keys that are rotated over time, with no unsigned senders slipping through. The hard part is simply knowing which selectors you really use, because forgotten tools and shadow senders are exactly where the gaps hide. That discovery is where DMARCER earns its keep.

How DMARCER keeps you safe

You can’t check a selector you don’t know exists, so DMARCER finds them for you. It discovers the selectors you actually use, both by reading your DNS and by mining the selectors that show up in your DMARC reports, the same reports that reveal real-world senders you may have forgotten.

Then it checks each one: key strength, the hash algorithm in use, how long it’s been since the key was last changed, and whether a sender is signing at all. Anything weak, deprecated, stale or missing is flagged in plain English, with what to fix, so the silent failures stop being silent.

  • Selector discovery from DNS and your DMARC reports
  • A per-selector check of key strength and algorithm
  • Flags stale keys that are overdue for rotation
  • Spots senders that aren’t signing at all
  • Plain-English findings you can act on or hand to a client

Keep exploring

DKIM management →

Discover every selector and keep each key strong and current.

DKIM checker →

Look up a selector and test its key in seconds, free.

DMARC →

How a DKIM result becomes real protection against spoofing.

Find the selectors you didn’t know you had

Run a free check to see which of your senders sign with DKIM, and which are quietly going out unsigned.

Check your domain
Free domain check

Check your domain security

See how your domain's security compares to your competitors.