What breaks

What breaks

After this lesson you can

Name the failure each advanced control introduces, and how it presents.

Assumes you have read The order to adopt in.

Each control adds a way for mail to fail that did not exist before. Two of them can stop inbound delivery entirely, and both do it quietly enough that you will hear from a sender rather than from a monitor.

What each one adds

Control	New failure	How it presents
MTA-STS	Enforcing senders refuse a host the cached policy does not list	Deferrals then bounces from Google and Microsoft only. Other senders unaffected, so it looks like a problem with them.
MTA-STS	Policy host certificate expires	Nothing visible. Protection silently stops for senders without a cached copy.
DANE	DNSSEC chain breaks, or a TLSA record no longer matches the served certificate	Validating senders stop delivering. Hard failure, not degradation.
DANE	Certificate renewed with a new key and no TLSA update	Same. The renewal that was routine for years becomes an outage.
BIMI	VMC expires, or the DMARC policy slips	The logo disappears. Mail is unaffected and nobody notices for months.
Bulk-sender requirements	Complaint rate crosses the threshold	Gradual filtering, then sharp. Visible in engagement long before anyone connects it.

The two that stop mail

MTA-STS: a host in the MX set but absent from the policy.
   Cause: someone changed MX without changing the policy,
          or changed both and did not wait out max_age.
   Scope: senders that enforce. Which is most of your volume.

DANE: a TLSA digest that does not match the presented key.
   Cause: certificate renewal with a fresh key pair.
   Scope: senders that validate. Fails closed by design.

Both share a shape: a routine change elsewhere — an MX addition, a certificate renewal — breaks a record nobody remembers is coupled to it. The coupling is the risk, and the remedy is a checklist rather than a monitor, because the monitor tells you afterwards.

Certificate automation is where DANE fails

An ACME client that generates a new key pair on every renewal will break a 3 1 1 TLSA record every sixty days. Configure it to reuse the key, or add a deploy hook that publishes the new digest and waits. The default behaviour of most clients is the one that breaks it.

Knowledge check

You add an MX host and update the MTA-STS policy the same afternoon. Mail from Gmail starts deferring. Why?

Senders holding a cached policy enforce it for its full max_age, and that cached copy does not list the new host.
The TXT record id was not changed, so the new policy was never fetched.
The new host does not have a valid TLS certificate yet.
The MX record TTL has not expired.

Correct — Senders holding a cached policy enforce it for its full max_age, and that cached copy does not list the new host. The policy change has to lead the MX change by at least max_age. Doing both together means every sender with a valid cached policy refuses the new host until its copy expires.

Not this — The TXT record id was not changed, so the new policy was never fetched. A stale id does prevent a refetch, and even with a changed id a sender holding a valid cached policy is under no obligation to refetch before it expires. The waiting period is the actual requirement.

Not this — The new host does not have a valid TLS certificate yet. That would report as a certificate failure rather than a policy mismatch, and it would affect that host from every enforcing sender equally.

Not this — The MX record TTL has not expired. An unexpired MX TTL would mean senders do not know about the host at all, so they would keep using the old one and nothing would defer.

Last reviewed 2026-09-15

What each one adds

The two that stop mail

Try it on a real domain