Two of the most-googled "do I need this?" email records of 2025 are BIMI and MTA-STS. They are not the same thing. They solve different problems. They share most of the prerequisites and they're sold together by every Gmail-deliverability blog because most domains are missing both.
BIMI is the visible identity layer. When you set it up correctly your logo shows up next to inbox entries in Apple Mail, Yahoo, Fastmail, and AOL on every email you send going forward. With a Verified Mark Certificate it shows in Gmail too with a blue check beside it. Without one, Gmail sees the record but does not display the logo.
MTA-STS is the in-transit encryption layer. When set up correctly, sending mail servers refuse to deliver your inbound mail unless they can negotiate TLS to a known set of MX hosts. Without it, an on-path attacker can downgrade the connection to plaintext (the STARTTLS stripping attack) and read or modify the message. Gmail and Yahoo are signaling MTA-STS will become a soft requirement for bulk senders alongside the SPF/DKIM/DMARC trio they already enforce.
I shipped both records on two domains in one sitting last week. This is the playbook with the cross-host parts that the typical tutorial leaves out.
Prerequisites both records share
Before either BIMI or MTA-STS is worth setting up, you need three things on the sending domain. Run the DNS / Email Auth Audit on your domain right now to confirm where you stand. The tool pulls live SPF, DKIM, DMARC, MX, and CAA records via DNS-over-HTTPS and tells you exactly which ones are missing.
- SPF authorizing your mail provider. For Google Workspace this is
v=spf1 include:_spf.google.com ~all. - DKIM signing live with the sending domain. Workspace generates the key in admin.google.com under Apps → Google Workspace → Gmail → Authenticate email; the resulting TXT record sits at
google._domainkey.<domain>. - DMARC at p=quarantine or p=reject, with
pct=100(explicit or omitted).p=noneis the most common blocker I see; BIMI specifically rejects it. Relaxed alignment (adkim=r; aspf=r) is acceptable for both; strict (adkim=s; aspf=s) is better but optional.
If DKIM is missing from the audit results, fix that first. It's the single most common prerequisite gap. The Workspace admin flow takes ten minutes. Wait an hour, re-run the audit, then proceed.
What BIMI gets you and what it does not
The DNS side is one TXT record at default._bimi.<your-domain> with this value:
v=BIMI1; l=https://your-domain.com/path/to/logo.svg
The hosting side is one SVG file. It must be the SVG Tiny PS profile (a strict subset of SVG 1.2), square aspect ratio, no text elements, no scripts, no animations, no external references, under 32 KB. Most marketing logos do not meet this spec out of the box because they contain <text> for brand text. The fix is to convert any text to paths or drop it from the BIMI version of the mark. The <text> element is the single most common reason BIMI inspectors reject a logo.
Display coverage as of 2026:
| Mail client | Without VMC | With VMC |
|---|---|---|
| Apple Mail (iOS, macOS) | shows logo | shows logo |
| Yahoo Mail | shows logo | shows logo + verified mark |
| Fastmail | shows logo | shows logo |
| AOL Mail | shows logo | shows logo |
| Gmail | does not show | shows logo + blue check |
| Outlook, Hotmail, Live | not supported | not supported |
A Verified Mark Certificate is a paid identity certificate from DigiCert (~$1,499/yr) or Entrust (~$1,200/yr). Before they will issue one, you need a USPTO-registered (or country equivalent) trademark covering the exact logo design. Application fees are $250 to $350 per class, registration takes 8 to 14 months, and an attorney typically adds $500 to $1,500 to that. Realistic first-year all-in: ~$2,000 to $3,000. Annual renewal after that: ~$1,200 to $1,500.
For most small businesses, skip the VMC. Apple Mail / Yahoo / Fastmail / AOL coverage is meaningful but not transformational, and Gmail-only logo display is rarely the difference between a sale and no sale. The math works for SaaS companies with strong brand identity already trademarked; it does not work for a single-location storefront, a personal newsletter, or a side-project domain.
What MTA-STS gets you and how it composes
MTA-STS has two components, same shape as BIMI: a DNS TXT record plus an HTTPS-hosted policy file.
The DNS record sits at _mta-sts.<your-domain>:
v=STSv1; id=20260507-01
The id is any unique token. Convention is YYYYMMDD-NN. You bump it whenever you change the policy.
The policy file lives at the EXACT URL https://mta-sts.<your-domain>/.well-known/mta-sts.txt and contains the MX names you authorize plus a freshness window:
version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 604800
The mandatory part most tutorials gloss over is the subdomain. mta-sts.<your-domain> has to actually resolve, with a valid TLS certificate, no redirect, and a content-type of text/plain on the policy file. That is where most of the host-specific work lives.
Optionally, add TLS-RPT for failure reporting:
TXT _smtp._tls.<your-domain> v=TLSRPTv1; rua=mailto:tls-reports@<your-domain>
Receiving mail servers will then send you JSON reports any time a TLS connection fails to your domain. Useful but not required.
Hosting decision: where the SVG and the policy file go
This is the cross-platform part. Each host has a different answer for "where does the SVG live" and "how do I create the mta-sts subdomain."
Netlify (where I host most properties)
SVG hosting: drop the file in images/bimi-logo.svg of your repo and deploy. It serves at https://yourdomain.com/images/bimi-logo.svg with a sensible image/svg+xml content-type automatically.
MTA-STS subdomain: add a domain alias on the existing site (mta-sts.yourdomain.com), let Netlify auto-provision a Let's Encrypt cert, and put the policy file at .well-known/mta-sts.txt in the same repo. Netlify serves the same content under both hostnames. Total time: about ten minutes plus a minute for the cert.
Watch out: netlify api createDnsRecord returns JSONHTTPError: Unprocessable Entity for every payload variation I have tried, including a trivial value="hello" smoke test. The underlying REST API works fine. If you script DNS changes, hit POST /api/v1/dns_zones/{zone_id}/dns_records directly with the bearer token from ~/AppData/Roaming/netlify/Config/config.json. The CLI's read methods (getDnsZones, getDnsRecords) work; only the create wrapper is broken in netlify-cli 24.x.
GoDaddy (cPanel hosting + their integrated DNS)
SVG hosting: log into the hosting account, open cPanel, then File Manager. Navigate to public_html and either drop the SVG into an existing images/ folder or create one. The file is then live at https://yourdomain.com/images/bimi-logo.svg.
MTA-STS subdomain: in cPanel, open Subdomains and create mta-sts with document root public_html/mta-sts/. cPanel auto-creates the DNS A record on GoDaddy's nameservers. Inside that new folder, create a .well-known directory and upload mta-sts.txt into it. AutoSSL provisions the TLS cert within 24 hours. While waiting, the policy file is reachable over HTTP only and BIMI/MTA-STS validators will fail until HTTPS is up.
Vercel
SVG hosting: drop the file in public/images/bimi-logo.svg of your repo. After vercel deploy --prod, it serves at /images/bimi-logo.svg.
MTA-STS subdomain: Vercel does not support multiple custom domains pointing at the same project file tree without explicit per-domain config. Two clean options. (1) Create a second, single-file Vercel project for the mta-sts.<domain> subdomain. Free tier covers it. (2) Use a Vercel rewrite to proxy the subdomain at the same project. Option 1 is simpler for a static file. Don't try to share a project across the apex and the mta-sts subdomain.
Squarespace
SVG hosting: Squarespace will let you upload an SVG via Custom Files / File Library, but the served URL is auto-generated and does not match a stable path you control. Use it for the BIMI logo only if you accept that the URL might rotate on a future platform update; a safer move is to host the SVG on a free Netlify Drop site at bimi-assets.<domain> and reference that.
MTA-STS subdomain: Squarespace does not allow arbitrary file uploads at the .well-known/ path of a subdomain you do not control. You cannot host the MTA-STS policy file directly on Squarespace. The standard workaround: spin up a free Netlify Drop or GitHub Pages site dedicated to the policy file, point a CNAME from mta-sts.<your-domain> at it, and configure HTTPS there.
Wix
SVG hosting: Wix lets you upload SVGs via the Media Manager but, like Squarespace, the served URL is on a Wix CDN with a path you cannot fully control. Same workaround as Squarespace: host the BIMI SVG on a sibling Netlify or Cloudflare Pages free site if URL stability matters.
MTA-STS subdomain: Wix does not allow custom file uploads at .well-known/ paths. Same workaround as Squarespace: spin up a free Netlify Drop or Cloudflare Pages site dedicated to the policy file, CNAME the subdomain at it.
Other hosts at a glance
- Cloudflare Pages, GitHub Pages, Render static sites all work like Netlify: drop the files in the repo, deploy, configure custom domains. None has the Netlify CLI gotcha because their CLIs are different shape.
- WordPress with cPanel behaves like GoDaddy. WordPress.com (managed) behaves like Squarespace and needs the Drop-site workaround.
- AWS S3 + CloudFront works fine for both files; the lift is configuring the second CloudFront distribution for the
mta-sts.subdomain with its own ACM cert.
The five-step playbook
For any host above:
- Run the DNS / Email Auth Audit and confirm SPF, DKIM, DMARC are healthy. Fix gaps before continuing.
- Build a BIMI-compliant SVG (square, Tiny PS profile, no text elements). Upload it to your host.
- Add the BIMI TXT record at
default._bimi.<domain>pointing at the SVG URL. - Create the
mta-stssubdomain on your host or on a free fallback (Netlify Drop, Cloudflare Pages). Wait for the TLS cert to provision. Upload the policy file at.well-known/mta-sts.txt. - Add the MTA-STS TXT record at
_mta-sts.<domain>with a uniqueid. Optionally add TLS-RPT at_smtp._tls.<domain>.
After ~10 minutes of DNS propagation, run the audit tool again as a regression check. It should pull both new records cleanly. For deeper validation use the BIMI inspector and an MTA-STS validator (search "MTA-STS validator" — multiple ones online; my preferred is aykevl.nl/apps/mta-sts/).
Time and cost summary
| Step | Time | Cost |
|---|---|---|
| BIMI SVG creation + hosting | ~30 min | $0 |
| BIMI DNS record | ~5 min | $0 |
| MTA-STS subdomain + cert | ~10 min on host with auto TLS, ~30 min if manual | $0 |
| MTA-STS policy + DNS record | ~10 min | $0 |
| Verification + propagation wait | ~15 min | $0 |
| Optional VMC for Gmail logo display | 8 to 14 months (trademark wait) | ~$2,000 first year, ~$1,200/yr after |
Skipping the VMC is the right call for almost every reader of this post. Apple Mail and Yahoo coverage is real, Gmail-without-VMC display is increasingly available for senders with strong DMARC reputation in any case, and the $1,200/yr is better spent on Google Ads or list quality.
A small mention of where this fits in a broader stack
If you're setting up email authentication from scratch on a small business domain, BIMI and MTA-STS are the last two records you should worry about. The transactional/newsletter/outreach lane decision, the secondary domain question, and the Workspace warmup process all matter more for actual deliverability. The full playbook for that work is in How to send email that actually gets delivered, and if you want the longer-form context on why a small operator should think of their site, email reputation, and sending infrastructure as one budget rather than three, that's the territory of The $100 Network.
Fact-check notes and sources
Every specific number above is verifiable. Where a small-business reader could reasonably ask "where'd you get that," here are the sources:
- DigiCert VMC pricing (~$1,499/yr) and Entrust VMC pricing (~$1,200/yr) — DigiCert VMC product page, Entrust VMC product page. Pricing reflects 1-year list price as of May 2026; volume and multi-year contracts run lower.
- USPTO trademark filing fees ($250 to $350 per class) — USPTO trademark fee schedule. TEAS Plus is $250/class, TEAS Standard is $350/class.
- USPTO trademark registration timeline (8 to 14 months) — USPTO First Action Pendency dashboard. Median first-action pendency has been 8 to 9 months since 2024; full registration adds 4 to 6 months on top of that for routine applications.
- BIMI requires DMARC at p=quarantine or p=reject — BIMI Group requirements, IETF draft-brand-indicators-for-message-identification. The spec is explicit:
p=nonepolicies are rejected. - BIMI SVG must be Tiny PS profile, square, no text elements — BIMI SVG creation guide.
- MTA-STS specification, including the
mta-sts.<domain>subdomain hard requirement — RFC 8461. The HTTPS-on-subdomain requirement is in section 3.3. - TLS-RPT specification — RFC 8460.
- STARTTLS stripping attack and motivation for MTA-STS — RFC 7672.
- netlify-cli
createDnsRecordfailure — reproduced against netlify-cli/24.8.1 on win32-x64 / node-v24.15.0, on multiple payload variations. Read methods (getDnsZones,getDnsRecords) succeed; only the create wrapper returns Unprocessable Entity. Direct RESTPOST /api/v1/dns_zones/{zone_id}/dns_recordswith the same bearer token works first try.
Pricing and platform behavior can move quarterly. Confirm against the source link before you commit.
Related reading
- How to send email that actually gets delivered — the broader email-infrastructure playbook
- DNS / Email Auth Audit — the precheck and post-deploy verifier referenced throughout this post
- DNS records generator — emits SPF/DKIM/DMARC and other records in five DNS provider syntaxes
- Why broken DMARC quietly kills newsletter deliverability — the deeper read on what the audit tool actually checks
- Email compliance footer — the CAN-SPAM and CCPA footer generator that sits next to this work in any send
This post is informational, not legal or compliance advice. BIMI, MTA-STS, and TLS-RPT specifications are evolving (IETF drafts, BIMI Group implementation guide, RFCs cited above). Mentions of Apple, Google, Yahoo, Fastmail, Microsoft, Netlify, GoDaddy, Vercel, Squarespace, Wix, DigiCert, and Entrust are nominative fair use. No affiliation is implied.
