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.

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

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.

At a glance

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:

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.
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.
Trigger a real transactional message. For an app or ESP-signed stream, 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 to parse it for you. Find the Authentication-Results header the receiving server added:

Technical exampletext

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 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 walks through finding the selector and interpreting a missing or malformed key, and the DKIM checker tool 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.
To test the whole authentication posture at once — DKIM alongside SPF and DMARC — run the 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, 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) 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 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 to confirm the record is on selector._domainkey.yourdomain and has propagated before re-testing the message.

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.