Your provider already ran the check and made the choice

Every mail provider runs three checks on every message before you see it. Here is the result of the last one you received.

In Gmail, click the small arrow next to to me at the top of any message. A panel opens with a few lines you have probably never read:

mailed-by:  target11013.example-vendor.com
signed-by:  target11013.example-vendor.com
security:   Standard encryption (TLS)

For the unabridged version, the three dots, then Show original, which prints the verdicts themselves:

SPF:    PASS
DKIM:   PASS
DMARC:  PASS

That was computed before the message reached your inbox. It is computed for every message, at every provider worth the name, and has been for years. It is the one piece of information in email that is not a guess.

What the three checks are

SPF asks whether the connecting server was authorised to send for that domain.

DKIM asks whether a cryptographic signature over the message verifies against a key the domain publishes in DNS.

DMARC asks whether either of those lines up with the From: address you are actually shown, under a policy the domain owner published.

There is no threshold, no model, no training corpus, no confidence score. Two people running these checks on the same message get the same answer.

Nobody is hiding it

It is worth being accurate about this, because the interesting problem is not a cover-up.

The panel above is one click from the message. The raw verdicts are two. Other providers may surface fragments elsewhere: an unauthenticated sender sometimes gets a question mark where the avatar goes, a suspected forgery gets a banner, and a message that fails DMARC against a domain publishing an enforcing policy is usually refused at the door.

This is not a complaint about one company. Every major provider behaves roughly the same way, and the reasoning is sound: a reliable decision about the mail is genuinely hard to make with this, and most people have no idea what a signed-by line is telling them. Given a fact that by itself is not enough, putting it out of sight is a perfectly rational thing to do.

The verdict is spent

What you are shown is not the verdict. It is the outcome of a decision that consumed it.

The three results go into a classifier as inputs, alongside hundreds of others: content features, sending-IP reputation, domain age, engagement history, what happened when similar messages reached other people. The classifier emits a placement, inbox or spam folder, and the placement is the interface. The single non-probabilistic input in the pipeline is averaged into an estimate, and the estimate is what lands on your screen.

Which leaves the two questions a person might actually have unanswerable at a glance:

A message in your inbox: did it authenticate, or did it merely score well enough? You cannot tell. Both look identical.

A message in the spam folder: did it fail a check, or did it just look unusual to a model? You cannot tell. Both look identical.

The information needed to separate those was computed on that message and then spent.

Why more disclosure would not fix it

Suppose a provider decided to be maximally forthcoming and put the panel on the screen by default. Look again at what it says.

A notification from your child's school district arrives. It is mailed by, and signed by, a domain you have never seen in your life, because the district sends through a messaging vendor, as almost every institution now does. Every check passes. The message is completely legitimate. What the panel has accurately told you is that a company you cannot name vouched for a message claiming to be from your school.

Now picture a forgery of that same message. A different domain you have also never seen, correctly signing its own mail, passing all three checks, because registering a domain and authenticating your own mail from it is trivial and always has been. In the field you were given, the two are indistinguishable. The field holds a domain, and your question was about a school.

So the provider's instinct is not cowardice. It is a correct reading of what the check produces. SPF, DKIM, and DMARC authenticate a domain, never a person, and no amount of better presentation converts one into the other. The panel offers you two domain names and a note that the last hop was encrypted. All three are facts about plumbing. None of them is an answer to "is this who it says it is", because that answer was never computed by anything, and couldn't be.

But follow that where it goes. Not one provider hands you both the information and the choice, and the reason is not squeamishness about the information. They did make the choice, and they could not have given it to you: it rests on hundreds of tiny signals, none of them decisive, weighed per message at a scale no person could work through. Email never produced a fact clear enough to decide on, so what got built instead is a computation only a machine can run. The decision gets made for you because there is no version of it you could have made yourself.

What you have that the classifier does not

The fact does not become sufficient by changing hands. What changes is what sits beside it.

Your provider is answering your question for you: should this reach you, and can it be believed. It has to answer that for a stranger, about a stranger, across billions of messages, holding nothing but the message itself. The hundreds of signals are there to stand in for the one thing that would settle it and that no provider has. Whether you actually have a child at that school. Whether you bank there. Whether you were expecting the parcel.

You are answering the same question, with the context the classifier spent hundreds of signals trying to approximate. That is not something it lacks through oversight. It is not available to it, at any budget, ever.

So the verdict is genuinely not enough for them and genuinely enough for you, and nothing about the verdict changed.

The exception is first contact. The first time the school writes through a vendor domain you have never seen, you have no context either, and no verdict can supply it. That one does not get guessed at. It gets labelled as unsettled and left with you.

What we do with it instead

The same three checks, run properly, at the boundary where legacy mail crosses into DMCN. They have to happen there: both SPF and DKIM depend on the connecting IP address and on what DNS said at the moment of delivery, neither of which can be reconstructed afterward.

What changes is where the answer goes. It is not scored. It is written into a record, signed with the bridge's key, attached to the message, and verified by your client before anything renders. Every message that arrived from legacy email carries a label naming what the checks produced, and they produce exactly three answers:

Legacy email. DKIM and DMARC both passed. The sending domain authenticated it.

Legacy email, unauthenticated. The checks did not fail. They did not happen. No signature, no published policy, or a soft SPF result. This is a large share of ordinary mail, and the label says so rather than implying fault.

Legacy email, failed checks. DKIM failed, DMARC failed, or SPF hard-failed. Delivered, labelled plainly, and nothing in it renders or loads until you decide.

Three states, attached to the message, on every message, without opening a menu.

What this does not do

It refuses almost nothing. The bridge drops exactly one case outright: a DMARC failure against a domain that publishes an enforcing p=reject policy, which is the unambiguous one, the sender's own domain having declared in advance that such mail is forged. A bad DKIM signature, an SPF softfail, a DMARC failure under p=none: all delivered, labelled, sealed. That is deliberate, for the reason given above. A domain owner who has not opted into enforcement has not authorised anyone to treat failures as fatal, and silently dropping their real mail is the worse error.

The school district problem is ours too. We inherit that limit whole, because it is a property of the checks and not of who runs them. The vendor domain passes for us exactly as it passes for everyone else, and a convincing lookalike passes alongside it. Our label means "this domain authenticated this message" and never "this is the person you think", which is why bridged mail is shown as not end-to-end verified even when every check passed.

What the label does change is what your own decisions are worth. A legacy sender has no key to pin, so adding one to your contacts can only ever record an address, and an address is the part anyone can type. So that entry is honored only on a message the bridge actually authenticated. The same address arriving unauthenticated is always yours to open but can never be fully trusted: you can read it whenever you want, nothing about the sender's standing changes when you do, and the next message asks again, because the doubt is about this message rather than about that person. The verdict is not decoration on top of a decision made elsewhere. It is load-bearing in a decision that is yours.

You are trusting our bridge here, not checking it yourself. We verify the claims on the incoming mail and pass on the result. Your client verifies our signature over that verdict rather than re-running DKIM on the original message, which no longer exists in a checkable form once it has been converted. That buys you a verdict that cannot be altered in transit or fabricated by another peer. And the check itself is deterministic, so what we pass on is not a judgment call: anyone standing where the bridge stood would have got the same answer. What you cannot do is stand there yourself. Mail between two DMCN addresses is a different case: there, the signature belongs to the author, and your client checks it against a key it resolved for itself, with us in the path but not in the trust.

The part worth keeping

The check has been running the whole time. On every message you have ever received, at every provider, producing the only answer in the system that is not an estimate.

And it earns its place in the system. What we'd change is who gets to choose what to do with it.