Read the authentication results before changing your email DNS

Nick Potter — Sat, 07 Nov 2026 12:44:34 +0000

When an email authentication check fails, collect evidence from one message before changing DNS. A DNS lookup shows what is published now; a receiver's authentication result describes what it observed while handling that message.

Putting those observations next to each other helps you choose a test instead of changing several unrelated records at once.

Collect a message from the right sending path

Send a test through the application or service that is failing. A message sent manually from your mailbox may use a different route from an automated receipt.

In Gmail, open the message menu and choose Show original. Google documents the steps here. Use the summary and the results added by the receiving mailbox provider; do not treat every Authentication-Results header in the message as equally trustworthy.

The following is an illustrative, abbreviated result, not a captured email:

Authentication-Results: mx.example.net;
    spf=pass smtp.mailfrom=bounce.provider.example;
    dkim=pass header.d=provider.example;
    dmarc=fail header.from=example.com

The result contains two passes and one failure. That is not inherently contradictory.

Read the identities alongside the verdicts

SPF passed for bounce.provider.example. DKIM passed for provider.example. The visible From domain was example.com.

A pass for an unrelated provider domain does not establish an aligned pass for the visible domain. DMARC evaluates that relationship. The DMARC alignment specification explains the distinction.

For this example, the next investigation is the provider's custom-domain authentication setup. Blindly adding more SPF includes to example.com may not address the identity the receiver actually checked.

Use the DKIM signature to choose a DNS query

A DKIM-Signature header contains a signing domain, d=, and selector, s=. Suppose it says:

d=example.com; s=mail2026;

Query the corresponding public key name:

dig +short TXT mail2026._domainkey.example.com

Do not guess the selector from your company name. Copy it from the provider configuration or a message produced by that provider. A key appearing in DNS still does not tell you whether the receiver verified this message successfully. RFC 6376 describes the signing and verification process.

Turn the observations into a test plan

Use a short investigation log:

Observation	Next check
SPF result mentions an unexpected domain	Check the configured envelope sender or custom Return-Path
DKIM domain is the provider's domain	Check whether custom-domain signing is enabled
Key lookup is empty	Recheck the exact domain, selector, record type, and public DNS answer
Authentication passes but delivery is poor	Investigate reputation, complaints, content, and receiver feedback

Record one hypothesis and make one justified change at a time. Keep the original message, the DNS answers, and the new test result together. That makes it possible to explain why a change helped instead of merely remembering that the problem disappeared.

A useful authentication investigation ends with a reproducible result for the intended sending route. Inbox placement remains a separate question; Google's sender guidelines cover requirements beyond authentication.

Header examples are fictional and use reserved example domains. Review against your provider's current instructions before changing production DNS.

DEV Community: Nick Potter

Read the authentication results before changing your email DNS

Collect a message from the right sending path

Read the identities alongside the verdicts

Use the DKIM signature to choose a DNS query

Turn the observations into a test plan