Beyond the big three: MTA-STS, TLS-RPT, BIMI, and ARC

The second shelf of email standards with honest weights: what each one does, who actually needs it, and why none of them decides whether you land in spam.

Last updated 19 July 2026

Past SPF, DKIM and DMARC sits a second shelf of standards: MTA-STS, TLS-RPT, BIMI, and ARC. Each solves a real problem. None of them decides whether your mail lands in the inbox. I want to be blunt about that up front, because the deliverability industry has a habit of presenting every acronym as equally urgent, and it isn't true. This lesson gives you each standard in plain English with an honest weight attached, so you can recognize them, deploy the ones that apply to you, and stop feeling guilty about the rest.

MTA-STS: requiring encryption on the way in

Mail between servers travels over SMTP, and SMTP's encryption story is historically weak: the sending server asks "do you support TLS?" (TLS is the encryption layer, the same technology behind the padlock in a browser) and encrypts if the answer is yes. The flaw is that the question and answer travel unencrypted, so an attacker positioned on the network can strip the offer, and both servers happily fall back to plaintext. Delivery still works; nobody notices.

MTA-STS (RFC 8461, the name means Mail Transfer Agent Strict Transport Security) lets a receiving domain publish a policy saying: mail to me must use TLS, with a valid certificate, or not be delivered at all. The policy has two parts: a TXT record at _mta-sts.yourdomain.com announcing that a policy exists, and the policy file itself served over HTTPS from a mta-sts subdomain. Serving it over HTTPS is the clever bit, since an attacker who can tamper with DNS answers can't so easily forge a valid certificate too.

Get the direction straight, because this is the most common confusion: MTA-STS protects mail sent to your domain. It is a receiving-side protection for your inbound mail's privacy in transit. Publishing it does not authenticate your outbound newsletter and will not move your placement. Who should care: anyone whose inbound mail is sensitive, which in practice means most businesses eventually, and any organization with compliance obligations around data in transit. Weight: worth doing, zero folder impact.

TLS-RPT: finding out when encryption fails

MTA-STS has a companion problem: if delivery to you starts failing because of a TLS problem (an expired certificate on your mail host, a misconfigured policy, an actual attack), how would you ever know? The senders see the failures. You see silence.

TLS-RPT (RFC 8460) is the feedback channel. One TXT record at _smtp._tls.yourdomain.com with a reporting address, and participating senders (Google among them) send you daily summaries of their TLS successes and failures when delivering to your domain. It changes nothing about how mail flows; it is purely reporting, the same philosophy as DMARC's rua. If you deploy MTA-STS, deploy TLS-RPT alongside it, always. An enforcement policy without a failure report channel is how you block your own inbound mail and find out from an annoyed customer on the phone.

Both records are public DNS, which means both are checkable from outside; they're in the domain suite the free health check runs, weighted honestly as minor findings.

BIMI: your logo, at a price

BIMI (Brand Indicators for Message Identification) is the standard that gets your logo displayed next to your messages in supporting inboxes. It is the most asked-about standard on this shelf, and the one with the least deliverability substance.

Mechanically it's simple: a TXT record at default._bimi.yourdomain.com pointing to your logo as an SVG file. The prerequisites are where it bites. BIMI requires your domain's DMARC to be at enforcement, meaning p=quarantine or p=reject, actually enforced rather than weakened by a low pct=. And for the inbox everyone actually wants, Gmail, the logo alone isn't enough: you need a mark certificate from an approved certificate authority. The standard route is a Verified Mark Certificate, a VMC, which requires a registered trademark on the logo; a newer certificate type accepts logos with established prior use instead. Either way it costs real money, renewed annually.

Whether it's worth it, honestly: BIMI is cosmetic. A logo in the inbox is a brand-recognition nicety, and mailbox providers do not treat the record itself as a trust signal for filtering. We check BIMI on domains because it's part of a complete picture, and we weight it accordingly, which is to say: low. The genuinely valuable thing about BIMI is the forcing function. More than one organization has finally walked the DMARC path to enforcement because marketing wanted the logo, and the security team quietly cheered. If a logo gets your domain to p=reject, the logo earned its keep, just indirectly.

ARC: patching what forwarding breaks

You know from the DKIM lesson that forwarding is authentication's rough edge. A forwarded message arrives from the forwarder's server, so SPF fails. If the intermediary modified the message, a mailing list stamping [list-name] into the subject or appending an unsubscribe footer, DKIM breaks too. Now the final receiver sees a message with your From domain and no aligned pass, and if you publish p=reject, your own policy tells them to bin legitimate mail your recipients wanted.

ARC (RFC 8617, Authenticated Received Chain) is the attempted fix. Each intermediary that handles the message adds a set of ARC headers recording, in signed form, the authentication results as they stood on arrival: "when this message reached me, SPF passed and DKIM verified, signed, the mailing list." The next receiver can walk this chain of custody backwards and see that the message authenticated properly before the forwarder touched it.

The load-bearing word in ARC is may. The final receiver may take the chain into account when DMARC fails; nothing obliges it to, and an ARC seal is only worth anything if the receiver trusts the sealer, since any spammer can add ARC headers to anything. In practice ARC operates as a trust arrangement among large providers, Gmail and Microsoft sealing and honoring each other's chains. As a sender you don't publish anything for ARC and you can't opt into it; it happens to your mail, or doesn't, in transit. Know what those ARC-Seal headers mean when you meet them in a header readout, and know that ARC is why a sane mailing list no longer forces you to choose between p=reject and your subscribers who forward.

Where this leaves you

Weights, stated plainly. MTA-STS and TLS-RPT protect inbound mail privacy and cost little: deploy them when inbound confidentiality matters to you, and always together. BIMI is a brand feature with an expensive gate, useful mostly for the DMARC enforcement it forces along the way. ARC is infrastructure other people run, worth understanding and impossible to buy.

And that completes the record work of this part. Notice what the four standards here have in common: every one of them assumes the big three are already in place and working. MTA-STS assumes you have mail worth protecting, BIMI demands DMARC enforcement outright, ARC exists to preserve SPF and DKIM verdicts through forwarding. The stack has one foundation. SPF, DKIM and DMARC, correctly configured and aligned, decide which folder your mail lands in; everything in this lesson is refinement on top. If your health check shows a big-three problem and a missing BIMI record, there is no contest about which to fix first. The next module leaves configuration behind and gets into the other half of deliverability: reputation, and how filters actually decide.

Terms from this lesson

MTA-STS - the standard (RFC 8461) letting a domain require TLS for its inbound mail, via a DNS record plus a policy file served over HTTPS.
TLS-RPT - the companion standard (RFC 8460) requesting daily reports about TLS successes and failures when senders deliver to your domain.
BIMI - the record that displays your logo in supporting inboxes; requires DMARC at enforcement and, for Gmail, a Verified Mark Certificate.
VMC (Verified Mark Certificate) - the paid certificate proving your BIMI logo is your registered trademark; the standard way to satisfy Gmail's certificate requirement for logo display.
ARC (Authenticated Received Chain) - the standard (RFC 8617) letting forwarders and mailing lists pass along signed authentication results, so receivers can see a message authenticated before it was forwarded and altered.
enforcement - a DMARC policy of p=quarantine or p=reject at full strength, the prerequisite state for BIMI and the destination of the DMARC rollout path.

Check yourself

1. What does MTA-STS protect?

2. What does Gmail require before it will display your BIMI logo?

3. Why does a mailing list often break DKIM?

4. As a sender, what do you publish to enable ARC for your mail?