# How do you test and verify DKIM on a real email?

> DKIM testing, end to end: send a message to a verifier, read the Authentication-Results header, and tell dkim=pass, fail, and none apart.

To test DKIM properly you have to check it on an actual message, not just look up the DNS record. Send a real email to a verifier mailbox or to your own account at another provider, open the received message's headers, and read the `Authentication-Results` line: `dkim=pass` means the signature verified, `dkim=fail` means it did not, and `dkim=none` means the message carried no signature at all. Checking the published key in DNS confirms the record *exists*; sending a test confirms your mail is actually being *signed and verified* in production — which is the thing that decides whether you pass DMARC.

## Quick takeaways

- **DKIM testing has two halves:** confirm the selector's public key is published in DNS, and confirm a live message is signed and verifies. Both must pass.
- The verdict lives in the received message's **`Authentication-Results` header** — read `dkim=pass`, `dkim=fail`, or `dkim=none`.
- The fastest test is to **send a message to a verifier address** (or to yourself at another provider) and inspect the headers it received.
- `dkim=none` means the message was **never signed** — a sending-side problem, not a DNS one.
- **Re-test after every change:** initial setup, key rotation, and each time you add a new sending service.

## How do you test DKIM on a real message?

The only test that matters is on mail your systems actually send, because that is what receivers judge. There are three reliable ways to generate a signed message and read the result:

1. **Send to a verifier mailbox.** Free DKIM/authentication checkers give you a one-time address; you send a normal email to it, and the tool reports `dkim=pass` or `dkim=fail` along with the signing domain and selector it saw. This is the quickest end-to-end check and it also reports SPF and DMARC in one pass.
2. **Send to yourself at another provider.** Mail from your business domain to a personal Gmail or Outlook account, then open the message and view the original/headers. Because the message crossed the public internet and was verified by a real receiver, the result is authoritative.
3. **Trigger a real transactional message.** For an app or [ESP-signed stream](/learning/dkim-google-workspace), fire a genuine password-reset or receipt to a mailbox you control and inspect that. This catches signing problems specific to one sending service that a manual test would miss.

In every case the goal is the same: get a *received* copy of a real message and read what the receiver decided.

## How do you read a DKIM result in the header?

Open the received message and view its raw source — "Show original" in Gmail, "View message source" in Outlook, or the [Email Header Analyzer](/tools/email-header-analyzer) to parse it for you. Find the `Authentication-Results` header the receiving server added:

```
Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourcompany.com header.s=selector1;
  spf=pass smtp.mailfrom=yourcompany.com;
  dmarc=pass (p=REJECT) header.from=yourcompany.com
```

The pieces that matter for DKIM:

- **`dkim=pass`** — the signature verified: the message body and signed headers were not altered in transit, and the public key resolved. This is what you want.
- **`dkim=fail`** — a signature was present but did not verify. The two usual causes are a broken body hash or a key mismatch; see the troubleshooting section below.
- **`dkim=none`** — no DKIM signature was found at all. The receiver had nothing to check.
- **`header.i` / `header.d`** — the signing domain. For DMARC this domain must align with the `From:` domain.
- **`header.s`** — the selector, which points at the exact DNS record (`selector._domainkey.yourcompany.com`) holding the public key.

If you are new to reading these, the [anatomy of an email header](/learning/what-is-an-email-header) breaks down every line around this one.

## Which DKIM testing tools should you use?

Match the tool to the half of the test you are running:

- **To test the DNS side** — that the selector's public key is actually published and well-formed — use a DKIM record lookup. Our guide on [how to check a DKIM record](/learning/check-dkim-record) walks through finding the selector and interpreting a missing or malformed key, and the [DKIM checker tool](/tools/dkim) resolves a selector for you.
- **To test the message side** — that live mail is signed and verifies — use a verifier mailbox or send-to-self, then parse with the [Email Header Analyzer](/tools/email-header-analyzer).
- **To test the whole authentication posture at once** — DKIM alongside SPF and DMARC — run the [Email Security Score](/tools/email-security-score), which flags where any one of the three is missing or misaligned.

A record lookup alone can show a perfectly valid key while your mail still arrives `dkim=none`, because the sending service was never configured to sign. Only a message-level test catches that.

## When should you re-test DKIM?

DKIM is not set-and-forget. Re-run the message test at these moments:

- **After initial setup**, before you rely on it — confirm the first real message shows `dkim=pass`, not just that the record resolves.
- **After a key rotation.** When you [rotate DKIM keys](/learning/dkim-key-rotation), test that mail signed with the new selector verifies before you retire the old key.
- **Whenever you add a sending service.** Every ESP, CRM, or ticketing tool that sends as your domain needs its own signing setup; add one and test that specific stream.
- **Before moving DMARC to enforcement.** A `dkim=pass` that also *aligns* with your From domain is what carries a message through a `p=reject` policy.

## Common issues with DKIM testing

### The test shows dkim=none even though the DNS record exists

`dkim=none` means the message left your sender unsigned, so the published key was never consulted. The record being present in DNS is necessary but not sufficient — the sending platform also has to be switched on to sign outbound mail with the matching private key. Check that DKIM signing is enabled for that specific service and that it uses the selector you published. This is the single most common false sense of security: the record is there, but the mail is not being signed.

### The signature fails with a body hash error

A `dkim=fail` citing a body hash mismatch means something rewrote the message body after it was signed — a mailing list footer, an antivirus or "safe links" gateway, or an ESP that modifies content in transit. The signature covers the exact bytes at signing time, so any later edit breaks it. Our guide on [dkim=fail (body hash did not verify)](/learning/dkim-fail-body-hash-did-not-verify) covers isolating which hop made the change.

### DKIM passes but DMARC still fails

DKIM can verify while DMARC fails, because DMARC also requires **alignment** — the signing domain (`d=`) must match the `From:` domain. A message DKIM-signed by an ESP's own domain passes DKIM but fails DMARC alignment unless you sign with your domain. See [why a DKIM signature fails alignment](/learning/why-does-my-dkim-signature-fail-alignment) for the fix.

### The lookup says no DKIM record found

If the verifier reports the selector does not resolve, the public key is missing, published on the wrong host, or waiting on DNS propagation. Work through [no DKIM record found](/learning/no-dkim-record-found) to confirm the record is on `selector._domainkey.yourdomain` and has propagated before re-testing the message.

## Frequently asked questions

### Can I test DKIM without sending an email?

Only partway. A DNS lookup confirms the selector's public key is published and syntactically valid, but it cannot tell you whether your mail is actually being signed or whether the signature verifies. For that you need a live message and its `Authentication-Results` header.

### What is a good DKIM key length to test for?

A 2048-bit RSA key is the current standard; 1024-bit is considered weak and some receivers discount it. A DKIM record lookup shows the key, so testing is also a chance to confirm you are not still on a short legacy key.

### Why does my message pass DKIM at Gmail but fail after being forwarded?

Forwarding often adds or rewrites headers and can alter the body, breaking the original signature. This is expected DKIM behavior, and it is exactly the case ARC and, ultimately, DMARC alignment across SPF or DKIM are designed to handle. Test forwarded paths separately if forwarding matters to you.

### How long after publishing the record should I test?

Give DNS time to propagate — usually minutes, but allow up to a few hours depending on your provider's TTL. A message test immediately after publishing may report `none` or a lookup failure simply because the record has not spread yet.

## Where Palisade fits

Palisade automates this loop instead of leaving you to send test messages by hand: it deploys and monitors SPF, DKIM, and DMARC across every domain you send from, watches the aggregate reports for streams that are failing or unsigned, and flags alignment gaps before they cost you deliverability. It is the difference between testing DKIM once and knowing it stays green as you add senders and rotate keys. See where your domain stands now with the [Email Security Score](/tools/email-security-score).

## Related reading

- [What is DKIM? DomainKeys Identified Mail explained](/learning/what-is-dkim)
- [How to check a DKIM record and interpret the result](/learning/check-dkim-record)
- [dkim=fail (body hash did not verify): what it means](/learning/dkim-fail-body-hash-did-not-verify)