# MTA-STS, TLS-RPT and BIMI for senders

The three DNS records beyond SPF, DKIM and DMARC: what each promises, what receivers do with it, what Spaw reads, and the order to add them in.

Date: 2026-09-13

MTA-STS, TLS-RPT and BIMI are the three published policies a sending domain adds once SPF, DKIM and DMARC are in place. The first two are about the transport: MTA-STS tells other mail servers that mail to your domain must travel over authenticated TLS, and TLS-RPT tells them where to report when it could not. BIMI is about the inbox: it lets a receiver show your logo beside your messages, and it only works on a domain whose DMARC policy enforces. Spaw reads the DNS record for each and answers three booleans on the domain endpoint, beside the SPF and DMARC details that decide whether BIMI can apply at all.

## MTA-STS: no more opportunistic downgrade

SMTP between mail servers upgrades to TLS opportunistically, through the `STARTTLS` command, and an attacker who sits on the path can simply strip the offer, after which the mail travels in the clear. MTA-STS, defined in RFC 8461 (2018), lets a domain say that this must not happen.

The policy has two parts. A TXT record at `_mta-sts.example.com` carries `v=STSv1; id=…`, where the id changes whenever the policy does, and a policy file served over HTTPS at `https://mta-sts.example.com/.well-known/mta-sts.txt` names the mode (`enforce`, `testing` or `none`), the MX hostnames the policy covers, and how long a sender may cache it. A sending server that supports MTA-STS fetches the policy, and in enforce mode refuses to deliver to any MX not on the list or to any connection without a valid certificate for the MX name.

Spaw reads the TXT record and answers `mta_sts: true` when it carries `v=STSv1`. It does not fetch the policy file, so the field says "this domain has declared a policy", not "the policy is valid and enforcing". A domain monitor raises `mta_sts_lost` when the record disappears between runs.

The cost of getting it wrong is real mail refused, which is why the mode exists: publish in `testing` first, read the reports, then switch to `enforce`.

## TLS-RPT: the reports that make testing possible

TLS-RPT, RFC 8460 (2018), is the reporting channel for MTA-STS and for DANE. A TXT record at `_smtp._tls.example.com` with `v=TLSRPTv1; rua=mailto:…` tells sending servers where to send a daily report of connections to your domain that failed to meet the policy: certificate mismatches, expired certificates, STARTTLS that was offered but did not complete, MX hosts outside the policy.

Without it, an MTA-STS policy in testing mode is a promise nobody reports back on. Spaw answers `tls_rpt: true` when the record exists with `v=TLSRPTv1`; a domain with `mta_sts: true` and `tls_rpt: false` has skipped the step that would tell it whether enforcing is safe.

## BIMI: the logo, and what it requires

BIMI, Brand Indicators for Message Identification, is a draft specification maintained by the AuthIndicators Working Group rather than an RFC. A TXT record at `default._bimi.example.com` carries `v=BIMI1; l=…` with the URL of an SVG logo, and optionally `a=` with the URL of a certificate that proves the trademark.

Two requirements sit underneath it. The domain's DMARC policy must be at enforcement, quarantine or reject, and applied to all mail, so `pct` at 100 rather than a partial rollout, because a logo shown beside a message is only meaningful when unauthenticated mail from the domain is being rejected. And the large mailbox providers typically require a Verified Mark Certificate before they display the logo, which means a registered trademark and a paid certificate.

Spaw answers `bimi: true` when the record exists with `v=BIMI1`, and beside it the two fields that say whether the record can matter: `dmarc_policy` and `dmarc_pct`. A domain with a BIMI record and `dmarc_policy: "none"` has published a logo no receiver will show.

## The SPF and DMARC details that go with them

The same domain answer carries the details of the two older records that the newer ones lean on.

| Field | What it says |
| --- | --- |
| `spf_all` | The qualifier on the policy's `all` term: `-all` fails everything else, `~all` soft-fails it, `?all` says nothing, `+all` allows everyone, which is no policy at all. |
| `spf_lookup_count` | How many DNS-querying terms the policy needs once `include:` and `redirect=` are followed. RFC 7208 allows ten; a policy over that is a permanent error at every receiver, and it happens quietly when one more platform is added to an old record. |
| `dmarc_policy` | `none`, `quarantine` or `reject`. |
| `dmarc_pct` | The share of mail the policy applies to, 100 when the record omits it. |
| `dmarc_rua` | Whether an aggregate-report address is published, which is the only way to know what a policy is doing. |

`spf_lookup_count` is the one that surprises people. Each `include:` counts, and so does every mechanism inside the included record, so a domain that includes Google, Microsoft, a marketing platform, a support tool and a CRM can pass ten without anyone noticing, and from that day some receivers treat its SPF as broken.

## The order to add them in

Each record depends on the one before it, so the order is not a matter of taste.

1. **SPF with `-all` or `~all`, under ten lookups.** Every later record assumes mail from your domain can be authenticated.
2. **DKIM on every platform that sends as you.** Check the selectors are published under the names each platform uses; the [DKIM guide](/guides/dkim-selectors-explained) covers the names and the caveat.
3. **DMARC at `p=none` with `rua=`.** Read the aggregate reports for a few weeks; they show every source that sends as your domain, including the ones you forgot.
4. **DMARC at `quarantine`, then `reject`, then `pct=100`.** Move when the reports show only your own sources passing.
5. **TLS-RPT.** Publish the reporting address before any transport policy, so the testing phase has somewhere to report.
6. **MTA-STS in `testing`, then `enforce`.** Cover every MX host, keep the certificate on each valid for its MX name, and only enforce once the TLS reports are clean.
7. **BIMI**, if the brand has a trademark and the budget for a certificate. It needs step 4 complete.

## What Spaw does with the answer

Nothing on the per-address score. These are facts about a domain's sending posture, answered on the domain endpoint and the free checker, and read by the domain monitor, which flags a lost MTA-STS record and a lost DKIM key beside the SPF and DMARC changes. They describe how well a domain sends, which is the question a sender asks about itself and a security team asks about a partner, not whether a mailbox at the domain exists, which is the question a verification answers.

## What to do next

- Check a domain with the [free MTA-STS, TLS-RPT and BIMI checker](/tools/mta-sts-checker).
- Read all three beside the SPF and DMARC details on the [domain intelligence endpoint](/docs/api/domain-intelligence).
- Put your sending domains on a [domain monitor](/docs/api/create-domain-monitor) so a record that disappears is reported the day it does.
- Start from the beginning with the [SPF, DKIM and DMARC guide](/guides/spf-dkim-dmarc-for-developers).

Reference: https://spaw.co/guides/mta-sts-tls-rpt-and-bimi-for-senders