SMTP Authentication Troubleshooting: SPF, DKIM, and DMARC Failures

Authentication failures — SPF fail, DKIM fail, DMARC policy violation — appear in the Authentication-Results header of every delivered message and in DMARC aggregate reports every day. When authentication is working correctly, these headers show three passes and require no attention. When authentication breaks — after a DKIM key rotation, an ESP migration, a DNS change, or a new sending source coming online — the failures cascade through delivery quality in ways that are sometimes immediate (DMARC p=reject blocking delivery) and sometimes gradual (authentication failures reducing Postmaster Tools authentication completeness scores over days). This guide documents the diagnostic and remediation approach for each authentication failure type.

Diagnosis First: Reading the Authentication-Results Header

Every authentication troubleshooting session starts with reading the Authentication-Results header from an affected message. Send a test message from the affected sending configuration to a seed address at Gmail and view the full message headers (Gmail: three-dot menu → Show original). The Authentication-Results header shows exactly what the receiving server evaluated and what result each mechanism produced.

Authentication-Results: mx.google.com;
   dkim=fail reason="signature did not verify" header.i=@brand.com header.s=mail;
   spf=pass (google.com: domain of noreply@returns.brand.com designates 203.0.113.45 as permitted sender) smtp.mailfrom=noreply@returns.brand.com;
   dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=brand.com

Reading this header: DKIM is failing with "signature did not verify" — the signing key at header.s=mail (selector "mail") for header.i=@brand.com is not verifying. SPF is passing for the MAIL FROM domain. DMARC is failing because DKIM alignment failed (SPF alignment on the MAIL FROM subdomain may not align with the From: header domain in relaxed mode depending on the specific subdomain). This narrows the diagnosis immediately to the DKIM key: the key is present (the header shows the domain and selector), but it is not verifying — suggesting either a key rotation problem, a DNS propagation issue, or a configuration mismatch.

The Authentication-Results header is the most information-dense diagnostic signal available — it tells you which mechanism failed, why it failed (where the reason is available), and what domain/selector/IP was evaluated. Always start here before running any other diagnostic tool.

SPF Failure: Causes and Fixes

SPF failure means the sending IP is not authorised in the SPF record for the MAIL FROM domain. The Authentication-Results header will show spf=fail or spf=softfail. The most common causes:

New sending IP not added to SPF record: A new ESP added to the sending configuration, a new server IP, or a new MTA deployment where the sending IPs were not added to the SPF record. Fix: add the new IPs or ESP's SPF include mechanism to the SPF record. After DNS propagation (typically 1-4 hours), verify with dig TXT brand.com and test with mxtoolbox.com SPF lookup.

SPF lookup limit exceeded (permerror): The SPF record has more than 10 DNS lookups (each include: mechanism counts as at least one lookup, and the includes themselves may chain further lookups). When the limit is exceeded, SPF evaluation fails with permerror — treated as a neutral result by most ISPs but reduces DMARC alignment reliability. Fix: use MXToolbox's SPF analyzer to count current lookup depth. Flatten the SPF record by replacing include: mechanisms with their constituent IP ranges (SPF flattening tools like SPF Wizard automate this). Keep the lookup count below 8 as a safety buffer.

Wrong MAIL FROM domain: The SPF record is published for brand.com but the MAIL FROM address is noreply@returns.brand.com — SPF evaluates against returns.brand.com, which has no SPF record. Fix: publish a separate SPF record for returns.brand.com, or use include:brand.com in a returns.brand.com SPF record to inherit the parent record.

SPF record syntax error: A typo in the SPF record produces a permerror on evaluation. Fix: validate the SPF record with the MXToolbox SPF check or SPF record testing tools before publishing. Common syntax errors: missing v=spf1 prefix, extra spaces, typos in mechanism keywords (all= instead of ~all or -all).

DKIM Failure: Causes and Fixes

DKIM failure (dkim=fail) means the DKIM signature in the message headers did not verify against the public key published in DNS. The most common causes:

Public key not published or wrong key published: After generating a new DKIM key pair, the public key must be published as a TXT record at selector._domainkey.brand.com. If the record is not published, not yet propagated, or contains the wrong key (e.g., a copy-paste error truncated the base64 data), DKIM verification fails. Fix: verify the DNS TXT record with dig TXT mail._domainkey.brand.com. Compare the p= value in the DNS record with the public key in the DKIM signing configuration. They must be identical. If the DNS record is correct but verification still fails, wait 24-48 hours for full DNS propagation before further troubleshooting.

Key rotation mismatch: After a DKIM key rotation, the signing configuration was updated to use the new private key but DNS still serves the old public key (or vice versa). Fix: during key rotation, publish the new public key in DNS under a new selector before updating the signing configuration. Use the old selector/key for ongoing signing until the new key is verified working. Only retire the old selector after confirming the new key produces verified DKIM signatures.

Message body modification after signing: DKIM signatures cover the message body hash. If anything modifies the message body after signing (a mail gateway adding a footer, a list manager re-wrapping lines, a forwarding service modifying content), the body hash changes and DKIM fails. This is expected behaviour for forwarded messages and is addressed by ARC. For messages within the direct sending path, investigate whether any component between the MTA DKIM signing step and the receiving server is modifying the message body.

Signed header list too restrictive or too permissive: DKIM signatures cover a specified list of headers (h= field). If critical headers (From, Subject, To) are not in the signed header list, spam filters may not treat the signature as meaningful. If headers that downstream systems modify are in the signed header list, the modification breaks the signature. Fix: ensure the DKIM h= field includes From, To, Subject, Date, Message-ID, MIME-Version, Content-Type, List-Unsubscribe. Exclude headers that intermediate systems commonly modify (Received, X-Forwarded-To).

DMARC Failure: Causes and Fixes

DMARC fails (dmarc=fail) when neither SPF alignment nor DKIM alignment passes for the message. DMARC requires at least one of the two authentication mechanisms to align with the From: header domain. The most common causes:

DKIM signing with ESP's shared domain (not own domain): The message is signed with d=esp.com instead of d=brand.com. SPF passes for the MAIL FROM domain but the MAIL FROM may be a subdomain that does not align under strict mode. Result: neither alignment passes. Fix: configure custom DKIM signing with d=brand.com in the ESP settings. This is the most common DMARC failure for new senders who have not yet set up custom domain signing.

MAIL FROM subdomain misalignment under strict DMARC: If the DMARC record specifies aspf=s (strict SPF alignment), the MAIL FROM domain must exactly match the From: header domain — not just the organisational domain. A message with MAIL FROM noreply@returns.brand.com and From: @brand.com fails strict SPF alignment because the domains differ. Fix: change DMARC to relaxed alignment (aspf=r, which is the default) or change the MAIL FROM to match the From: domain exactly.

No DMARC record published: If the domain has no DMARC record, DMARC evaluation shows "none" rather than fail — but the domain does not benefit from DMARC protection and cannot advance to p=quarantine or p=reject. Fix: publish a minimal DMARC record: v=DMARC1; p=none; rua=mailto:dmarc@brand.com.

Alignment Issues: When SPF and DKIM Pass but DMARC Fails

The most confusing DMARC failure scenario: both SPF and DKIM show pass in the Authentication-Results header, but DMARC still fails. This occurs when both mechanisms pass but neither aligns with the From: header domain.

Alignment means: the domain in the DKIM signature (d=) must match the From: header domain (or its organisational domain in relaxed mode), and the MAIL FROM domain must match the From: header domain (or its organisational domain in relaxed mode). A message can have:

• DKIM pass for d=esp.com (the ESP's shared signing domain) — does not align with From: @brand.com
• SPF pass for MAIL FROM bounce@esp-relay.com — does not align with From: @brand.com

Both mechanisms pass (the signatures are valid and the IP is authorised), but neither aligns with brand.com. DMARC evaluates alignment, not just pass/fail — and alignment fails for both. Fix: configure custom DKIM signing with d=brand.com (solves DKIM alignment) and use a MAIL FROM address at brand.com or a subdomain of brand.com (solves SPF alignment in relaxed mode).

Authentication Failures from Email Forwarding

Email forwarding breaks authentication in predictable ways. When a message is forwarded by a mail server (not the original sender): SPF fails because the forwarding server's IP is not in the original sender's SPF record. DKIM may fail if the forwarding server modifies the message body. DMARC fails if both SPF and DKIM fail after forwarding.

This authentication failure cascade from forwarding is expected and is not a misconfiguration problem with the sending infrastructure — it is a fundamental limitation of SPF and DKIM when applied to forwarded mail. ARC (Authenticated Received Chain) is the mechanism designed to address this: ARC-capable forwarding servers attest to the original authentication status before forwarding, allowing receiving servers to evaluate the original authentication chain rather than the post-forwarding result.

From the sender's perspective: if DMARC aggregate reports show authentication failures from specific sending sources that appear to be forwarding services (corporate mail gateways, mailing lists, auto-forwarders), these failures are expected and do not indicate a problem with the sending configuration. The relevant action: ensure ARC-capable forwarding infrastructure is used by the forwarding parties where possible, and monitor that the forwarding-induced DMARC failures do not constitute a significant percentage of total traffic (large percentages of forwarding failures may indicate an unauthorised forwarding configuration that needs investigation).

Verification Tools and Diagnostic Commands

The authentication troubleshooting toolkit:

The diagnostic sequence for any authentication problem: (1) View Authentication-Results header from a test message to identify which mechanism fails. (2) Use the relevant dig command to verify the DNS record is published and contains the expected value. (3) If DNS is correct, use mail-tester.com to do an end-to-end authentication test and check whether the problem reproduces. (4) If the problem reproduces, check for post-signing modification (by an intermediate gateway or content system) by comparing the signed headers against the received headers. (5) Review DMARC aggregate reports to understand the scope of the failure — is it affecting all sending sources or only specific ones?

Prevention: The Authentication Health Checklist

Authentication failures are preventable through systematic verification after every change that could affect the authentication stack. The authentication health checklist — run before any campaign deployment and after any infrastructure change:

Authentication, correctly configured and regularly verified, is invisible — it simply works, every message, for every recipient. Authentication that is misconfigured or has drifted from its correct state produces the failures documented in this guide. Build the verification habit; run the checklist after every change; and authentication will remain one of the operational variables that requires attention only at setup and at configuration change events — not as a source of ongoing deliverability incidents that consume investigation time and reputation recovery effort.