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.
- SPF with
-allor~all, under ten lookups. Every later record assumes mail from your domain can be authenticated. - DKIM on every platform that sends as you. Check the selectors are published under the names each platform uses; the DKIM guide covers the names and the caveat.
- DMARC at
p=nonewithrua=. Read the aggregate reports for a few weeks; they show every source that sends as your domain, including the ones you forgot. - DMARC at
quarantine, thenreject, thenpct=100. Move when the reports show only your own sources passing. - TLS-RPT. Publish the reporting address before any transport policy, so the testing phase has somewhere to report.
- MTA-STS in
testing, thenenforce. Cover every MX host, keep the certificate on each valid for its MX name, and only enforce once the TLS reports are clean. - 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.
- Read all three beside the SPF and DMARC details on the domain intelligence endpoint.
- Put your sending domains on a domain monitor so a record that disappears is reported the day it does.
- Start from the beginning with the SPF, DKIM and DMARC guide.