Email authentication failure: diagnose the right layer

An email authentication failure is not one diagnosis. It can be an SPF result for the envelope sender, a DKIM signature that did not verify, a DMARC alignment failure, or a receiver policy decision reported beside those results. Preserve the failed message and its full headers first. Then follow the identity that actually failed. A public DNS check is useful, but the receiver's result on the same message is the evidence that closes the loop.

Quick takeaways

• Save the complete bounce and headers before changing DNS.
• Identify the exact SPF, DKIM, or DMARC result that failed.
• Check the domain and selector named in the message, not a guessed domain.
• Repair the smallest proven fault instead of weakening every policy.
• Retest through the same sender, route, and receiver.

What does the failure mean?

If the error appeared while a mail app was signing in or submitting the message, start with the mailbox and SMTP login authentication workflow. That pre-submission problem uses account, client, and server evidence rather than receiver SPF, DKIM, or DMARC results.

Authentication results describe separate checks. SPF evaluates whether the connecting IP is authorized for a MAIL FROM or HELO identity. DKIM verifies a signature against the public key named by its d= domain and s= selector. DMARC asks whether at least one passing SPF or DKIM result aligns with the visible From domain.

The receiver normally records these outcomes in Authentication-Results. RFC 8601 defines that field and warns that a result must be interpreted inside the receiver's trust boundary. A copied header can be forged, so start with headers added by the mailbox system that accepted the message.

Source: Palisade diagnostic graphic based on RFC 8601, RFC 7208, RFC 6376, and RFC 9989.

This separation matters because a message can show spf=pass and still fail DMARC when the SPF identity does not align with the visible From domain. It can also show dkim=pass for a provider domain that does not align. The broad email authentication explainer covers how the protocols fit together; this guide starts after a receiver reports a problem.

What usually causes it?

The receiver evaluated a different SPF identity

SPF commonly checks the return-path domain, not the address a person sees in From. A sender may publish a healthy SPF record at the organizational domain while the live service uses a different MAIL FROM domain. Forwarding can also change the connecting IP without changing the original message.

RFC 7208 defines fail, softfail, temperror, and permerror as different results. Treat them differently. A permanent syntax or lookup problem needs an operator change. A temporary DNS error may succeed later. A hard fail means the evaluated client was not authorized by the published policy, but final message disposition remains receiver policy.

The DKIM selector or signature path is wrong

DKIM failures often come from an unpublished selector, a public key that does not match the active private key, or content changed after signing. Mailing lists, gateways, footers, and link rewriting can alter signed body or header fields. A record found under one selector says nothing about a message signed with another.

RFC 6376 makes the selector and signing domain part of the signature. Use the exact s= and d= values from the failed message. If the signature reports a body-hash mismatch, repeatedly editing DNS will not repair the changed content.

SPF or DKIM passes without DMARC alignment

DMARC evaluates the relationship between an authenticated identifier and the visible From domain. A third-party platform can pass SPF with its own return path and pass DKIM with its own signing domain while still leaving the customer's From domain unaligned.

RFC 9989 is the current DMARC core specification. It requires an aligned pass through SPF or DKIM for a DMARC pass. When SPF and DKIM both pass while DMARC fails, compare their authenticated domains with the visible From domain.

The message passed authentication but hit receiver policy

Not every 5.7.x rejection is an authentication failure. The adjacent response text may point to reputation, content, rate, TLS, local policy, or an administrator rule. Preserve the whole SMTP response, including the receiver name and any provider-specific subcode. Do not rewrite SPF or DMARC solely because a bounce contains the word "policy."

How do I diagnose the failure?

1. Preserve one failed transaction

Save the complete SMTP reply, message ID, UTC timestamp, recipient domain, sending application, envelope sender, visible From address, and full headers when available. Redact personal content in tickets, but keep protocol fields intact.

Use a message from the path that is failing. A successful test sent manually from a different mailbox does not validate a marketing platform, billing system, or support desk.

2. Read the trusted receiver result

Locate the receiver-added Authentication-Results field. Record each result and its identity:

spf=fail smtp.mailfrom=returns.example.net
dkim=pass header.d=mailer.example.net header.s=s1
dmarc=fail header.from=example.com

This sample shows why "SPF failed" is incomplete. It identifies returns.example.net as the SPF domain, mailer.example.net as the DKIM signing domain, and example.com as the DMARC From domain.

3. Check the named public records

Use the SPF checker for the exact MAIL FROM domain and the DKIM checker for the exact signing domain and selector. Check _dmarc. with the DMARC checker.

Record what public DNS returns, including CNAME targets, multiple TXT answers, lookup errors, and TTL. A clean lookup establishes what is published now. It does not reconstruct what a receiver saw earlier, prove that the sender used a private key, or validate a message that the tool never received.

Use Palisade's Email Security Score only after the failed identities have been extracted from the message. That keeps the first broad check tied to the evidence instead of a guessed domain or selector.

4. Map the result to the responsible owner

Assign the failed layer before changing it. The DNS owner can fix a wrong public record. The sending-service owner can activate signing, choose a custom return path, or provide account-generated records. A gateway owner can stop modifying signed content. The application owner can move traffic to an authenticated domain.

If two teams share a record, write down which exact value each team controls. This avoids a common loop where the DNS team republishes the same correct key while the sender continues using a different private key.

5. Reproduce through the same path

Send a new message from the same application, region, stream, From domain, and routing chain to a mailbox where you can inspect trusted headers. Compare the new result with the saved failure. If the receiver differs, treat the test as supporting evidence rather than a perfect reproduction.

How do I fix it?

Fix the proven layer only. For SPF, add or correct the legitimate service in the one policy used by the live MAIL FROM domain, then keep the DNS-query limits defined by RFC 7208 in view. Do not create a second SPF record.

For DKIM, use the sender's account-generated selector and public value. Publish it at the authoritative DNS host, verify that it resolves, and activate the matching private key in the sender. Never invent a replacement public key unless you also control the paired private key and the sender configuration.

For DMARC alignment, give the legitimate service an aligned DKIM signing domain or an aligned custom MAIL FROM path. Do not change p=reject to p=none as the automatic first move. A temporary rollback can be justified when verified legitimate mail is being lost and the organization has an explicit owner, monitoring window, and restoration condition.

For receiver policy, follow the exact provider guidance in the SMTP text. Authentication changes will not repair an invalid recipient, low IP reputation, prohibited attachment, rate spike, or a custom inbound rule.

How do I validate the repair?

Validation needs more than one green DNS card:

• Public DNS returns the intended record from an external resolver.
• The sending platform reports the domain or selector as verified when that state exists.
• A new production-path message shows the expected smtp.mailfrom, header.d, selector, and visible From domain.
• The trusted receiver result shows the repaired mechanism and DMARC alignment.
• A later aggregate-report window confirms the legitimate source at expected volume.

Source: Palisade retest matrix based on the protocol evidence boundaries in RFC 7208, RFC 6376, RFC 8601, and RFC 9989.

Keep the original failure and the successful retest in the same incident record. If the DNS check passes but the message still fails, stop editing DNS and return to sender use, routing, or post-signing modification.

Palisade's focused tools can inspect the public SPF, DKIM, and DMARC layers separately. Those lookups cannot read private keys, inspect an unseen production message, or guarantee delivery. They are most useful after the failed identities have been extracted from real evidence.

When the incident exposes an ongoing monitoring or ownership gap, Palisade's DMARC Agent turns DMARC report findings into source-specific authentication tickets and recommended actions. It cannot reproduce a receiver's private decision or prove a message that does not appear in the available evidence. Start with Palisade only after that recurring operating need is clear.

Sources and further reading

• RFC 8601: Authentication-Results
• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 9989: DMARC core specification