How to verify the DKIM signature of an email

Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com;
  spf=pass ...; dmarc=pass ...

Verifying without waiting for an email

Half the equation checks out without a single message being sent: the public key. A DNS query on the selector does it:

dig TXT selector._domainkey.example.com

The expected result is a v=DKIM1; k=rsa; p=... record with a complete, non-empty public key. A missing key, a truncated one, or an empty p= (revoked key) guarantees failure. For end-to-end verification — signature included — an analyzer covers it: our free analyzer confirms the presence and validity of the key, and, paired with the reports, the real alignment of every source.

Alignment: the only thing that matters for DMARC

It bears repeating, because it's the #1 mistake: a valid DKIM signature is only useful to DMARC if it's aligned. DKIM alignment means the signature's d= domain matches the From: domain. Many platforms sign by default with their domain (d=platform.com): dkim=pass, but no alignment, so DMARC doesn't rely on it. The definitive proof of alignment is read in the aggregate reports, source by source. For the full concept, how the three protocols work together lays it out.

Why a legitimate signature sometimes fails

A signature can fail even though the message is perfectly legitimate. The classic causes:

• The message body was modified in transit. A mailing list adding a footer, a gateway rewriting content: the bh= hash no longer matches, the signature breaks. This is common with lists and some forwards.
• The public key is missing or truncated at the named selector (a publishing slip, a key cut on copy-paste).
• The selector matches nothing — typically after a rotation where the old selector was removed too early.
• The key is revoked (p= empty) or DNS propagation isn't complete for a freshly published key.

Good news: DKIM survives forwarding better than SPF (the signature travels with the message), which makes it the most reliable anchor for DMARC alignment — when the body isn't modified.

The case of forwards and lists

A point that confuses people: a forwarded message or one passed through a mailing list can see its DKIM signature break if the content is altered. That's not a flaw in the configuration — it's the list modifying the message after signing. For these cases, complementary mechanisms exist (like ARC, which preserves the authentication result across intermediaries), but the key thing is not to panic at isolated DKIM failures clearly coming from forwards: volume and source come first, before any conclusion that something is broken.

Dissecting a full Authentication-Results

This header condenses the verdict of all three mechanisms, and knowing how to read it saves a great deal of guessing. An example:

Authentication-Results: mx.example.com;
  dkim=pass header.d=company.com header.s=mail2025;
  spf=fail smtp.mailfrom=router.com;
  dmarc=pass (p=reject) header.from=company.com

Line by line. dkim=pass header.d=company.com: the signature is valid and aligned with the sending domain — perfect. spf=fail: here SPF fails, because the envelope belongs to the router rather than the sender; that's fine, because DMARC only needs one alignment. dmarc=pass (p=reject): despite the SPF failure, the message satisfies DMARC thanks to aligned DKIM. That's the concrete illustration of why DKIM alignment is the workhorse of real-world deployments: it saves authentication where SPF, because of the third-party envelope, doesn't align. Reading this header in full, rather than stopping at the first pass, reveals exactly why a message passes or fails.

When a message carries several signatures

Finding several DKIM-Signature headers on the same message is no cause for surprise — it's common and perfectly legitimate. Many platforms sign twice: once with their own domain, for their own reputation tracking, and once with the customer's, for DMARC alignment. Each signature is verified independently, and Authentication-Results then shows one dkim= verdict per signature. The rule to keep in mind: DMARC only needs one valid, aligned signature to pass. A failing or misaligned signature sitting next to an aligned pass is not a problem to fix — it's just the platform's own signature doing its separate job. When reading headers, the one to locate is the signature whose d= matches the From: domain; that's the one whose fate matters.

When DKIM alone isn't enough

DKIM verifies integrity and origin, but on its own it says nothing about what a receiver should do with an unsigned or spoofed message. That's DMARC's role, which relies on DKIM (or SPF) alignment and applies the published policy. In other words, verifying that a DKIM signature passes is necessary but not sufficient: as long as the DMARC policy stays at p=none, a message spoofing the domain — with no valid signature behind it at all — still reaches inboxes. DKIM verification is therefore one brick of a larger structure; once the signatures are reliable and aligned, the next step is to tighten DMARC to p=reject, so the absence of a valid signature finally has real consequences for impersonators.

Frequently asked questions

Where does a DKIM pass show up? In the received message's Authentication-Results header (dkim=pass/fail), and in aggregate in the DMARC reports. "Show original" in most webmails gives access to the headers.

Is dkim=pass enough? For the signature's validity, yes. For DMARC, no: header.d (the signing domain) must also align with the From:. Both readings are required.

Why does my DKIM fail on some emails only? Often because those messages pass through a list or forward that modifies the body, breaking the hash. Direct sends pass. The profile (lists, low scattered volume) reveals the cause.

Can a third party's DKIM be verified? Its public key is checkable (DNS is public), and the result is readable in the headers of any email it sent. It's useful for diagnosing a partner.

Is an empty p= key normal? No: an empty p= signals a revoked key. Signatures pointing to a selector whose key is empty will fail — the fix is to republish a valid key.

How long before DKIM shows up in reports? DMARC aggregate reports are sent at the end of the reporting period (often 24 hours). The first verified signatures appear the day after activation. At low sending volume, a representative sample may take a few days — which is also why checking directly with dig and an email header viewer is faster for initial validation.

Can DKIM be verified without sending a test email? Partially. dig confirms the public key exists in DNS — that covers the publishing side. End-to-end verification (signature generated, valid, aligned) requires a real message whose headers can be read, or an analyzer that sends a probe and reads the result.

Building verification into the routine

DKIM verification shouldn't be a one-time gesture at configuration time, then forgotten. Three key moments deserve active verification: at activation (confirming the key is published, the signature passes and aligns); after each rotation (confirming the new selector signs correctly and the old one left no failures); and periodically, via the DMARC aggregate reports (confirming every sending source maintains its alignment over time, without silent drift). Aggregate reports are particularly useful because they cover every sending source with no test email needed to each one — a systematic view, domain by domain, source by source. Putting report reading into a monthly routine — even quick, even partial — is the only way to detect a decaying signature before it hits deliverability or DMARC posture. A signature that worked perfectly six months ago can break quietly if a platform changes its defaults, a rotation goes wrong, or a new sending path appears without being configured. Reports catch that drift; manual checks don't scale.

Thomas confirms the signatures

Reading headers by hand for each source is tedious and incomplete. Thomas, the virtual CISO, verifies that each source signs with DKIM, that the signature is valid and aligned with the domain, and flags sources whose signature breaks — lists and forwards aside — before they undermine readiness for p=reject.

Free DMARC analysis of a domain — or an account for continuously verified DKIM signatures.