why DKIM authentication keeps failing after setup

You published the DKIM TXT record. Your DNS provider shows it's live. You send a test email, pull up the headers, and find dkim=fail staring back at you.

I've debugged dozens of these setups. The record looks correct in the registrar dashboard. The mail server is configured to sign. Everything checks out on paper, yet the receiving server says no. The problem is that DKIM failure after setup has at least seven distinct causes, and most diagnostic tools only tell you that verification failed, not which category you're dealing with.

Every one of these failures is fixable once you know where to look. Most take under ten minutes. If you're running agent email workflows and would rather skip DNS debugging entirely, get your agent its own inbox here. LobsterMail handles DKIM signing, SPF, and DMARC automatically so your agent sends authenticated email from minute one.

For everyone else staring at a failed DKIM check, here's what's actually going wrong.

Why DKIM authentication fails after setup#

DKIM authentication can fail even after a correct initial setup. The most common reasons fall into three categories: DNS misconfiguration, message modification after signing, and domain alignment errors.

1. DNS record has not fully propagated (allow 24-48 hours after publishing)
2. Email body or headers modified in transit by forwarding or gateways
3. Wrong or missing DKIM selector in the signing header
4. Outbound security appliance altering the message after DKIM signing
5. DKIM key mismatch between the DNS record and mail server config
6. No DKIM record published for a third-party sending service
7. DKIM signing domain does not align with the visible From address

Each of these looks identical in a basic pass/fail check. The difference is in the details of the authentication results header, which we'll get to below.

DNS propagation and record problems#

The simplest cause is also the easiest to overlook. After you add a DKIM TXT record, DNS propagation can take anywhere from a few minutes to 48 hours depending on your registrar and the TTL of your zone. Running a DKIM check five minutes after publishing the record will often show a failure that resolves on its own by the next morning.

But propagation isn't always the issue. Two other DNS problems come up constantly.

The first is a wrong selector. DKIM records live at selector._domainkey.yourdomain.com. If your mail server signs with selector s1 but your DNS record is published at default._domainkey.yourdomain.com, the receiving server's lookup fails silently. Google Workspace uses google as its default selector. Microsoft 365 uses selector1 and selector2. Your transactional email service likely uses something different. Verify the exact selector your sending service expects, because guessing will cost you hours.

The second is a truncated key. 2048-bit DKIM keys exceed the 255-character limit for a single DNS TXT string. Your registrar needs to split the key into two quoted strings within one record. Some registrar interfaces handle this automatically. Others don't, and you end up with a chopped key that fails verification every single time.

Check your record from the command line:

dig TXT s1._domainkey.yourdomain.com +short
If the output is empty or suspiciously short, that's your answer.

## Message modification breaks the signature

DKIM works by generating a cryptographic hash of specific email headers and (usually) the message body, then signing that hash with a private key. The receiving server re-hashes the message and compares its result against the public key in DNS. If *anything* changes between signing and verification, the hashes won't match.

This is the cause behind the dreaded `body hash did not verify` error.

Three things commonly modify messages after signing.

Email forwarding is the biggest culprit. When a message is forwarded at the server level (think .edu aliases, corporate mail routing, mailing lists), the forwarding server often adds headers, rewrites the envelope sender, or alters the body. The original DKIM signature becomes invalid because the message the recipient's server evaluates is not the message you signed. This is also why DKIM can pass for direct recipients but fail for anyone whose mail routes through an intermediary.

Outbound gateways and security appliances are the second common cause. If your mail flows through a DLP scanner, anti-virus filter, or compliance gateway *after* DKIM signing, any header or body change will break the signature. Organizations that chain multiple mail processing steps before delivery hit this constantly.

Footer injection is the third. Marketing platforms and corporate email systems that append unsubscribe links, legal disclaimers, or tracking pixels after signing cause a body hash mismatch every time.

The fix for all three is the same: DKIM signing must be the *last* step before the message leaves your infrastructure. If you have an outbound gateway that modifies content, reconfigure the signing order so it happens downstream of all modifications.

## DKIM alignment failures

This is the one that confuses people the most. Your DKIM signature can *pass* verification and still trigger a DMARC failure. It happens when the DKIM signing domain (the `d=` value in the DKIM-Signature header) doesn't match the domain in the visible From address.

DMARC checks alignment in two modes. Relaxed alignment requires the signing domain and From domain to share the same organizational domain, so `mail.example.com` signing for `example.com` passes. Strict alignment requires an exact match, so `mail.example.com` signing for `example.com` fails.

This trips up third-party sending services regularly. If you send from `you@yourdomain.com` but the service signs with `d=theirplatform.com`, the DKIM signature itself is valid. DKIM *alignment* under DMARC fails, though, because the domains don't match. The fix is to configure the sending service to sign with your domain, which typically means publishing their provided DKIM key under your domain's DNS zone.

If you're managing [custom domains for agent email](/blog/custom-domains-agent-email), alignment is something to configure once and verify before any agent starts sending.

## How to read DKIM results in email headers

Every email carries its authentication verdict in the headers. Knowing how to read them turns DKIM debugging from guesswork into a five-minute task.

In Gmail, open the message, click the three-dot menu, and select "Show original." Look for the `Authentication-Results` header:
Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.d=yourdomain.com header.s=s1;
  spf=pass smtp.mailfrom=yourdomain.com;
  dmarc=fail

The text in parentheses tells you what went wrong:

• body hash did not verify means the message body was modified after signing. Check for forwarding, gateways, or footer injection.
• signature verification failed or bad signature means the public key in DNS doesn't match the private key used for signing, or the DNS record itself is malformed.
• no key for signature means the receiving server couldn't find a DKIM record at the selector specified in the signature. Verify that selector._domainkey.yourdomain.com exists and returns the correct key.

Note that DKIM can fail while SPF passes. They're independent mechanisms: SPF validates the sending server's IP, while DKIM validates message integrity. A passing SPF result doesn't cover for a broken DKIM signature.

Understanding what email deliverability for AI agents looks like in practice means checking these headers regularly, not only during initial setup.

Multiple sending services each need their own key#

If you send email through several services (your primary mail server, a marketing platform, a transactional sender), each one needs its own DKIM configuration. A common mistake is setting up DKIM for your main mail server and assuming it covers all outbound email from your domain.

Each sending service uses its own private key and selector. You need to publish a separate DNS record for each:

google._domainkey.yourdomain.com    → Google Workspace
k1._domainkey.yourdomain.com        → Mailchimp
smtpapi._domainkey.yourdomain.com   → Transactional service

If even one service lacks a published DKIM record, emails sent through that service fail authentication. And since DMARC evaluates all sending sources for your domain, a single unconfigured service can trigger aggregate report failures. On a p=reject DMARC policy, those messages get dropped entirely.

This is where agent email infrastructure gets interesting. If your agent provisions its own sending identity, it needs its own signing key and DNS records. Managing that across many agents and domains scales linearly in complexity. We wrote about the broader security picture in is your OpenClaw agent's email secure? probably not.

Start with the headers#

If you take one thing from this article, let it be this: check the Authentication-Results header first. The parenthetical text after dkim=fail narrows your debugging from seven possibilities to one specific fix. From there, the solution is usually a DNS correction, a signing-order change, or an alignment tweak. For agent workflows where DKIM maintenance across many domains becomes ongoing operational overhead, that's the exact problem LobsterMail was built to eliminate. Your agent sends email; the authentication is already handled.