MTA-STS and BIMI: Worth It, or Vendor Upsell?
MTA-STS and BIMI get sold together and are not the same purchase. MTA-STS is a published internet standard that blocks a real interception attack, and its reporting half costs one DNS record. BIMI is a draft branding feature gated behind a mark certificate listed at 1,500 dollars a year. Do the reporting first.

- TLS reporting is the cheap half and it works on its own. One DNS TXT record gets you daily reports on how other mail servers encrypted their connections to you, with nothing to host.
- An MTA-STS policy in testing mode enforces nothing. The standard says a sender may deliver the message anyway, and about 45 percent of published policies sit in testing.
- MTA-STS is a small web hosting project, not a DNS edit. You run an HTTPS site at mta-sts.yourdomain with a valid certificate, and Microsoft states Exchange Online will not host that file for you.
- BIMI's real cost is a recurring mark certificate. SSL.com lists one at 1,500 dollars a year, and it needs a logo registered with a recognised trademark office.
- Microsoft's own documentation names Google, Fastmail and Yahoo as the providers that support BIMI, and says emails sent from Exchange Online do not yet support it.
Are MTA-STS and BIMI worth it once DMARC is done?
Yes to TLS reporting, usually yes to an MTA-STS policy in enforce mode, and no to BIMI at most small firms. Those are three decisions, not one. Your provider will quote them as a single upgrade because they share a chapter in the same vendor deck, and separating them is the job of this article.
Separate them because they cost wildly different amounts. TLS reporting is one DNS TXT record. An MTA-STS policy is a small web hosting project with a certificate to renew. BIMI is a recurring subscription to a certificate authority, and the stronger version needs a registered trademark first. One of the three is free and useful this week.
Check the pitch against what the market has actually done. Across the top million domains, 7,377 published an MTA-STS policy in January 2026, which is 0.7 percent, up from 2,975 in 2024. Of those that publish, about 54 percent use enforce mode and about 45 percent sit in testing. Testing mode is the part a seller is least likely to explain, and it decides whether you bought anything.
What does MTA-STS actually protect you from?
MTA-STS protects the connection between two mail servers, not the contents of a message. RFC 8461 names two attacks. One is foiling TLS negotiation, which downgrades a session to plain text. The other is impersonating the destination mail server, for example by spoofing an MX record. An attacker on the network path strips the encryption offer out of the conversation, and without MTA-STS the sending server sends anyway.
To stop that, you publish a policy telling other people's mail servers what to insist on. Four things have to be true.
- Publish a DNS TXT record at _mta-sts.yourdomain containing v=STSv1 and an id value.
- Host the policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt, answering with HTTP 200.
- Secure that web host with an X.509 certificate valid for the mta-sts name and chaining to a trusted root.
- Name every mail server allowed to receive your mail, plus a max_age senders cache, typically in the range of weeks or greater.

Note what is missing. MTA-STS does nothing about a lookalike domain, a mailbox somebody already broke into, or a forged invoice. The FBI logged 24,768 business email compromise complaints in 2025 and $3,046,598,558 in losses, about $3.05 billion, or roughly $123,000 per complaint. None of that was lost to a downgraded TLS session. Keep the two problems apart when a provider bundles them into one quote.
Why MTA-STS is a web hosting project, not a DNS edit
To publish an MTA-STS policy you have to run a web server, because the policy lives on an HTTPS page rather than in DNS. Microsoft states it plainly for everyone on Microsoft 365: MTA-STS policy files aren't something that Exchange Online can host on behalf of customers, so you arrange the hosting yourself.
Microsoft's own walkthrough shows the shape of the job. The recommended route runs an Azure Static Web App with an Azure DevOps repository and a deployment pipeline, across eleven numbered steps. The alternative uses Azure Functions, which Microsoft calls not preferred because it requires that you issue your own mta-sts certificate and bind it to the function. Microsoft also says the article doesn't provide any information about Azure features' charging or costs. The free Static Web Apps tier does include two custom domains per app with free SSL certificates.
The recurring cost is attention, not licence fees. Somebody renews the certificate on that subdomain every year, and somebody notices when the page stops answering. Senders cache your policy for up to max_age, so a broken policy host fails quietly, weeks later, when the cached copies expire. Ask who owns that endpoint by name, and what monitoring watches it. If the answer is a person who left, you have a dependency nobody is auditing.

What does testing mode mean, and does it count as protection?
Testing mode means no enforcement at all. RFC 8461 says that in testing mode a sender reports the failure but messages may be delivered as though there were no MTA-STS validation failure. A policy parked in testing changes nothing about where your mail goes. It is a request for feedback, which is genuinely useful, and it is not a control.
Both big platforms tell you to start there, which is correct advice and the source of the problem. Google says before your domain enforces MTA-STS encryption and authentication, set your policy to testing mode. Microsoft recommends the same, and documents switching back during an incident, because testing allows you to keep your MTA-STS infrastructure intact while signaling to senders that enforcement should be paused. Neither page tells you when to come back and finish.
So the likely outcome is a policy that sits in testing forever, and the measurements bear that out. About 45 percent of published policies are in testing mode. An academic study of more than 87 million domains over 31 months found that of the 68,000 domains publishing an MTA-STS record, 29.6 percent were incorrectly configured. Its authors surveyed 117 operators and found 94.7 percent awareness, with 48.8 percent of non-deployers naming operational complexity. This protocol does not fail from obscurity.

One question settles it. What is the date your MTA-STS policy moved from testing to enforce? A date means somebody finished the work. No date means the project stopped halfway, and the invoice did not.
Is TLS reporting separate from MTA-STS?
Yes, and this is the most useful fact in the article. TLS reporting is its own standard, RFC 8460, and it works with no MTA-STS policy at all. You publish one DNS TXT record at _smtp._tls.yourdomain carrying v=TLSRPTv1 and a rua address, and sending systems start mailing you statistics. No policy file, no web host, no certificate, nothing to renew.
It reports even when you have no policy, which is the part vendors skip while selling the pair. The report schema carries a result value for the case where neither a DANE nor MTA-STS policy could be found, so reports arrive and describe reality either way. Each one covers a full day, from 00:00-24:00 UTC as a JSON file, and tells you whether other organisations' mail servers managed to encrypt their connections to you.

Run the three in that order and the risk drops. Reports first, for a month or two, so you can see which senders would break. Then a policy in testing. Then enforce mode, on a date you write down. Enforce mode genuinely can block inbound mail: Microsoft documents the non-delivery codes its senders return, including 5.4.8 when the destination MX host was not the host expected per the domain's STS policy and 5.7.5 when the remote certificate failed MTA-STS validation. That is the protection working, and it is also how a misconfigured policy loses you an order.
What does BIMI require, and what does it really cost?
BIMI requires an enforced DMARC policy, an SVG logo, a DNS record, and for Gmail a mark certificate you rent from a certificate authority. Google's gate is specific. The policy option (p) must be set to quarantine or reject, and BIMI doesn't support DMARC policies that have the p option set to none. You also need a VMC or CMC for your domain from a third-party certificate authority. Allow up to 48 hours for a logo to appear.
One published requirement points at a retired tag
Google also states that the percent option (pct) must be set to 100. That tag no longer exists in the standard. DMARC moved to RFC 9989 in May 2026, which obsoletes RFCs 7489 and 9091 and carries an appendix titled Removal of the "pct" Tag, with no pct entry left in its registry. A DMARC record written to the current standard has no pct tag to set. Put that to whoever is quoting you, and ask which mailbox providers they have actually tested against. Small things like this show how closely a seller reads the specifications.
The certificate is the cost, and one issuer publishes a price
The BIMI Group lists DigiCert, GlobalSign and SSL.com as Mark Certificate issuers and publishes no prices itself. Of those three, SSL.com publishes a figure on its own site: a Verified Mark Certificate at $1,500 per year on a one-year term, $1,350 per year over two years and $1,275 per year over three. The other two do not show a clean per-year figure on their own public pages, so ask for a written quote rather than trusting a reseller's number.

Then add the trademark, because a verified mark certificate is not sold against a logo you merely use. SSL.com requires the logo to be registered with a recognized trademark office, naming the USPTO, EUIPO, UKIPO, CIPO and IP Australia. A US application starts at a $350 base application fee per class before any attorney time, and registration takes months. Certificate validation itself is the fast part, typically 3-5 business days.
One more thing before you sign. MTA-STS is a published standard. BIMI is not. The specification is still an Active Internet-Draft, revision 14 dated 1 May 2026, which expires on 2 November 2026 and has never been published as an RFC. That does not make it fake, and the large mailbox providers implement it. It does mean the rules can move while you rent a certificate against them.
Which mailbox providers actually display your logo?
Four providers document their own behaviour, and the four answers differ enough to change the decision. Read them against your own customer list, not against a vendor's compatibility chart.
- Gmail shows the paid signal. Google states that in Gmail, you'll see a checkmark next to senders verified with a VMC, and that non-Gmail web apps do not support the feature.
- Yahoo does not charge for it, stating that we currently do not require VMCs to be set up for BIMI logos to appear in Yahoo applications. It does require a DMARC policy of quarantine or reject, that the mailing is sent to a large number of recipients, and sufficient reputation and engagement for the sending email address. It shows no logos for personal email.
- Apple Mail supports BIMI on iOS 16, iPadOS 16, and macOS Ventura 13 or later, and on iCloud.com, but puts the work on the receiving side. Apple requires your recipient's mail provider to have been added to the bimigroup.org list of providers supporting BIMI, and been verified by Apple, to verify the evidence document and to add the required headers.
- Microsoft publishes no answer at all, which is the answer you have to plan around. Its documentation names the supporting providers as Google, Fastmail, Yahoo, etc. without listing Outlook, and cautions that BIMI support is currently limited, so not all email clients or providers display the BIMI logo. It separately says emails sent from other Microsoft products, such as Exchange Online, do not yet support BIMI, but read that carefully: it is about sending, not about what the Outlook inbox renders. The honest position is that the other three tell you what they do and Microsoft does not.

Three of the four display a logo and the fourth does not, so put those four facts side by side and they say something no single page does. The certificate is mandatory at Gmail and optional at Yahoo, so what you are really buying is the Gmail checkmark. Yahoo shows your logo for nothing, but only on bulk mail with reputation behind it, which is not the invoice and quote traffic a 30-person firm sends. Apple displays a logo only where your recipient's provider has done server-side work you cannot do for them. And Microsoft, whose mailboxes most of your business customers read, says it is not supported.
If you invoice businesses rather than consumers, the recurring certificate buys a logo in the inbox your customers are least likely to be using.
That is the honest verdict on BIMI for a small business. It is a brand purchase, priced like one, aimed at consumer marketing mail. A retail list of 200,000 Gmail and Yahoo subscribers makes it defensible, and your marketing budget should carry it. Four hundred invoices a month to accounts payable departments does not, whatever security language the proposal wraps around it.
The verdict on each, in one line
Five decisions follow from the evidence above, and none of them is "it depends".
- Publish TLS reporting this month. One DNS TXT record, nothing to host, and it reports whether inbound mail to you is being encrypted.
- Publish an MTA-STS policy if a named person will own the HTTPS endpoint and renew its certificate. Set the date you move to enforce mode before you start.
- Skip enforce mode if nobody can name that person. A policy left in testing mode is at least honest about enforcing nothing.
- Defer BIMI unless you send bulk marketing mail to consumer mailboxes and already hold a registered trademark. It is a marketing spend, not a security control.
- Refuse any quote that prices the three together. Ask for three lines and three verdicts.
None of this makes your email secure on its own, and an honest provider says so. MTA-STS closes one network-level attack. TLS reporting tells you the truth about encryption in transit. BIMI puts a verified logo in front of some readers. The expensive attacks still arrive as a plausible message from a domain that is not yours.

What has to be true before either one is worth buying
Three things have to be finished first, and other posts own each of them. SPF, DKIM and a DMARC policy at quarantine or reject come first, because BIMI will not work without the last of those, and MTA-STS is beside the point while anybody can forge your domain outright. Our guide to SPF, DKIM and DMARC covers the records. Somebody also has to be reading the reports you already get, because a team that ignores DMARC reports will ignore TLS reports too: how to read a DMARC aggregate report walks through the five fields that matter.
The inventory has to be complete as well. The ten-domain email authentication problem covers the domains you forgot you own, and who owns your DNS records covers who can publish any of this. Two neighbouring questions get mistaken for this one. Mail landing in spam is answered by why your invoices land in spam, volume sending by the bulk sender rules, and somebody using your chief executive's name by display name spoofing.
What to ask your provider this week
Six questions separate a provider who has done this from one reselling a dashboard. Write the answers down, because a strong answer contains a date, a name or a setting value.
- Quote TLS reporting, the MTA-STS policy and BIMI as three separate lines with three prices.
- Name the person who renews the certificate on mta-sts.ourdomain, and the service monitoring that page.
- State the date our MTA-STS policy moves from testing mode to enforce mode.
- Show last month's TLS report, and name which sending organisations failed to encrypt.
- Confirm whether the BIMI quote includes a mark certificate, which certificate authority issues it, and what it renews at.
- Explain which of our customers' mailbox providers would display the logo we are paying for.
We rank providers and do not sell IT services, so we have no stake in the answer. Take these six questions to three vetted firms and compare side by side. A provider who tells you to publish one free DNS record before selling you a certificate is reading your business rather than their price list.
FAQ
Is MTA-STS worth it for a small business?
Usually yes, if somebody will own it. MTA-STS blocks a real attack, described in RFC 8461 as foiling TLS negotiation and impersonating the destination server. The cost is a small web hosting job with a certificate to renew, because Microsoft states that Exchange Online cannot host the policy file for customers. Agree who maintains it first.
Do you need MTA-STS to get TLS reports?
No. TLS reporting is a separate standard and works alone. You publish one DNS TXT record at _smtp._tls carrying v=TLSRPTv1 and a rua address, and the report format includes a value for the case where neither a DANE nor MTA-STS policy could be found. That makes it the cheapest first step in this whole area.
How much does a BIMI certificate cost?
One of the three listed issuers publishes a clean figure. The BIMI Group lists DigiCert, GlobalSign and SSL.com, and SSL.com publishes $1,500 per year for a one-year Verified Mark Certificate. Ask the other two for a written quote. Add the trademark too, because the USPTO base application fee is $350 per class.
Does Outlook display BIMI logos?
Microsoft does not say, and the absence is itself the answer for a buyer. Its documentation names the providers that support BIMI as Google, Fastmail, Yahoo, etc. without listing Outlook, warns that BIMI support is currently limited, so not all email clients or providers display the BIMI logo, and states separately that emails sent from other Microsoft products, such as Exchange Online, do not yet support BIMI. That last sentence is about sending, not displaying, so do not read it as a statement about the Outlook inbox. Nobody at Microsoft has published that Outlook shows the logo, and a certificate is an annual fee. Ask the seller to show you a logo rendering in Outlook before you buy, and treat a demonstration in Gmail as a demonstration about Gmail.
Does a DMARC policy of p=none work for BIMI?
No. Google states that the policy option (p) must be set to quarantine or reject and that BIMI does not support p=none. Yahoo requires the same, listing a DMARC policy of quarantine or reject as a condition for showing a logo. Get your DMARC policy to enforcement before anybody quotes you for a logo.
Best IT MSP is the independent directory of vetted managed IT and cybersecurity providers across North America. Organic ranking is earned on rating and verified data, and paid placement is always labelled. Take the six questions above to three merit-ranked firms in your city.