← Back to Blog

SPF, DKIM, and DMARC are the foundation of email authentication, and any organization serious about deliverability and anti-spoofing needs all three. But they are not the whole story. A newer set of standards, also published largely through DNS, addresses problems the original three do not: encrypting the connection between mail servers, reporting when that encryption fails, displaying your verified logo in the inbox, and preserving authentication through mailing lists and forwarders. Each solves a specific gap, and each lives, at least partly, in records you publish and can monitor.

If you have already implemented SPF, DKIM, and DMARC, covered in our complete email authentication guide, this piece is the natural next layer. It explains MTA-STS, TLS-RPT, BIMI, and ARC: what each does, what the records look like, and why they are worth monitoring.

MTA-STS: Enforcing Encryption Between Mail Servers

When one mail server delivers to another, it can upgrade the connection to TLS using STARTTLS. The weakness is that this is opportunistic: the encryption is negotiated in plaintext, so an attacker positioned in the middle can strip the upgrade and force the message through unencrypted, a downgrade attack. SPF, DKIM, and DMARC do nothing about this, because they authenticate the message, not the transport.

MTA-STS closes the gap by letting your domain publish a policy that says, in effect, "servers delivering to me must use TLS, and must validate my certificate." It has two parts: a DNS TXT record that signals the policy exists, and a policy file served over HTTPS that spells out the details.

The DNS record is published at a specific name under your domain:

_mta-sts.example.com.   IN   TXT   "v=STSv1; id=20260415000000"

The id is a version marker you change whenever you update the policy, so sending servers know to re-fetch it. The policy file itself lives at a fixed HTTPS location, https://mta-sts.example.com/.well-known/mta-sts.txt, and looks like this:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800

The mode is the key setting. Start at testing, which reports problems without blocking delivery, then move to enforce once you have confirmed legitimate mail is not affected. This staged rollout is the safe path, and it depends on the next standard to tell you what is happening.

TLS-RPT: Seeing When Encryption Fails

MTA-STS in testing mode is only useful if you can see the results, and that is what TLS-RPT (SMTP TLS Reporting) provides. It asks sending servers to send you daily aggregate reports about TLS connection successes and failures, so you can spot certificate problems, handshake failures, or downgrade attempts before switching MTA-STS to enforce.

It is a single DNS TXT record at its own name, pointing at where reports should go:

_smtp._tls.example.com.   IN   TXT   "v=TLSRPTv1; rua=mailto:[email protected]"

The rua tag names the address (or addresses, comma-separated) that receive the JSON reports. The relationship between the two standards is simple: MTA-STS enforces encryption, and TLS-RPT tells you how that enforcement is going. Deploying MTA-STS without TLS-RPT means flying blind through the exact period when you most need visibility.

BIMI: Your Verified Logo in the Inbox

BIMI (Brand Indicators for Message Identification) is the standard that displays your organization's logo next to authenticated messages in supporting email clients. Beyond looking professional, it is a trust signal: recipients see a verified brand mark, which is harder for impersonators to fake.

BIMI has an important prerequisite: it only works if you have DMARC in place at an enforcement policy. It is explicitly a reward for having done the authentication groundwork, not a shortcut around it. The record is a TXT record pointing at your logo (in a specific SVG format) and, for most real deployments, a verification certificate:

default._bimi.example.com.   IN   TXT   "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/bimi-cert.pem"

The l tag points to the logo, and the a tag points to the Verified Mark Certificate that attests you own the logo. Major mailbox providers generally require that certificate before they will display the mark, which is what stops anyone from simply pointing BIMI at a logo they do not own.

ARC: Preserving Authentication Through Forwarders

ARC (Authenticated Received Chain) solves a subtler problem. When a message passes through an intermediary, a mailing list, a forwarding service, that intermediary often modifies the message in ways that break SPF and DKIM. The result is that legitimate mail, forwarded through a list, can fail authentication at the final destination and get rejected, even though it was genuine.

ARC addresses this by letting each intermediary record the authentication results it saw at the time it received the message, and cryptographically sign that assessment. The final receiver can then see the chain: "this message passed authentication when the mailing list received it, and here is the list vouching for that." It does not override the receiver's own judgment, but it gives them the context to accept legitimate forwarded mail that would otherwise fail.

ARC is implemented by mail servers rather than being a single record you publish, so it is less a DNS configuration task and more a capability your mail infrastructure either supports or does not. It is worth knowing about because it explains why some legitimate forwarded mail fails, and why mature mail platforms implement it.

How These Fit Together

It helps to see the layers as complementary rather than competing:

  • SPF, DKIM, DMARC authenticate the message and its sender.
  • MTA-STS and TLS-RPT secure and report on the transport encryption between servers.
  • BIMI rewards strong authentication with a visible trust signal.
  • ARC preserves authentication results through intermediaries.

You do not need all of them on day one, and the sensible order is to get SPF, DKIM, and DMARC solid first, then add MTA-STS with TLS-RPT, then BIMI once DMARC is enforced. ARC largely comes along with a capable mail platform. Each layer addresses a real, distinct gap.

Why These Records Are Worth Monitoring

Every one of these standards, except ARC, lives in DNS records, which means they share the failure mode of all DNS configuration: they can be changed, break, or drift without anyone noticing until mail is affected. An MTA-STS policy record whose id is stale, a TLS-RPT address that no longer has a monitored mailbox behind it, a BIMI record pointing at a moved logo or an expired certificate, each is a silent failure that undermines the protection or trust signal you set up.

Because these are TXT records in your zone, they fall within the same continuous change monitoring that covers the rest of your DNS. DNS Assistant detects changes across your DNS records, including the TXT records these standards rely on, and surfaces them in real time, so an unexpected change to your email-security records is something you learn about promptly. It monitors and alerts rather than managing your mail configuration for you: the setup lives in your DNS and mail platform, and the value here is catching the day one of these records changes or disappears when it should not have. This is part of the broader email authentication posture we cover in the SPF, DKIM, and DMARC guide.

Check Your Email Records

You can inspect the email-related records a domain publishes with the free DNS lookup tool or a Free Domain Risk Report, a quick way to see what is in place and what is missing.

To keep your email authentication and transport-security records continuously monitored for change, start free at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free