A misconfigured DKIM record does not always announce itself. Mail can keep flowing for months while DKIM silently fails in the background, and the first sign of trouble is often a spike in DMARC failures or a client complaining that legitimate email is landing in spam. Getting DKIM right the first time, and catching drift before it causes damage, comes down to checking a handful of specific things rather than assuming the setup works because nothing looks broken. These seven steps cover what to check, why it matters, and how to verify it.
Quick checklist: what to verify
|
Step |
What you’re checking |
Why it matters |
|
1. Selector and DNS record |
The DKIM selector resolves to a published TXT record |
No record means no valid signature, full stop |
|
2. Record syntax |
Tags (v=, k=, p=) are correctly formatted |
Malformed records fail silently at some receivers |
|
3. Public key match |
The DNS public key matches what your mail server signs with |
Mismatched keys cause universal DKIM failure |
|
4. Live signature test |
A real sent email carries a valid DKIM-Signature header |
Confirms signing is active, not just configured |
|
5. Key length and algorithm |
RSA key is 2048-bit, not the deprecated 1024-bit |
Short keys are a known weak point flagged by major receivers |
|
6. DMARC alignment |
The d= domain in the signature matches the From: domain |
Misalignment fails DMARC even with a valid DKIM signature |
|
7. Ongoing monitoring |
Pass rates are tracked across every sending source |
New senders and vendor changes break DKIM without warning |
Before we dive in, it’s worth running a free DKIM checker, tools like Red Sift Investigate take just 30 seconds with a real email and take out all the hassle of the manual checks.
1. Confirm your DKIM selector resolves in DNS
Every DKIM signature references a selector, the short string that tells a receiving mail server where to find your public key in DNS. The selector lives in the DKIM-Signature header as the s= tag, and it points to a TXT record at [selector]._domainkey.[yourdomain].com.
Start by identifying every selector your organization uses. Larger organizations often run more than one, especially when a marketing platform, a CRM, and an internal mail server all send under the same domain with separate keys. Query each selector’s DNS record directly using a command line tool or an online DNS lookup. If the query returns nothing, that selector has no valid DKIM record and any mail signed with it will fail authentication at any receiver that checks DKIM.
2. Check the record syntax carefully
A DKIM TXT record is a set of tag-value pairs, and small syntax errors break the whole record even when the intent is correct. The record should include v=DKIM1 as the version tag, k=rsa for the key type, and p= followed by the base64-encoded public key with no line breaks or extra whitespace inside the key itself.
A common failure comes from DNS providers that split long TXT records into multiple quoted strings and concatenate them incorrectly, or from a key that was copied with trailing characters or truncated during a copy-paste. If the record looks correct on inspection but authentication still fails, paste the raw record into a DKIM record validator rather than checking it by eye. Malformed records do not always throw an obvious error. Some receivers fail the signature quietly and simply mark the message as unauthenticated.
3. Verify the public key matches your signing key
DKIM works as a public-private key pair. Your mail server or sending platform signs outgoing messages with a private key, and the public key published in DNS lets receivers verify that signature. If these two keys do not match, every message will fail DKIM regardless of how correct the DNS record looks.
This mismatch happens more often than expected, usually after a platform migration, a key rotation that only updated one side, or a sending service that regenerated its key pair without notifying the domain owner. Confirm with your email service provider which private key is currently active, and cross-check the corresponding public key against exactly what is published in your DNS record. If you manage multiple sending platforms under one domain, do this for each one separately since they typically use different selectors and different key pairs.
4. Send a real test email and inspect the signature
DNS records and configuration screens tell you what should happen. A live test tells you what actually happens. Send a test email through each system that sends mail on your domain, marketing platform, transactional email service, and any internal mail server, and view the full message headers on the receiving end.
Look for the DKIM-Signature header and confirm three things: it is present at all, the d= domain matches your sending domain, and the signature validates. Most major webmail providers show an authentication summary (something like “DKIM: PASS”) if you view the original message source. A missing signature means the sending system is not signing outbound mail at all, which is a configuration issue on the sending side rather than a DNS problem.
5. Check your key length and algorithm
Not all valid DKIM records are equally secure. Keys shorter than 2048 bits, including the older 1024-bit standard, are considered weak by current standards and several major receivers have begun treating short keys with reduced trust or outright rejection. If your DKIM key was set up several years ago and never rotated, there is a reasonable chance it is still using a 1024-bit key.
Check the key length by decoding the base64 public key in your DNS record, or by using a DKIM inspection tool that reports key size directly. If you find a 1024-bit key, plan a rotation to 2048-bit as a priority. Rotating a DKIM key requires publishing the new public key alongside the old one temporarily, switching your sending system to sign with the new private key, and then removing the old record once you’ve confirmed mail flow has fully switched over.
6. Confirm DKIM alignment with your DMARC policy
A valid DKIM signature is not the same as DKIM alignment, and this distinction trips up a lot of otherwise correct setups. DMARC checks whether the domain in the DKIM signature’s d= tag matches (or is a subdomain of) the domain in the visible From: address. If a third-party sender signs mail with their own domain rather than yours, the signature can be completely valid and still fail DMARC because it is not aligned.
This is especially common with marketing platforms and transactional email services that use their own default DKIM signature instead of a custom one set up under your domain. Check your DMARC aggregate reports (RUA) for entries showing “dkim=fail” alongside a valid underlying signature. That combination is the signature of an alignment problem rather than a broken key. Tools like Red Sift OnDMARC parse these aggregate reports automatically and flag alignment failures by sending source, which turns a manual XML-reading exercise into a source-by-source breakdown you can act on directly.
7. Monitor DKIM continuously, not just at setup
DKIM configuration is not a one-time task. Sending sources change constantly: a new marketing tool gets added, a vendor migrates infrastructure and rotates keys without telling anyone, or a key expires on a schedule the original setup team never documented. Any of these can break DKIM quietly while every other part of your email program keeps working normally.
Ongoing visibility matters more than the initial setup. Red Sift OnDMARC provides continuous DKIM and DMARC monitoring across every sending source tied to a domain, surfacing new or unauthorized senders and tracking pass rates over time so a broken key gets caught in days rather than being discovered months later in a bounce report or a phishing complaint. For organizations managing DKIM across dozens of sending platforms, a monitoring layer like Red Sift’s DNS Guardian also tracks DNS record changes directly, which catches accidental deletions or overwrites during routine domain management.
How to choose the right verification approach
Manual checks work fine for a single domain with one or two sending sources, and the steps above cover that case completely using free DNS lookup tools and a test email. The picture changes for organizations with multiple business units, marketing platforms, and third-party vendors all sending under variations of the same domain. At that scale, DKIM selectors multiply, key rotations happen on different schedules across different teams, and nobody has full visibility into every sending source at once.
The decision point is really about frequency and scale. If DKIM setup happens once and rarely changes, manual verification on a periodic schedule (quarterly is a reasonable cadence) catches most problems. If your organization onboards new senders regularly, automated monitoring that flags authentication failures and new sending sources as they appear removes the risk of a multi-week gap between something breaking and someone noticing.
Compliance requirements also shape the right approach. Organizations working toward a DMARC policy of p=reject need very high confidence that DKIM is correctly aligned across every legitimate sender before enforcement, since a missed sender at that stage means real mail gets blocked rather than just flagged.
Your DKIM setup questions answered
What does it mean when DKIM shows as “neutral” instead of “pass” or “fail”?
A neutral result means the receiving server found no DKIM signature to evaluate at all, which usually means the sending system isn’t signing outbound mail rather than signing it incorrectly. Check the sending platform’s configuration first, since this points to signing not being enabled rather than a broken key.
Can DKIM pass but DMARC still fail?
Yes, and this is one of the most common points of confusion in DKIM troubleshooting. DKIM validates the signature itself, while DMARC additionally checks that the signing domain aligns with the visible From: domain, so a technically valid signature from an unaligned domain passes DKIM but fails DMARC.
How often should a DKIM key be rotated?
Most security guidance recommends rotating DKIM keys annually, though there’s no universal requirement and some organizations rotate more frequently for higher-risk domains. The more important habit is documenting when each key was last rotated so a rotation schedule doesn’t quietly lapse for years.
Does every sending platform need its own DKIM selector?
Using a distinct selector per sending platform is best practice because it lets you rotate or revoke one platform’s key without affecting any other sender on the domain. Sharing a single selector across multiple platforms makes it harder to isolate which sender caused a failure.
Will a missing DKIM record definitely send email to spam?
Not necessarily on its own, since SPF can still pass and many receivers weigh multiple signals, but a missing DKIM record removes one authentication layer and makes DMARC alignment impossible for that sender. Combined with a strict DMARC policy, a missing DKIM record on a given sending source can result in that source’s mail being rejected or quarantined outright.
Is a 1024-bit DKIM key still considered acceptable?
No, 1024-bit keys are considered weak by current standards and some major receivers now treat them with reduced trust. Any DKIM key still using 1024-bit should be rotated to 2048-bit as a priority rather than left in place until the next scheduled review.
Can DKIM be checked without sending a test email?
DNS-level checks (record presence, syntax, and key match) can be done without sending mail, but confirming the signature is actually applied to outbound messages requires a live test. Configuration can look correct in DNS while the sending system still isn’t applying a signature in practice.
What’s the fastest way to check DKIM across many sending sources at once?
For a handful of sources, checking each selector’s DNS record and reviewing DMARC aggregate reports manually is workable. For domains with many sending platforms, a monitoring tool that parses aggregate reports automatically and flags failures by source removes the need to read raw XML reports one at a time.
