How to Verify Your DKIM Record Is Working for Domain Emails

You added a DKIM record, waited, and sent a test email. Now comes the honest question: is it actually working, or does it just look right in your DNS panel? A DKIM record can exist and still fail because of a copied character, a wrong selector, or signing that was never switched on. Verifying it properly takes a few minutes and saves you from weeks of quiet spam-folder problems.

This guide shows you several ways to check DKIM, from the simplest test inside Gmail to reading the authentication results in a message header. Use at least two methods, because each one catches a different kind of mistake.

Quick Answer

Send an email from your domain address to a Gmail account you control, open the message, choose the option to show the original message, and look for DKIM with PASS next to it and your own domain listed. If it says FAIL or the line is missing, check that signing is turned on in your mail service, that the selector in DNS matches, and that the full public key was copied without extra spaces.

What a Working DKIM Result Looks Like

DKIM works by signing each outgoing message with a private key held by your mail service. The receiving server finds the matching public key in your DNS, under a name that combines a selector and your domain, and uses it to check the signature. If the message content and key headers match the signature, the result is a pass.

Two details matter when you read any test result. First, the result must be a pass, not just present. Second, the signing domain, often shown as d=, should be your own domain. A pass for a different domain, such as a bulk sender’s shared domain, does not protect your domain’s reputation in the same way.

Method 1: Check the Original Message in Gmail

This is the most useful everyday test because it shows exactly what a real receiver saw.

1. Send a plain test message from your custom domain address to a Gmail address you can open.
2. Open the message in Gmail on a computer, not only in a mobile app, so all options are visible.
3. Open the menu next to the reply button and choose the option to show the original message.
4. At the top, read the summary lines for SPF, DKIM, and DMARC. Each should say PASS.
5. Confirm the DKIM line names your domain, then scroll into the raw headers and find the Authentication-Results line to double-check.

Google explains what these header fields mean in its Gmail help page on checking whether an email is authenticated, which is a good reference the first time you read a raw message.

Method 2: Look Up the DNS Record Directly

A header test proves a message passed. A DNS lookup proves what you actually published, which helps when the header test fails.

1. Find your selector. Google Workspace usually uses google, while other services use names like default, s1, or a longer custom value shown in their settings.
2. Build the lookup name by joining the selector, the word _domainkey, and your domain, for example google._domainkey.yourdomain.com.
3. Use any DNS lookup tool or your registrar’s DNS viewer to request the TXT record at that exact name.
4. Check the result starts with v=DKIM1 and contains a p= value. That p= value is the public key and should be long.
5. Compare the record character by character with the value your mail service gave you, especially at the start and end.

If the lookup returns nothing, the record is at the wrong name, was saved under the wrong domain, or has not propagated yet. If it returns a record with an empty p= value, the key may have been revoked, which is a deliberate way to disable an old key.

Method 3: Send a Test to Another Mailbox Provider

Different receivers report results in slightly different ways, and a second provider can confirm the first result was not a fluke.

• Send the same test to an Outlook or Yahoo address you control and view its message headers there.
• Look for Authentication-Results and a dkim=pass entry naming your domain.
• Send a test through every path you use: your normal mailbox, your website forms, and any newsletter or invoicing tool that sends as your domain.
• Note that each separate service usually needs its own selector and its own DKIM record. One working record does not cover them all.

This step catches a very common surprise. Your main mailbox passes perfectly, while invoices from a separate tool fail because nobody ever set up DKIM for that tool.

Common Reasons DKIM Fails After Setup

Signing was never turned on

Publishing the DNS record is only half the job. In many services, including Google Workspace, you must return to the admin settings after the record verifies and start authentication. Until you do, messages go out unsigned and receivers report DKIM as neutral or missing, not as a pass.

The key was copied incompletely

DKIM keys are long. Copying them through a spreadsheet, a chat window, or a document can add line breaks, strip characters, or change the value quietly. Always copy directly from the service that generated the key into your DNS panel, and compare the ends of both versions.

The record sits at the wrong name

Some DNS panels automatically add your domain to the host field. Typing the full name then creates a doubled domain that no receiver will ever query. Check what the published record is actually called with a lookup, not just what you typed. If you have not published the record yet, follow the full setup steps in our guide about adding SPF, DKIM and DMARC records in GoDaddy and then return here to verify the result.

The message was changed after signing

Some forwarding services and old mailing lists modify the subject or body, for example by adding a footer or prefix. That breaks the signature even though your record is perfect. In those cases the failure is caused by the path the message took, not by your DNS.

How DKIM, SPF, and DMARC Results Connect

Receivers rarely judge DKIM alone. DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. That means a forwarded message can fail SPF yet still pass DMARC through a valid DKIM signature. This is one reason DKIM is so valuable: it survives normal forwarding far better than SPF does. The organisation that maintains the specification describes this relationship in the DMARC overview on dmarc.org, which is worth reading if you plan to move to a strict policy.

When you test, record all three results together. A pattern of DKIM passing and SPF failing on forwarded mail is normal. A pattern of both failing on direct mail is a real configuration problem that needs fixing.

Common Mistakes to Avoid

• Testing with a message sent to yourself on the same service. Internal delivery may skip the checks you want to see. Always test to a mailbox on a different service.
• Checking five minutes after a DNS edit. Give the record time to propagate, then test again before changing anything else.
• Assuming one pass covers every tool. Each sending service needs its own working DKIM setup under its own selector.
• Ignoring a pass for the wrong domain. A pass naming a service’s shared domain does not authenticate your domain.
• Deleting the old record during a key change too early. Keep the old selector published until mail signed with it has had time to be delivered and checked.

Conclusion

Verifying DKIM means proving three things: the record is published at the right name, signing is switched on, and real receivers report a pass for your own domain. Test in Gmail’s original message view, confirm the DNS record directly, and repeat the test for every service that sends as you. Once those checks pass consistently, you can trust DKIM to support your DMARC policy and protect your domain’s sending reputation.

Frequently Asked Questions

Why does my test show DKIM as none instead of fail?

None usually means the message was not signed at all. That points to signing being off in your mail service, or the message being sent by a tool that was never given a DKIM setup, rather than a broken DNS record.

How long should I wait before testing a new record?

Wait at least an hour for typical DNS changes, and longer if your registrar warns of slow propagation. If a lookup tool shows the correct record but Gmail still fails, wait a few more hours and test with a fresh message.

Can I have more than one DKIM record on my domain?

Yes. Each selector holds one record, so google._domainkey and a newsletter tool’s selector can exist side by side. Problems start when two records compete under the same selector name.

Does a DKIM pass guarantee my email avoids spam?

No. DKIM proves identity, not quality. Content, engagement, list hygiene, and your domain’s history still affect spam placement. DKIM is necessary for trust, but it is not a promise of inbox delivery.

What should I do if DKIM passes in Gmail but fails elsewhere?

Compare the Authentication-Results headers from both providers and check whether the failing path involved forwarding or a mailing list that modified the message. If direct messages fail at one provider only, allow more propagation time and retest before editing DNS.