Email Authentication for Developers Guide: BIMI, ARC and MTA-STS

SPF, DKIM and DMARC prove who sent a message, but they say nothing about whether it travelled encrypted, whether a forwarder broke it on the way, or whether the receiver will show your brand, and those gaps are now where most email engineering effort goes. This guide is the developer and platform engineer's companion to the sender-authentication basics: it covers the Authentication-Results header, STARTTLS downgrade, SMTP MTA Strict Transport Security (MTA-STS), SMTP TLS Reporting (TLS-RPT), DANE for SMTP with TLSA records, the Authenticated Received Chain (ARC) and BIMI, with record templates, rollout order and the failure modes seen in production. It assumes you already publish SPF, DKIM and DMARC; for policy rollout and aggregate reports, see the DMARC, SPF and DKIM Guide. It is for developers who build or run applications that send transactional email, and the teams that run mail domains and DNS.

Key takeaways

• Trust only your own Authentication-Results. RFC 8601 requires border MTAs to delete inbound Authentication Results header fields that claim your authserv-id, and applications should ignore any they did not add.
• Opportunistic TLS can be stripped. Without MTA-STS or DANE, an attacker in the path can remove the STARTTLS offer and mail falls back to cleartext without anyone noticing.
• Start every transport project with TLS-RPT. Daily JSON reports from senders show certificate and policy failures before you enforce, and keep showing them after.
• ARC carries evidence, not trust. RFC 8617 says "ARC is not a trust framework"; receivers decide which sealers to believe, so register only intermediaries you actually use.
• BIMI is the reward for enforcement. It requires DMARC at quarantine or reject, an SVG Tiny PS logo and, for Gmail, a Verified Mark Certificate or Common Mark Certificate.

Reading results: the Authentication-Results header

Receivers record their verdicts in the Authentication-Results header (RFC 8601, Standards Track, May 2019). Each field starts with an authentication service identifier (authserv-id, usually the receiving host or domain) followed by method=result statements with properties. A typical field looks like this template:

Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=tx202610; dmarc=pass header.from=example.com; arc=none

Developers parse this header in inbound processing and support tooling, and that is where it goes wrong. Anyone can write an Authentication-Results field into a message before sending it. RFC 8601 says a conforming MTA "MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier" to be its own, and must delete or obscure fields that did not come from a trusted MTA. Consumers "SHOULD NOT interpret this header field unless the authentication service identifier of the header field is used within the ADMD". In practice:

• Pin the authserv-id: read only the topmost field carrying your own identifier; ignore all others.
• Strip at the border: confirm your gateway or platform removes inbound fields that claim your identifier, and test it with a crafted message from outside.
• Record raw results: store each method with header.d and header.s, not one pass or fail flag.

The STARTTLS downgrade problem

SMTP between mail servers uses STARTTLS (RFC 3207): the receiving server offers it, the sender upgrades if it can, and otherwise continues in cleartext. Certificates are usually not validated. An attacker on the path can remove the STARTTLS offer or present any certificate, and the sender carries on. ATT&CK v20 describes this class as T1689 Downgrade Attack, and the interception that follows as T1557 Adversary-in-the-Middle. Two standards let recipients require TLS with a valid certificate.

MTA-STS in depth

SMTP MTA Strict Transport Security (MTA-STS, sometimes searched as MTA STS) is published in two parts. The TXT record at _mta-sts.example.com holds v=STSv1; id=20261018T0900, where id is any string that changes whenever the policy changes. The MTA-STS policy file is served at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mx1.example.com
mx: *.mail.example.net
max_age: 86400

• Modes: in enforce, senders "MUST NOT deliver the message to hosts that fail MX matching or certificate validation"; in testing, mail is delivered as normal and failures are reported through TLS-RPT; none withdraws the policy.
• mx patterns: a wildcard may only be the whole left-most label, so *.example.com matches mail.example.com but not example.com. Every MX record must match a pattern, including backup MX hosts and any gateway or filtering service your MX records point to.
• max_age: seconds a sender caches the policy, up to 31557600 (about one year). Use a day in testing; a week or more once enforcing so a blocked fetch does not leave senders without a cached policy.
• Certificates: the policy host must present a valid certificate for mta-sts.<domain>, and redirects are not followed. Each MX must present an unexpired certificate that chains to a trusted root and matches its host name. Automate renewal for both and alert well before expiry.
• Changing the policy: update the HTTPS file first, then the TXT id, so senders never fetch a new id with an old file.
• Removing it: publish mode: none with a short max_age, change the id, wait for the old max_age to pass, then remove the records. Deleting the records outright leaves senders enforcing a cached policy.

Treat the MTA STS policy file as code: keep it in version control and add a test that fetches it over HTTPS and checks every live MX against the patterns.

TLS-RPT: SMTP TLS Reporting

SMTP TLS Reporting (TLS-RPT, or TLS RPT, RFC 8460) asks senders to report failed and successful TLS sessions to you. Publish a TXT record at _smtp._tls.example.com: v=TLSRPTv1; rua=mailto:[email protected] (an https: endpoint is also allowed). Reports are JSON, normally gzip-compressed (application/tlsrpt+gzip), and "SHOULD cover a full day, from 00:00-24:00 UTC". Each report lists policies applied (sts, tlsa or no-policy-found), success counts and failure details.

Treat reports as untrusted input: decompress with size limits and validate JSON before parsing.

DANE for SMTP and TLSA records

DANE for SMTP (SMTP DANE, RFC 7672) uses TLSA records (RFC 6698) to pin the receiving server's key in DNS. RFC 7672 says it "depends critically on DNSSEC for downgrade resistance", and once a sender finds a secure TLSA record, "The SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS", which is what blocks STARTTLS downgrade even on first contact.

• Record: _25._tcp.mx1.example.com. IN TLSA 3 1 1 <SHA-256 of the server's public key>. The fields are certificate usage 3 (DANE-EE), selector 1 (SubjectPublicKeyInfo) and matching type 1 (SHA-256), the combination RFC 7672 prefers because it survives certificate renewals that reuse the same key.
• Usages to avoid: RFC 7672 says port 25 TLSA records "SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1)". DANE-TA(2) with a hash of your issuing CA is the second choice where keys change often.
• Rollover: publish TLSA for both the current and next key, wait at least the record TTL, switch the key, then remove the old record. Wire this into certificate automation; a renewal that generates a new key without updating TLSA makes DANE-validating senders defer your mail.
• Hosted MX: if your MX points at a mail platform, DANE depends on that platform publishing TLSA and DNSSEC for its hosts.

Publish both MTA-STS and DANE where you can. Some large senders support one and not the other, and RFC 8461 tells senders that MTA-STS must not override a DANE failure.

ARC: sealing and chain validation

The Authenticated Received Chain (ARC, RFC 8617, Experimental) addresses mail that legitimately changes in transit: mailing lists adding footers, gateways rewriting links, forwarders. Each intermediary adds an ARC set of three ARC headers with the same instance tag i= (1 to 50):

• ARC-Authentication-Results (AAR): the SPF, DKIM and DMARC results the intermediary saw on arrival.
• ARC-Message-Signature (AMS): a DKIM-style signature over the message as it left the intermediary.
• ARC-Seal (AS): a signature over all ARC header sets so far, with the chain validation result cv=none, pass or fail.

ARC sealing happens after every modification, and a sealer stops if the latest seal says cv=fail. ARC chain validation checks each seal in order; a passing chain shows which domains handled the message and what they saw, so the receiver can accept mail whose DKIM broke in transit. It does not make the message safe: RFC 8617 tells recipients "to treat every Sealer of the ARC Chain with suspicion".

• If you operate an intermediary (list server, ticketing system that relays, a gateway that rewrites content): enable ARC sealing with a dedicated signing domain and key, and manage that key like a DKIM key.
• If you receive on Microsoft 365: add each service that modifies inbound mail as a trusted ARC sealer in the Defender portal or with Set-ArcConfig -Identity Default -ArcTrustedSealers, which replaces the existing list. Microsoft warns that "a compromised vendor could pass spoofed messages through your authentication checks" and that "ARC overrides DMARC only, not spam filtering". The sealer is the d= domain in the ARC-Seal header, not your own domain.

BIMI records, selectors and logos

Brand Indicators for Message Identification (BIMI) lets supporting mailbox providers show a verified logo next to authenticated mail. The specification is an individual Internet-Draft (draft-brand-indicators-for-message-identification-14, May 2026) that the IETF Datatracker says has "no formal standing"; operational requirements come from the BIMI Group and each mailbox provider. For BIMI in the context of impersonation and BEC, see the Email Identity and BEC Guide.

• BIMI record: a TXT record at default._bimi.example.com: v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/mark.pem. v=BIMI1 must come first, l= is the logo location and a= the authority evidence (the mark certificate). Empty l= and a= declines BIMI for that name.
• BIMI selector: send a BIMI-Selector header (for example v=BIMI1; s=receipts) to use receipts._bimi.example.com for one stream. Receivers add BIMI-Location and BIMI-Indicator headers themselves; do not set them.
• DMARC prerequisite: the draft requires quarantine or reject. Google's help page also says "The percent option (pct) must be set to 100"; RFC 9989 removed pct, and an absent pct meant 100 under the older RFC 7489. p=none is not supported.
• BIMI SVG: the logo must use the SVG Tiny PS profile (baseProfile="tiny-ps", version="1.2"), with no scripts, animation or external references, served over HTTPS. Gmail asks for at least 96 pixels square, recommends 32 KB or smaller and a solid background.
• BIMI logo validation: receivers fetch the SVG and the certificate, check the profile and check that the logo in the certificate matches. Most rejections are profile errors from design tools, so validate the file with a BIMI checker before publishing and keep it under change control.

Transactional email authentication for developers

Application mail (password resets, receipts, alerts) is where developers control authentication directly, through a sending API, an SMTP relay or the Gmail API or Microsoft Graph.

• Align by design: sign with DKIM using your domain (d= on your organisational domain), set a custom return-path on your domain, and put each stream on its own subdomain such as notify.example.com.
• Meet the bulk sender floors: Google requires all senders to personal Gmail accounts, from 1 February 2024, to use SPF or DKIM, valid forward and reverse DNS and TLS; above 5,000 messages a day it adds SPF, DKIM, DMARC, From alignment and one-click unsubscribe for marketing mail. Microsoft requires senders of 5,000 or more messages to Outlook.com consumer addresses to pass SPF, DKIM and an aligned DMARC check, or receive 550 5.7.515.
• Protect the sending identity: the API key or SMTP credential for your email service is a non-human identity that sends mail passing every check. Scope it to send-only, store it in a secrets manager, restrict source IPs where offered and rotate it. The Gravity SMTP vulnerability exposed email API keys on WordPress sites to mass scanners. See the API Key Management Guide.
• Test in CI: send to a test mailbox, parse the Authentication-Results header with your own authserv-id and fail the build if DMARC is not aligned or TLS was not used.

Choosing what to deploy

Small teams on a hosted platform can do TLS-RPT and MTA-STS in a sprint. Large organisations should template records, generate policies from the MX inventory and run certificate and TLSA rollover in one pipeline.

Rolling out transport security and BIMI

1. Inventory: list every domain with MX records, every MX host, its certificate issuer and expiry, and whether the zone is DNSSEC-signed.
2. Publish TLS-RPT: on every receiving domain; confirm reports arrive within 48 hours and parse them.
3. MTA-STS testing: fix certificate names and expiry flagged in reports, publish the policy in testing with max_age: 86400, and watch at least two to four weeks of reports.
4. Enforce: switch to enforce, raise max_age to a week or more and change the id. Rollback is the reverse: return to testing and change the id; senders pick it up on their next check.
5. DANE: where DNSSEC is in place, publish TLSA 3 1 1, integrate rollover into certificate renewal and confirm tlsa policy results in TLS-RPT.
6. ARC: enable sealing on intermediaries you run and register trusted sealers on receiving platforms, one service at a time.
7. BIMI: once DMARC is at quarantine or reject, prepare an SVG Tiny PS logo, obtain a VMC or CMC, publish the BIMI record and verify display in test inboxes.

Detection and measurement

Alert on TLS-RPT failure spikes for any MX, on starttls-not-supported from a host that normally offers TLS (a possible downgrade in the path), on MX or policy-host certificates within 21 days of expiry, on changes to _mta-sts, _smtp._tls, _bimi and TLSA records outside change control, and on inbound Authentication-Results fields claiming your authserv-id that reach mailboxes. Metrics:

• Transport coverage: share of receiving domains with TLS-RPT and MTA-STS in enforce mode.
• TLS success rate: successful sessions as a share of all reported sessions, per MX.
• Certificate headroom: minimum days to expiry across MX and policy hosts.
• DANE health: tlsa-invalid or dnssec-invalid results per month (target zero).
• ARC sealer register: trusted sealers configured versus services actually modifying mail.
• Aligned transactional mail: share of application mail passing aligned DKIM in CI and production.

Framework mapping

Common failure patterns

• Expired MX certificate under enforce: a renewal fails and MTA-STS senders stop delivering to you until it is fixed; TLS-RPT showed certificate-expired warnings nobody read.
• Forgotten MX host: a backup MX or a filtering service is missing from the mx patterns, so enforcing senders refuse it.
• Records deleted instead of withdrawn: removing MTA-STS records leaves senders enforcing a cached policy for up to max_age.
• TLSA not rolled: certificate automation creates a new key and DANE-validating senders defer all mail.
• Trusting forged results: an application or support tool reads the first Authentication-Results header it finds, which an attacker wrote.
• Over-broad ARC trust: services added as trusted sealers years ago remain after the contract ends, each one able to vouch for spoofed mail.

Practitioner checklist

• Parse only Authentication-Results fields with your own authserv-id and strip forged ones at the border.
• Publish TLS-RPT on every receiving domain and process reports as untrusted input.
• Run MTA-STS in testing, fix every reported failure, then enforce with a max_age of a week or more.
• Automate MX and policy-host certificate renewal and alert at 21 days.
• Where zones are DNSSEC-signed, publish TLSA 3 1 1 records and roll them with key changes.
• Seal with ARC on intermediaries you run and keep the trusted sealer list to services in use.
• Publish BIMI only after DMARC enforcement, with a validated SVG Tiny PS logo and a VMC or CMC.
• Sign transactional mail with aligned DKIM on per-stream subdomains and test alignment in CI.
• Treat email API keys and SMTP credentials as non-human identities: send-only scope, vaulted, rotated.

Standards and references

• IETF: RFC 8461 SMTP MTA Strict Transport Security (MTA-STS)
• IETF: RFC 8460 SMTP TLS Reporting
• IETF: RFC 7672 SMTP Security via Opportunistic DANE TLS
• IETF: RFC 8617 The Authenticated Received Chain (ARC) Protocol
• IETF: RFC 8601 Message Header Field for Indicating Message Authentication Status
• IETF: Brand Indicators for Message Identification (BIMI) Internet-Draft
• Google: Set up BIMI
• Microsoft: Configure trusted ARC sealers

Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · Email Security Guide · Email Identity and BEC Guide · DNS Security Guide · Machine Identity, PKI and Certificate Lifecycle Guide