Read the authentication results before changing your email DNS

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:

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.

This article was prepared with AI assistance. Header examples are fictional and use reserved example domains. Review against your provider's current instructions before changing production DNS.