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

You receive an email that claims to be from your bank. The sender name looks right. The logo is the right shade of blue. The link goes to a domain that looks almost like the real one. Before you click anything, you want to know one thing: did this email actually come from the bank?

That is the question DKIM is designed to answer. DKIM, which stands for DomainKeys Identified Mail, is a cryptographic signature attached to every legitimate email by the sending server. The receiving server checks the signature against a public key published in DNS, and if the math works out, it can confirm two things: the email really came from a server authorized to send for that domain, and the body has not been modified in transit.

The catch is that almost no one knows how to actually look at it. Mail clients hide all of this by default. Below is a step-by-step guide for the major mail clients, what the result actually tells you, and the gotcha that most phishing victims fall for.

Step 1: Open the raw source of the email

Every mail client gives you a way to view the raw source. The path is different in each one, but the goal is the same: get to the unprocessed text of the email so you can read the headers the receiving server added.

Gmail (web). Open the email. Click the three-dot menu in the top right corner of the message body (not the inbox toolbar). Select Show original. A new browser tab opens. At the top, Gmail displays a colored summary panel that shows the SPF, DKIM, and DMARC results in plain English. This is the easiest of all the mail clients because Gmail does the work of summarizing for you.

Outlook (desktop). Open the email in its own window. Click File in the top menu, then Properties. The headers appear in a small text box near the bottom labeled Internet headers. Copy the contents to a text editor for easier reading.

Outlook (web). Open the email. Click the three-dot menu in the message header. Select View, then View message source. A modal opens with the raw source.

Apple Mail. Select the email. From the top menu bar, choose View, then Message, then Raw Source. The keyboard shortcut is Option-Command-U.

Thunderbird. Open the email. From the top menu, View then Message Source. The keyboard shortcut is Control-U on Windows and Linux, Command-U on macOS.

ProtonMail. Open the email. Click the three-dot menu, select View headers.

If you use a mail client not listed here, search for "view message source" plus the name of your client. Every mail app has a way to do this even if it is buried in a submenu.

Step 2: Find the Authentication-Results header

Once you have the raw source open, search for the text Authentication-Results:. This is the header that the receiving mail server adds after it checks the email's authentication. It is the single most important line in the entire email, and most users have never read it.

Here is what one looks like for an authenticated email received by Gmail. The example uses RFC 2606 reserved documentation domains (example.com) and an RFC 5737 documentation IP (192.0.2.0/24) so it cannot be confused with any real sender:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s2024 header.b=abc123;
       spf=pass (google.com: domain of bounce@example.com designates
            192.0.2.41 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Three things matter on the DKIM line:

dkim=pass means the email was DKIM-signed and the signature verified. The receiving server fetched the public key from DNS, ran the math, and the signature matched. This is the result you want to see.

header.i=@example.com tells you which domain signed the email. This is the most important detail, and it is the one most readers skip. The signing domain should match the visible "From:" address. If the email visibly claims to be from support@example.com but DKIM passed for header.i=@example-marketing.net, the signature is technically valid but the sender is signing on behalf of a different domain. This is a yellow flag.

header.s=s2024 is the DKIM selector. Senders publish multiple keys in DNS so they can rotate them, and the selector tells the receiving server which key to use. This is useful for debugging but not for trust evaluation.

You may also see other DKIM results: dkim=none means the sender did not sign the email at all. dkim=fail means the sender tried to sign it but the signature did not verify, which usually means either tampering in transit (rare) or a misconfigured forwarder (common). dkim=neutral means the receiving server could not make a determination, often because the public key was missing from DNS.

Step 3: Look at the DKIM-Signature header itself

If you scroll further down in the raw source, you will find a header called DKIM-Signature:. This is the actual signature that the sending server attached. It looks like a wall of text:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=s2024; t=1697654321;
        bh=QTSyMz...;
        h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type;
        b=abc123def456...

You do not need to understand all of it, but a few fields are worth knowing:

d=example.com is the domain that owns the signing key. This is the same as header.i from the Authentication-Results header.

h=From:To:Subject:Date:... is the list of headers that are covered by the signature. If "From" is in this list (which it should be for any reputable sender), then the signature guarantees the From line has not been changed in transit.

b=abc123... is the actual signature bytes, base64-encoded.

The gotcha that catches everyone

Here is the part most people get wrong. The presence of a DKIM-Signature: header does not mean the email is trusted. It only means the sender claimed to sign it.

A phisher can put a DKIM-Signature: header on their own phishing email all day long. They can use a real domain they control (like a freshly registered lookalike) and sign it with a real, valid key they own. The signature will technically pass because the math works out: they really do own the key for the domain they are signing for.

The problem is the domain they are signing for is not the domain they want you to think the email came from. Imagine an attacker who registers example-billing-secure.com as their own domain and configures DKIM correctly for it. They then send you an email signed with that key, but they craft the visible From line to read billing@example.com. The DKIM check passes (because they really do own the lookalike domain they signed with), but the signing domain and the visible domain do not match.

This is exactly what DMARC is designed to catch. DMARC adds an alignment check on top of DKIM: the signing domain has to match (or be a subdomain of) the visible From domain. Without DMARC, a passing DKIM check is not the same as a trusted sender. With DMARC enforcement, it is.

So when you read an Authentication-Results header, the order of importance is:

dmarc=pass is the strongest signal. It means DKIM (or SPF) passed AND the signing domain aligned with the visible From line.
dkim=pass with the signing domain matching the From line is almost as good.
dkim=pass with a mismatched signing domain is suspicious. Look at the visible From line carefully.
dkim=none on an email from a major company is a red flag. Banks, payment processors, and SaaS platforms all sign their email. If they did not, that is unusual and worth questioning.
dkim=fail on an email from a major company is also a red flag, though it can also be caused by a forwarder rewriting the message body. Cross-check the rest of the email carefully.

Why this matters more than people realize

Almost every legitimate sender today signs their email with DKIM. Banks, payment processors, large e-commerce platforms, and almost every SaaS platform you use have valid DKIM signatures on every email they send. When you receive an email that fails DKIM or is missing a signature entirely, the receiving server treats it with suspicion. Most modern spam filters drop unsigned email from suspicious senders directly into the spam folder before you ever see it.

The reverse is also true. When you, as a sender, do not have DKIM set up properly on your own domain, your legitimate emails get flagged as suspicious by everyone you email. Your customers stop receiving your invoices. Your prospects stop receiving your sales messages. The receiving servers are doing exactly what they were designed to do, and your unsigned email is collateral damage.

If you run a domain and you have not checked your DKIM configuration, the easiest way to do it is to send yourself an email from your work address to a personal Gmail address, then follow Step 1 above to read the Authentication-Results header. If you see dkim=none, your domain is not signing email and you should fix that immediately.

Going from per-email to continuous monitoring

Reading raw email headers is fine for a few suspicious messages. It does not scale when you want to know whether your domain's DKIM is healthy across thousands of messages a day, or whether someone is spoofing your domain at scale.

That is what DMARC aggregate reports are for. When you publish a DMARC record with a reporting address, every major mailbox provider (Gmail, Microsoft, Yahoo, and dozens of others) sends you a daily XML report summarizing every authentication check they performed on email claiming to be from your domain. You can see exactly which servers are sending your email, whether their DKIM passed, whether their SPF aligned, and how much volume each one is moving.

The catch is the reports are XML, they pile up in a shared mailbox, and reading them manually is miserable. PhishFence's Email Security add-on parses them for you, identifies known versus unknown senders, and alerts you the moment an unauthorized server starts sending real volume claiming to be your domain. That turns a quarterly compliance check into a continuous monitoring system.

If you want to start with the basics, our DMARC, SPF, and DKIM setup guide walks through how to publish the records correctly the first time, including the safe way to roll out DMARC enforcement without breaking legitimate email.