Skip to the documentation
Knowledge base

Verified sender

A mark beside the sender when the sending domain’s published records line up.

Details

  • Every message you receive carries a Sender checks row under Details, naming what each of the three mechanisms said, whether it passed or not, and who said it. The verdict is computed on arrival from what the receiving relay reported, so it is a record of what happened rather than a check run when you open the message.
  • The verdict is READ, not recomputed. The servers that receive your mail check the signature against the message as it arrived and state the result on the delivery itself, alongside the message rather than inside it; that is what the seal reports. Nothing here re-derives it, because verifying a signature yourself means keeping the original bytes of every message forever, and a mailbox here keeps the parsed thread instead. The tooltip says so rather than letting the seal imply otherwise.
  • A verdict written inside the message is never believed. Authentication-Results is an ordinary header and any sender may write one saying they passed, so a claim carried in a message is shown as a report from a stranger rather than as a finding. The seal is drawn only on verdicts that came in with the delivery, computed by the servers that took the message in, the one part of an arriving message its sender cannot write.
  • DMARC and DKIM, not SPF. SPF fails on every legitimately forwarded message, since the forwarder is not in the original domain’s record, so requiring it would strip the seal from most mail that reaches an inbox through a list or a redirect. A message that passes all three says so on the Sender checks row; one that passes DMARC without the full set says that too, and names whichever mechanism actually broke rather than assuming it was SPF. A DKIM failure alongside a DMARC pass is not treated as a failure at all: DMARC passes on either aligned mechanism, and a signature broken by a mailing-list footer is the ordinary reason for that pair.
  • A phishing verdict outranks it. A compromised account sends perfectly authenticated mail, so the seal is withheld on any message flagged as dangerous: the seal answers whether the domain is who it says, and it is never allowed to soften the warning that answers whether the message is safe.
  • BIMI is not part of the seal, deliberately. Hanging the mark on a published logo would mean a domain that passes everything shows nothing because it never bought one, which is a fact about a marketing budget rather than about mail. The logo is drawn where it belongs, as the sender’s avatar, and it is withheld on a message that did not pass DMARC, because a brand’s own mark beside a forged address is the most persuasive thing a mail client can do for an attacker.
  • No mark means nothing was proven, not that something failed. Mail stored before these checks existed carries no verdict at all, and says “not checked” rather than borrowing a pass it never earned.