# BIMI and MTA-STS: Ship Both in an Afternoon, on Any Host (No $1,500 VMC Required)

BIMI puts your logo in the inbox. MTA-STS stops attackers from TLS-downgrading your incoming mail. Both use a DNS record plus an HTTPS-hosted file. Setup takes about an hour per domain on Netlify, GoDaddy, Vercel, Squarespace, or Wix, and the price for most small businesses is $0.

Author: J.A. Watte
Published: May 7, 2026
Source: https://jwatte.com/blog/blog-bimi-mta-sts-cross-host/

---

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](https://datatracker.ietf.org/doc/html/rfc7672)) 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](/tools/dns-email-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.

1. **SPF** authorizing your mail provider. For Google Workspace this is `v=spf1 include:_spf.google.com ~all`.
2. **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>`.
3. **DMARC at p=quarantine or p=reject**, with `pct=100` (explicit or omitted). `p=none` is 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](https://bimigroup.org/creating-bimi-svg-logo-files/) (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](https://bimigroup.org/getting-a-vmc/) 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:

1. Run the [DNS / Email Auth Audit](/tools/dns-email-audit/) and confirm SPF, DKIM, DMARC are healthy. Fix gaps before continuing.
2. Build a BIMI-compliant SVG (square, Tiny PS profile, no text elements). Upload it to your host.
3. Add the BIMI TXT record at `default._bimi.<domain>` pointing at the SVG URL.
4. Create the `mta-sts` subdomain 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`.
5. Add the MTA-STS TXT record at `_mta-sts.<domain>` with a unique `id`. 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](https://bimigroup.org/bimi-generator/) and an MTA-STS validator (search "MTA-STS validator" — multiple ones online; my preferred is [aykevl.nl/apps/mta-sts/](https://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](/blog/blog-email-infrastructure-small-business/), 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](https://www.amazon.com/dp/B0FF4F1QBR).

---

## 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](https://www.digicert.com/tls-ssl/verified-mark-certificates), [Entrust VMC product page](https://www.entrust.com/digital-security/certificate-solutions/products/digital-certificates/verified-mark-certificates). 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](https://www.uspto.gov/learning-and-resources/fees-and-payment/uspto-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](https://www.uspto.gov/dashboard/trademarks/). 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](https://bimigroup.org/implementation-guide-bimi/), [IETF draft-brand-indicators-for-message-identification](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/). The spec is explicit: `p=none` policies are rejected.
- **BIMI SVG must be Tiny PS profile, square, no text elements** — [BIMI SVG creation guide](https://bimigroup.org/creating-bimi-svg-logo-files/).
- **MTA-STS specification, including the `mta-sts.<domain>` subdomain hard requirement** — [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461). The HTTPS-on-subdomain requirement is in section 3.3.
- **TLS-RPT specification** — [RFC 8460](https://datatracker.ietf.org/doc/html/rfc8460).
- **STARTTLS stripping attack and motivation for MTA-STS** — [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672).
- **netlify-cli `createDnsRecord` failure** — 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 REST `POST /api/v1/dns_zones/{zone_id}/dns_records` with 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](/blog/blog-email-infrastructure-small-business/) — the broader email-infrastructure playbook
- [DNS / Email Auth Audit](/tools/dns-email-audit/) — the precheck and post-deploy verifier referenced throughout this post
- [DNS records generator](/tools/dns-records-generator/) — emits SPF/DKIM/DMARC and other records in five DNS provider syntaxes
- [Why broken DMARC quietly kills newsletter deliverability](/blog/blog-tool-dns-email-audit/) — the deeper read on what the audit tool actually checks
- [Email compliance footer](/tools/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.*


---

Canonical HTML: https://jwatte.com/blog/blog-bimi-mta-sts-cross-host/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-bimi-mta-sts-cross-host.webp
