The Silent Failure Problem: Your Security Controls Rot Without Telling You

In 2025, URIports analyzed the top one million domains and found that 53.6 percent of BIMI-enabled domains had at least one error preventing their logo from displaying, up from 41.8 percent the year before. More than half of the organizations that paid for a certificate and did the DNS work are getting nothing, and the number is going the wrong way.

Not one of them received an error. There is no bounce, no log line, no email to the domain owner. Gmail simply does not render the logo, and the team that spent $1,400 and three months on it has no idea.

That is not a BIMI problem. It is the defining property of an entire category of security control, and once you learn to recognize it you find it everywhere. It is also the shared weakness of every system in the move toward cryptographic verification I wrote about a few days ago.

The shape of the failure

A control fails silently when three things are true at once:

1. It degrades to no protection rather than to an error.
2. The party who notices the failure is not the party who can fix it.
3. The system it protects keeps working perfectly in the meantime.

That third condition is the cruel one. A loud failure interrupts someone. A silent failure looks exactly like success, and it can persist for years while everyone involved believes they are covered. There is no incident, so there is no investigation, so there is nothing to learn from.

Compare it to a control that fails loudly. A TLS certificate expires and the browser throws a full-page interstitial that your customers see in minutes. That is a bad afternoon and a good design. The failure is impossible to ignore, so it gets fixed within the hour and it never becomes debt.

A tour of the category

These come from very different domains. The shape is identical.

SPF hits eleven DNS lookups. The specification caps evaluation at ten. Exceeding it returns permerror, which receivers treat as no SPF record at all. Your mail continues to deliver. Your authentication is off. The trigger is usually a marketing team adding one more vendor, and nobody who touches that decision knows the ceiling exists.

DMARC parks at p=none. Publishing a monitoring policy feels like shipping a control, and every checker on the internet reports the record as valid and correctly formatted. It protects nothing. Receivers act on p=none by doing exactly what they would have done without it. Organizations sit here for years believing they are covered, which is why the enforcement rollout is the work rather than the record.

An MTA-STS policy expires. RFC 8461 gives you downgrade protection on inbound SMTP by publishing a cached policy over HTTPS. When the policy host breaks or the certificate lapses, senders fall back to opportunistic TLS, which an active attacker can strip. Mail keeps flowing. Nothing alerts.

A DKIM key is rotated at the vendor and not in DNS. Signatures fail. If SPF still passes and aligns, DMARC passes anyway, so delivery is unaffected and the signature layer is quietly gone.

A Content Credential is stripped by your image resizer. You signed the asset. Your CDN converted it to WebP. The manifest is gone, the transform reported success, and the provenance chain you built ends at the moment of publication.

Artifact verification proceeds when the transparency log is unreachable. This one is my favorite, because it is the same bug as SPF permerror wearing modern clothes. Verification tooling that cannot reach the log and chooses to allow the deployment has converted a network problem into a security bypass, invisibly, in the direction of availability.

A signing policy accepts any valid signature. Not a failure of the control. A failure of its configuration, with the same signature: everything reports green, and the policy admits anything anyone in the log has ever signed.

The alerting pipeline stops. The oldest one in the book. A detection rule that stopped matching, a log source that stopped shipping, a webhook whose credentials rotated. Silence is the expected output of a security monitoring system, which means silence is also what total failure looks like.

Why nobody tells you

It is tempting to read this as vendor negligence. It mostly is not. There are structural reasons the feedback channel does not exist.

The receiver has no incentive and no safe way to report. Gmail rejecting your logo cannot tell you why without also telling every attacker probing its display logic what the thresholds are. Detailed verification failures are an oracle. The reticence is deliberate and, from the receiver's position, correct.

The failing party is not the party who suffers. When your SPF breaks, the cost lands on recipients who receive spoofed mail. Your systems are fine. The economic signal that normally drives operational fixes never reaches you.

Fail-open is chosen deliberately, and usually for good reasons. Every one of these systems faced a choice between blocking legitimate traffic during an outage and silently reducing protection. Nearly all chose the second, because the first produces an incident and the second produces nothing. That is a rational engineering decision that aggregates into a systemic blind spot.

The check happens somewhere you do not own. Verification runs on the receiver's infrastructure, on someone else's schedule, against a cache you cannot inspect. You are not in the loop by construction.

How to find your own

Three techniques, in ascending order of effort and value.

1. Read the reporting channels you already have

Several of these standards shipped with telemetry precisely because their designers understood the problem. DMARC has rua aggregate reports. TLS-RPT (RFC 8460) reports TLS negotiation failures. Certificate transparency logs are public and queryable.

These are not compliance artifacts. They are the only feedback loop that exists, and in most organizations nobody has opened them since the week they were configured. If you read one thing after this post, make it last month's aggregate reports.

2. Probe from outside, on a schedule

Every silent control needs a synthetic test that exercises it from the position of a real receiver, on a cadence, with an alert when the result changes.

The rule that matters: test from outside your own trust boundary. The single most common false positive in email verification is checking from a colleague's mailbox on the same tenant, where internal directory data renders something that looks exactly like a working BIMI logo. Teams conclude they are done weeks before they are. Send to a personal account on the actual provider.

The same applies everywhere. Verify your signed artifact from a clean environment with no local cache. Fetch your own image from the CDN at every delivered size and check whether the manifest survived. Query your own agent verification result from an external client.

3. Write down what "off" looks like

For each control, answer one question in writing: if this stopped working right now, what would I observe?

If the answer is "nothing", you have found one. That control needs either a synthetic probe or an explicit decision to accept the risk, and the answer being "nothing" is itself the most useful output of the exercise. I have run this on my own infrastructure and been unhappy with the results more than once.

The design lesson, for anyone building this stuff

If you are shipping a control that other people depend on, you own a decision most designers make implicitly and never revisit: what happens when your verification cannot complete.

Fail-open is often right. An origin that hard-fails on agent verification errors will eventually block the well-behaved crawlers it was built to admit, because key directories go down and drafts change. Failing open there is correct.

Fail-closed is often right too. Artifact verification at deployment admission should refuse when it cannot verify, with a documented break-glass path decided in advance rather than during an incident.

What is never right is failing open without saying so. Whichever you pick, the requirement is the same: the degraded state must be observable by the party who can fix it. A metric, a log line, a report, a header, anything. The absence of that channel is the bug, not the fail-open behavior itself.

This is the same instinct behind not letting an application swallow exceptions, and behind not letting a tool invocation fail quietly in an agent pipeline. We know the pattern. We just keep rebuilding systems where the failure is invisible because the invisible version is the one that ships without an incident report.

The short version

Half of BIMI deployments are broken and their owners believe they work. That statistic is not interesting because of BIMI. It is interesting because it is a measurement of a failure mode we have almost no measurements of anywhere else, and there is no reason to think email is unusual.

Ask the question for every control you own. If it broke, what would you see? Most of the answers will be uncomfortable, and the discomfort is the point.

If you want the layer-by-layer version for email specifically, including which failure belongs to which standard, that is the authentication stack. For the human side, where a silently broken control meets a user trained to look for a badge, start with a framework for defending against phishing.