How to verify the DKIM signature of an email

You've enabled DKIM, published your key, and now you want the question that really matters: does it work? Verifying a DKIM signature means confirming that a message was indeed signed, that the signature is valid, and — for DMARC — that it aligns with your domain. This guide shows where to read the result, how to interpret the signature's tags, how to check it yourself, and why a legitimate signature can sometimes fail.

The simplest method: read Authentication-Results

You don't need to redo the cryptographic math by hand: the receiving server already did it, and it writes its verdict in a message header, Authentication-Results. Open an email you sent (in an inbox that isn't yours) and show its full headers (often "Show original" or "View source"). Look for a line like:

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

Three key pieces here: dkim=pass (the signature is valid), header.d=your-domain.com (the signing domain — check it's yours), and dmarc=pass (the whole thing aligns and satisfies DMARC). If dkim=pass but header.d is a provider's, your signature is valid but not aligned — it doesn't count for DMARC.

Read the DKIM-Signature header

To go further, look directly at the message's DKIM-Signature header. It contains several tags:

• d= — the signing domain. This is what must align with your From: for DMARC.
• s= — the selector, pointing to the public key to use (see the selector).
• h= — the list of headers covered by the signature.
• bh= — the hash of the message body.
• b= — the cryptographic signature itself.

The receiver fetches the public key at s=._domainkey.d=, recomputes the hash of the body and signed headers, and compares with b=. If everything matches, dkim=pass. This mechanism explains most failures (see below).

Verify it yourself, without waiting for an email

You can check half the equation without even sending a message: the public key. Query the selector in DNS:

dig TXT selector._domainkey.your-domain.com

You should find 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 your key, and, paired with your reports, the real alignment of your sources.

Alignment: the only thing that matters for DMARC

Let's repeat it, 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 your 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 your aggregate reports, source by source. For the full concept, see how the three protocols work together.

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 your 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 to not panic at isolated DKIM failures clearly coming from forwards: look at the volume and the source before concluding there's a problem.

Dissecting a full Authentication-Results

This header condenses the verdict of all three mechanisms, and knowing how to read it saves you a lot of guessing. Take 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

Let's decode it. dkim=pass header.d=company.com: the signature is valid and aligned with your domain — perfect. spf=fail: here SPF fails, because the envelope belongs to the router, not you; 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, tells you exactly why a message passes or fails.

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 your policy. In other words, verifying that your DKIM signature passes is necessary but not sufficient: as long as your DMARC policy stays at p=none, a message spoofing your domain — with no valid signature from you at all — still reaches inboxes. DKIM verification is therefore one brick of a larger structure; once your 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 do I see if DKIM passes? In the received message's Authentication-Results header (dkim=pass/fail), and in aggregate in your 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 your From:. Always check both.

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 I verify a third party's DKIM? You can check its public key (DNS is public) and read the result in the headers of an email it sent you. It's useful for diagnosing a partner.

Is an empty p= key normal? No: an empty p= signals a revoked key. If your signatures point to a selector whose key is empty, they'll fail — 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). Expect to see the first verified signatures the day after activation. If your sending volume is low, it may take a few days to get a representative sample — which is also why checking directly with dig and an email header viewer is faster for initial validation.

Can I verify DKIM without sending a test email? Partially. You can confirm the public key exists in DNS with dig — that covers the publishing side. For end-to-end verification (signature generated, valid, aligned), you need a real message to read headers from, or an analyzer that sends a probe and reads the result.

Building verification into your routine

DKIM verification shouldn't be a one-time gesture at configuration time, then forgotten. Three key moments deserve active verification: at activation (confirm the key is published, the signature passes and aligns); after each rotation (confirm the new selector signs correctly and the old one left no failures); and periodically, via your DMARC aggregate reports (confirm all your sending sources maintain their alignment over time, without silent drift). Aggregate reports are particularly useful because they cover all your sending sources without you having to send a test email to each one — they give you 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 impacts your deliverability or your 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.

Let Thomas confirm your signatures

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

Analyze your domain for free → or create an account for continuously verified DKIM signatures.