Advanced Email Authentication: BIMI, MTA-STS, DANE and ARC Explained

Beyond SPF, DKIM and DMARC

SPF, DKIM and DMARC form the foundation of email authentication. This guide assumes you have them in place (see SPF DKIM DMARC Guide if not) and covers the next layer of protocols: BIMI, MTA-STS, DANE and ARC.

These protocols address problems that SPF/DKIM/DMARC do not:

• BIMI displays your brand logo next to authenticated emails in the inbox.
• MTA-STS enforces encryption (TLS) for email in transit between servers.
• DANE uses DNS to verify the TLS certificate of the receiving mail server.
• ARC preserves authentication results when emails are forwarded through intermediaries.

BIMI (Brand Indicators for Message Identification)

What BIMI does

BIMI displays your brand's logo next to your emails in supporting mail clients. When a recipient sees your email in their inbox, instead of a generic initial or avatar, they see your verified logo.

Why it matters:

• Brand recognition in the inbox.
• Visual trust signal (only authenticated senders can display a logo).
• Increased open rates (studies show 10-30% improvement in brand recognition).
• Competitive differentiation (most senders do not have BIMI set up).

Requirements

BIMI requires:

1. DMARC at enforcement. Your DMARC policy must be p=quarantine or p=reject. A policy of p=none (monitoring only) is not sufficient.

2. A verified logo. Your logo must be in SVG Tiny PS (SVG Portable/Secure) format, a specific constrained version of SVG. It must be:

   • Square aspect ratio.
   • Solid background (no transparency).
   • SVG Tiny PS format (not regular SVG).
   • Hosted at an HTTPS URL.

3. A VMC (Verified Mark Certificate). Currently required by Gmail and Apple Mail. A VMC is issued by a certificate authority (DigiCert or Entrust) after verifying your trademark ownership. Costs approximately $1,000-1,500 per year.

4. A registered trademark. The logo must be a registered trademark with a recognised trademark office (USPTO, EUIPO, CIPO, etc.).

BIMI DNS record

BIMI uses a TXT record at default._bimi.yourdomain.com:

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

Where:

• l= is the URL to your SVG Tiny PS logo.
• a= is the URL to your VMC certificate (required for Gmail).

Supporting mail clients

Implementation steps

1. Ensure DMARC is at p=quarantine or p=reject with good alignment rates.
2. Register your logo as a trademark (if not already registered). This can take 6-12 months.
3. Create an SVG Tiny PS version of your logo.
4. Obtain a VMC from DigiCert or Entrust (requires trademark registration).
5. Host the SVG and VMC at stable HTTPS URLs.
6. Add the BIMI DNS record.
7. Test with BIMI Inspector (bimigroup.org/bimi-generator).
8. Monitor for logo display across supporting clients.

MTA-STS (Mail Transfer Agent Strict Transport Security)

What MTA-STS does

MTA-STS tells sending mail servers that your domain requires encrypted (TLS) connections for email delivery. Without MTA-STS, a sending server might fall back to unencrypted delivery if the TLS connection fails, making the email vulnerable to interception.

The problem it solves: SMTP was designed without encryption. STARTTLS was added later as an opportunistic upgrade -- the sending server tries TLS, but if it fails, it falls back to plaintext. An attacker can strip the STARTTLS command (a "downgrade attack"), forcing plaintext delivery and intercepting the email.

MTA-STS says: "If TLS fails, do not fall back to plaintext. Either deliver over TLS or do not deliver at all."

How MTA-STS works

1. The sending server checks for an MTA-STS policy at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.
2. The policy specifies which mail servers to connect to and that TLS is required.
3. If the sending server cannot establish a TLS connection to the specified servers, it does not deliver the email (instead of falling back to plaintext).

MTA-STS policy file

Host this file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: mail2.yourdomain.com
max_age: 86400

Where:

• mode: testing (report failures but still deliver) or enforce (reject unencrypted delivery).
• mx: your mail servers (must match MX records).
• max_age: how long sending servers cache the policy (in seconds).

MTA-STS DNS record

Add a TXT record at _mta-sts.yourdomain.com:

_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20261008"

The id value must change whenever you update the policy file (it tells sending servers to re-fetch the policy).

TLS-RPT (TLS Reporting)

Companion to MTA-STS. TLS-RPT tells sending servers where to send reports about TLS connection failures:

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

These reports tell you:

• Which sending servers had TLS failures connecting to your domain.
• What type of failures occurred (certificate errors, connection failures).
• How many messages were affected.

Implementation steps

1. Ensure all your MX servers have valid TLS certificates.
2. Create the MTA-STS policy file.
3. Host the policy file at the correct HTTPS URL (requires a web server or CDN).
4. Add the MTA-STS DNS TXT record.
5. Start in testing mode (reports but no enforcement).
6. Set up TLS-RPT to receive reports.
7. Monitor reports for TLS failures.
8. Once confident, switch to enforce mode.

DANE (DNS-Based Authentication of Named Entities)

What DANE does

DANE uses DNSSEC (DNS Security Extensions) to publish the TLS certificate (or certificate authority) that a mail server should present. The sending server checks the DNS record and verifies that the receiving server's certificate matches.

The problem it solves: TLS certificates are issued by certificate authorities (CAs). A compromised or malicious CA could issue a fake certificate for your domain. DANE adds an independent verification path through DNS.

How DANE works

1. Your domain publishes TLSA records in DNS specifying the expected certificate.
2. The sending server looks up the TLSA record via DNSSEC.
3. The sending server connects to your mail server and checks that the presented certificate matches the TLSA record.
4. If it does not match, the sending server can reject the connection.

DANE DNS record

A TLSA record at _25._tcp.mail.yourdomain.com:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 <hash-of-certificate>

Where:

• 3 = certificate usage (DANE-EE, end entity certificate).
• 1 = selector (SubjectPublicKeyInfo).
• 1 = matching type (SHA-256 hash).
• The hash is a SHA-256 hash of the mail server's public key.

Requirements

DANE requires DNSSEC on your domain. DNSSEC signs DNS records cryptographically to prevent tampering. Without DNSSEC, DANE records cannot be trusted.

DNSSEC adoption challenges:

• Not all domain registrars support DNSSEC.
• DNSSEC adds complexity to DNS management.
• Key rotation must be handled carefully to avoid outages.
• Not all DNS providers support DNSSEC.

DANE vs MTA-STS

Recommendation: Implement MTA-STS first (wider support, easier to deploy). Add DANE if your infrastructure already supports DNSSEC.

ARC (Authenticated Received Chain)

What ARC does

ARC preserves email authentication results across forwarding hops. When an email is forwarded (mailing list, forwarding service, security gateway), SPF and DKIM can break:

• SPF fails because the forwarding server's IP is not in the original sender's SPF record.
• DKIM can fail if the forwarding server modifies the email (adds a footer, changes headers).

ARC allows intermediaries to sign the original authentication results so the final receiving server can see what the results were before forwarding.

How ARC works

1. The original email arrives at the intermediary (mailing list server, forwarding service).
2. The intermediary records the current SPF, DKIM and DMARC results.
3. The intermediary signs these results with its own key (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results).
4. The intermediary forwards the email.
5. The final receiving server sees that SPF/DKIM may have failed, but checks the ARC headers.
6. If the intermediary is trusted, the receiving server can use the original authentication results.

ARC headers

ARC adds three headers at each hop:

ARC-Authentication-Results: i=1; mx.example.com;
    dkim=pass header.d=sender.com;
    spf=pass smtp.mailfrom=sender.com;
    dmarc=pass header.from=sender.com

ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=arc;
    h=from:to:subject:date;
    b=<signature>

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arc;
    cv=none;
    b=<seal-signature>

The i= value increments at each hop (i=1, i=2, i=3), creating a chain.

Who needs ARC

ARC is primarily relevant for:

• Mailing list operators (emails are redistributed with modifications).
• Email forwarding services (university alumni forwarding, domain forwarding).
• Email security gateways (that modify email in transit).
• Large enterprises with complex mail routing.

As a sender, you do not need to implement ARC. Your role is to have strong SPF, DKIM and DMARC. ARC is implemented by intermediaries and evaluated by receiving servers.

ARC support

Implementation Priority

Recommended order:

1. SPF, DKIM, DMARC (if not already in place).
2. MTA-STS in testing mode + TLS-RPT.
3. MTA-STS in enforce mode (after monitoring reports).
4. BIMI (if you have a registered trademark or plan to register one).
5. DANE (only if you already have DNSSEC).

Testing and Monitoring

Testing tools

Ongoing monitoring

• DMARC reports: monitor authentication pass rates, identify unauthorised senders.
• TLS-RPT reports: monitor TLS connection failures to your domain.
• BIMI display: check logo display in supporting clients after deployment.
• Certificate expiry: ensure mail server TLS certificates are renewed before expiry.

Related Guides

• SPF DKIM DMARC Guide
• Email Deliverability Troubleshooting
• Sender Reputation Guide
• Email Warm-Up Strategies
• Cold Email Infrastructure Setup