Skip to main content
How-to DKIM

How to Check if an Email Is DKIM Signed (and Why It Matters)

DKIM is one of the three pillars of email authentication, but most people have never opened a raw email to verify a signature. Here is exactly how to check, what the result actually means, and how phishers exploit the gaps.

April 10, 2026 · 8 min read

TL;DR

  • 1 Look for the DKIM-Signature header in the raw email; d= names the signing domain, s= names the selector.
  • 2 A pass result in Authentication-Results shows the receiver verified the signature against the published public key.
  • 3 If DKIM passes but d= doesn't align with the visible From, DMARC will still fail: alignment matters, not just pass/fail.

What it does

DKIM cryptographically signs each outbound message so receivers can verify two things: the message wasn't tampered with in transit, and someone with the private key (presumed to be your domain's mail infrastructure) authorized it. Without DKIM, a forwarded copy of your email or a tampered version can pass SPF only to fail DMARC alignment.

Receivers verify the signature by fetching the public key from DNS at <selector>._domainkey.<your-domain>. The signing domain (d=) and selector (s=) are in the DKIM-Signature header on every signed message. A DKIM-pass result feeds DMARC's alignment check: if the signed d= matches your visible From domain, the message passes DMARC even when SPF fails.

Checking whether a message you sent (or received) is DKIM-signed takes 30 seconds in any modern mail client: open the raw source, look for the DKIM-Signature header, then look for dkim=pass in the Authentication-Results header to confirm the receiver actually verified it.

How it works

  1. 1

    Open the raw email source. Gmail: ⋮ menu > Show original. Outlook: File > Properties > Internet Headers (then View Source for the body). Apple Mail: View > Message > Raw Source.

  2. 2

    Find the DKIM-Signature header. It starts with DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourbrand.com; s=selector1; t=.... The d= tag is the signing domain; s= is the selector.

  3. 3

    Check the Authentication-Results header. The first dkim= result is the verdict: dkim=pass = receiver verified the signature, dkim=fail = signature didn't validate, dkim=none = no signature was present.

  4. 4

    Verify alignment. Compare the d= from the DKIM signature to the domain in the visible From: header. If they match (or share the same org domain under relaxed alignment), DMARC passes via DKIM.

  5. 5

    Look up the public key in DNS. dig +short TXT <selector>._domainkey.<d>. The record should be present and start with v=DKIM1;. PhishFence's DKIM checker does the same lookup in the browser.

Common pitfalls

  • Looking for the wrong header on a forwarded message. Forwarding strips or rewrites DKIM-Signature in many MUAs. To check the original sender's DKIM, look at the message as delivered to the first receiver, not the forward.

  • Trusting dkim=pass without checking alignment. An ESP signing with its own domain (d=sendgrid.net) produces a pass result but won't align with your From:, so DMARC still fails. The pass alone is not enough.

  • Confusing DKIM-Signature with X-Sender / X-Original-From. Many ESPs add their own X-headers that mention the original sender. Those don't carry cryptographic authority; only DKIM-Signature does.

  • Reading the Authentication-Results header from a forwarder, not the original receiver. Some MTAs prepend their own A-R header to messages they relay, so the newest (topmost) A-R reflects the last hop, not the original send. The DMARC-relevant one is the LAST/lowest Authentication-Results header in the raw source, the one closest to (added by) the original receiving server, before any forwarding.