Sender Identity

Home · Troubleshoot · Sender identity

Email authentication · Sender warning

We could not verify the identity of the sender

6 November 2026

“We could not verify the identity of the sender” means a mailbox or security gateway could not establish that the message really came from the visible From domain. The exact wording varies by product and it is not always a bounce code. Treat it as a warning to inspect, not proof by itself that the message is forged.

What the receiver is trying to verify

Receivers commonly compare the visible From domain with the result of SPF or DKIM. An authentication pass is not enough if it belongs to a different domain. DMARC ties a passing SPF or DKIM result to the From domain:

The warning may come from a mailbox provider’s sender-verification feature, a security gateway, or a forwarding service. Find the original message headers before assuming the cause. A forwarded copy can fail on delivery even when the original sender’s DNS is correct.

Fix path for the sending domain

  1. Identify the exact visible From domain on a failing sample, not only the Return-Path or envelope sender.
  2. Read the original headers and locate Authentication-Results. Record the result domains for SPF, DKIM, and DMARC.
  3. Run the free static audit on the visible From domain. Check for missing or duplicate SPF, missing DKIM selectors, and a missing DMARC record.
  4. Authorize the correct sending infrastructure and make DKIM sign with a domain that aligns with From. Follow the setup for Google Workspace or Microsoft 365 or your ESP.
  5. If DKIM reports a body-hash or signature failure, fix message rewriting at the gateway or list manager first. See DKIM body hash did not verify.
  6. Publish DMARC with a reporting address, start at p=none if enforcement is not ready, then use aggregate reports and the staged transition to reject.
  7. Send a fresh test to the same receiving environment and re-read its headers. DNS fixes do not change a message that has already failed.

If SPF or DKIM says “pass”

Look at the domain beside each pass. This is a common reason a warning survives an apparently healthy DNS setup:

Setting DMARC to p=none requests monitoring; it does not make an unverified sender trustworthy. Moving to quarantine or reject can change delivery when aligned authentication fails, but only after legitimate senders are inventoried. Read DMARC alignment failed if the pass domains still do not match.

If you received the warning

Do not use the message’s contact details to confirm the sender. Contact the person or organization through a known website, phone number, or account, especially when the message requests money, credentials, or changes to payment instructions. If you administer the receiving mailbox, preserve the original headers and ask the sender’s mail team for their sending domain, ESP, DKIM selector, and the exact failure result.

What this page cannot tell you: a public DNS audit cannot read the headers of one delivered message, prove that a particular message is genuine, or override the receiving provider’s decision. It can show whether the published authentication records and selectors give the receiver something valid and aligned to evaluate.