MTA-STS, TLS-RPT and BIMI Setup Guide

Beyond SPF, DKIM and DMARC, three DNS-based standards address email transport security, reporting and brand visibility: MTA‑STS, TLS‑RPT and BIMI. They complement email authentication rather than replace it: MTA‑STS publishes a transport security policy for incoming mail, TLS‑RPT requests transport reports, and BIMI provides logo information for supporting inbox providers. Publishing these records does not guarantee inbox placement or logo display.

In this article, we will walk through what MTA‑STS, TLS‑RPT and BIMI actually do, how they fit into your existing email setup, and what kind of DNS and hosting environment you need to deploy them safely. The hosting considerations apply whether you use shared hosting, a VPS, a dedicated server or colocated infrastructure. The goal here is to give you a practical, production-oriented view so you can plan, implement and maintain these records without breaking email delivery.

Where MTA‑STS, TLS‑RPT and BIMI Fit in the Email Security Stack

Before going deeper, it helps to put these three standards in context. Most organizations already know the first layer:

• SPF: identifies servers authorized to use a domain in the SMTP MAIL FROM or HELO identity, not necessarily the visible From address.
• DKIM: cryptographically signs selected message headers and the body so recipients can verify the signed content.
• DMARC: requests handling when neither SPF nor DKIM passes with alignment to the visible From domain, and specifies reporting destinations. A pass from either aligned mechanism is sufficient.
• rDNS / PTR: maps a sending IP to a hostname; verify that the hostname resolves back to the same IP, as required by providers such as Gmail.

If you need a refresher, we have a detailed guide on how to set up SPF, DKIM and DMARC correctly on cPanel or a VPS, and another step‑by‑step article about improving email deliverability with SPF, DKIM, DMARC and rDNS.

Once that foundation is solid, you can add the second layer:

• MTA‑STS: asks supporting senders to require TLS for SMTP delivery to your domain and validate the destination MX against your policy when enforcement is enabled.
• TLS‑RPT: requests aggregated reports from participating senders about TLS delivery to your mail servers, including failures.
• BIMI: supplies your brand logo for display by supporting inbox providers, subject to their authentication, reputation and logo-verification requirements.

Think of SPF/DKIM/DMARC as identity and policy, and MTA‑STS/TLS‑RPT/BIMI as encryption assurance and visual trust. Together, they can reduce phishing risk, increase transport security, and help your real messages stand out in supporting inboxes.

MTA‑STS: Enforcing TLS Encryption for Your Domain’s Incoming Email

MTA‑STS (Mail Transfer Agent Strict Transport Security) defines recipient SMTP transport policy. In enforce mode, it lets you publish a policy saying: “Supporting senders should deliver to my MX servers only over TLS using valid certificates; if they cannot meet the policy, they should not fall back to plaintext.” This helps protect SMTP transport against downgrade attacks and some man‑in‑the‑middle scenarios, but it is not a guarantee for every sender or connection.

How MTA‑STS Works: DNS Record + Policy File

MTA‑STS has two key components, both of which you need to host correctly:

1. DNS TXT record at _mta-sts.example.com that announces the existence and version of your policy.
2. HTTPS policy file at https://mta-sts.example.com/.well-known/mta-sts.txt describing your MX hosts, policy mode and max age.

When a provider that supports MTA‑STS wants to send mail to user@example.com, the process is broadly:

• Uses a valid cached policy, or discovers the _mta-sts.example.com TXT record and fetches the HTTPS policy when needed.
• Checks each candidate MX against the policy patterns and verifies STARTTLS support and a trusted, unexpired certificate with a SAN DNS-ID matching the actual MX hostname.
• Applies the selected mode. Under enforce, a failing MX is skipped and another eligible MX may be tried; failure is normally transient and retried.
• Checks for an updated policy before permanently failing delivery. A valid cached policy still applies if current DNS discovery or HTTPS fetching fails.

Publishing the recipient policy does not force every sender to support MTA-STS. With no valid cached policy and no fetchable policy, delivery proceeds as though MTA-STS were absent; initial discovery can therefore be blocked by an attacker.

MTA‑STS Policy Modes: none, testing, enforce

Your MTA‑STS policy file has a mode directive:

• mode: none: declares that the domain has no active policy. It supports controlled removal, rather than a discovery/testing phase.
• mode: testing: an MTA-STS validation failure does not itself block delivery. Participating TLS-RPT senders can report failures; other delivery checks still apply.
• mode: enforce: supporting senders applying the policy must not deliver to an MX that fails hostname matching, STARTTLS or certificate validation. Other eligible MX hosts can be tried. They should retry temporary failure and must check for a newer policy before permanently failing delivery.

A cautious rollout starts with testing, monitors TLS‑RPT reports, and fixes misconfigurations before moving to enforce. Allow an observation period, such as a few weeks, appropriate to your mail traffic and reporting coverage.

Example: MTA‑STS Policy and DNS Record

This example uses reserved names for two MX hosts. Replace them with your real receiving MX names. The one-day cache lifetime is a staging example, not a universal production recommendation:

version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400

The corresponding DNS TXT record at _mta-sts.example.com could look like this:

_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20250101T000000;"

The id is a unique policy-instance identifier containing 1–32 ASCII letters or digits; it has no required date format or ordering. Update the HTTPS body first, then publish a new id. Senders checking DNS can discover the change, but this does not instantly flush every policy cache.

max_age is the lifetime in seconds from the last successful policy fetch, separate from DNS TTL; its valid range is 0–31557600. Stable deployments benefit from longer lifetimes, often weeks, while changes must account for previously served values. Shortening max_age today does not shorten a sender’s existing cache. To retire MTA-STS, publish mode: none with a new id and keep the TXT/HTTPS endpoints until all previously served policy lifetimes have expired.

Common MTA‑STS Pitfalls

Check for these MTA‑STS issues before enabling enforcement:

• MX names and patterns: List every intended primary/backup MX. *.example.com matches mail.example.com, but not example.com or foo.bar.example.com. Use ASCII/Punycode for internationalized names.
• SMTP certificate identity: A trusted, unexpired certificate must contain a SAN DNS-ID matching the actual MX hostname. Matching a broad policy pattern is not enough, and a Common Name alone does not meet this MTA-STS rule.
• Policy HTTPS endpoint: Serve the exact well-known path directly with 200 and text/plain. MTA-STS clients do not follow 3xx redirects. The HTTPS certificate must authenticate mta-sts.example.com; this is a separate identity from the SMTP MX.
• Premature enforcement: A failing path can delay delivery, but another eligible MX may still work. Test all primary, backup, IPv4 and IPv6 paths before enforce; report silence is not proof of coverage.

If you are already familiar with DANE/TLSA for SMTP, you can combine both approaches. We have a separate article focused on a deeper dive into MTA‑STS, TLS‑RPT and DANE/TLSA for SMTP security, where we compare DNSSEC-based and policy-file-based methods.

TLS‑RPT: Seeing When TLS Fails for Your Domain

TLS-RPT (SMTP TLS Reporting) lets participating senders share aggregate TLS success and failure outcomes for delivery to your domain, including MTA-STS and DANE policy results. A report should cover a full UTC day and may arrive later with a delay. Participation and receipt are not guaranteed for every sender or day.

Common problems surfaced by TLS‑RPT include:

• Certificate expiration, trust or hostname-validation failures.
• Missing STARTTLS and MTA-STS policy fetch or validation errors.
• Patterns of failed sessions that warrant checking DNS, TLS and network logs.

The standard JSON schema has no separate TLS-version or cipher-suite fields. A generic error may require sender detail or your SMTP logs to distinguish protocol, cipher, DNS and connectivity problems. Temporary network failures need not be reported.

How TLS‑RPT Works in Practice

To enable TLS‑RPT, you publish a single DNS record at _smtp._tls.example.com. For email-based reporting, this record tells participating senders where to email their aggregate reports as JSON attachments, usually compressed. A typical reporting flow:

1. A participating sender records successful and failed TLS session outcomes.
2. It aggregates policy information, success/failure counts and any failure details over a reporting interval, normally a full UTC day.
3. It submits JSON to a supported URI in the TLS-RPT record, by email attachment or HTTPS POST, possibly after a delay.
4. You validate and process reports, correlating recurrent failures with SMTP logs and configuration changes.

Failure details can identify an affected sender IP, receiving MX/IP and result type when available. Counts for different error types can overlap; they are not necessarily unique messages. Successful TLS sessions do not prove inbox placement.

We usually recommend sending these reports to a dedicated mailbox like tlsrpt@example.com or to a processing service capable of aggregating and visualizing them. Report volume depends on how many senders participate; automated processing is more practical than reading each report manually.

Example TLS‑RPT DNS Record

Here is a minimal TLS‑RPT record:

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com;"

You can list multiple addresses separated by commas:

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,mailto:secops@example.net;"

Publish one valid TLS-RPT TXT record. Reporters may deliver to one supported endpoint rather than every listed address. Check that the mailbox or HTTPS processor works. For emailed reports, require a valid DKIM signature from the reporting domain that does not use l= to limit the signed body length; ignore reports that do not meet these conditions. Handle malformed or oversized attachments safely. There is no universal 24–48-hour startup deadline; lack of reports can reflect sender participation, traffic or report delivery problems.

BIMI: Turning Email Authentication Into Visual Brand Trust

BIMI (Brand Indicators for Message Identification) publishes logo information for participating mailbox providers. Its eligibility depends on DMARC, the provider’s reputation rules and its logo/certificate requirements. It does not replace authentication or guarantee a visible logo.

A missing logo can result from unsupported clients, unmet authentication or reputation conditions, invalid image/certificate files, inaccessible HTTPS assets or caching. Check the target provider’s current requirements before buying a certificate or changing DNS.

BIMI Requirements Before You Start

Before touching BIMI DNS, you should ensure that:

• DMARC enforcement: The organizational domain and relevant subdomains must meet BIMI’s full-enforcement requirement with p=quarantine or p=reject; subdomain policy must not defeat it.
• Message alignment: A passing SPF or DKIM identity must align with the visible From domain for DMARC. Either aligned mechanism can produce a DMARC pass; providers may separately require both SPF and DKIM.
• Reputation: Provider-specific complaint and sending-reputation rules still apply.
• Logo and evidence: Use an SVG Tiny PS logo and the mark certificate required by the receiver. Gmail accepts VMC or CMC and requires the logo-containing PEM file; standalone SVG alone is insufficient there.

The BIMI Group guide rejects partial enforcement such as legacy pct<100. RFC 9989 now classifies pct as historic, so it is a legacy compatibility consideration rather than a newly mandatory DMARC tag. Follow the receiving provider’s current BIMI eligibility instructions.

If you want to go deeper into DMARC analytics, forensic reports and BIMI tuning, we already covered advanced DMARC reporting and BIMI implementation in more depth. Here we will focus on how BIMI interacts with DNS and your hosting.

How BIMI Works: DNS TXT + SVG Logo

The default selector uses default._bimi.example.com. Its TXT record can reference an HTTPS SVG logo and an a= mark-certificate URL. The permitted combination depends on the receiver: Gmail’s current instructions require VMC/CMC evidence with the logo embedded in PEM and also show a record with empty l= and a PEM URL in a=.

The flow looks like this:

1. The mailbox provider receives a message from user@example.com and evaluates authentication and its local policies.
2. If DMARC passes with the required enforcement and other eligibility conditions, it may query default._bimi.example.com.
3. It validates the applicable logo and VMC/CMC evidence, fetching and caching HTTPS resources as required.
4. It may display the logo in a supported interface. This does not attest that every link or claim in the message is safe.

Example BIMI DNS Record and Logo Hosting

This standalone SVG example is only for providers accepting self-asserted BIMI. It does not satisfy Gmail’s certificate requirement:

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://assets.example.com/bimi/logo.svg;"

Where a VMC or CMC is used, add an a= HTTPS URL for the provider-accepted PEM evidence. This example names a VMC file; prepare the actual certificate chain according to the issuer:

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

Key hosting considerations for the logo:

• Use HTTPS with a valid TLS certificate; HTTP will not work.
• Serve from a reliable origin: a subdomain on your main site, a static asset server, or a CDN fronting one of your servers at dchost.com.
• Correct format: BIMI logos must be specific “SVG Tiny Portable/Secure” style files, not arbitrary SVGs. Many providers have validators.

A static origin or CDN can serve the assets if the required HTTPS files remain publicly retrievable and valid. Check access rules, certificate renewal and file validation. Hosting choice alone does not determine BIMI eligibility or logo display.

The DNS Records You Need: Quick Reference

Let’s summarize the core DNS records involved in MTA‑STS, TLS‑RPT and BIMI:

• MTA‑STS TXT record
  • Host: _mta-sts.example.com
  • Value example: v=STSv1; id=20250101T000000;
• MTA‑STS policy host A/AAAA or CNAME
  • Host: mta-sts.example.com
  • Points to the web server that serves /.well-known/mta-sts.txt
• TLS‑RPT TXT record
  • Host: _smtp._tls.example.com
  • Value example: v=TLSRPTv1; rua=mailto:tlsrpt@example.com;
• BIMI TXT record
  • Host: default._bimi.example.com
  • Value example (self-asserted support only, not sufficient for Gmail): v=BIMI1; l=https://assets.example.com/bimi/logo.svg;
• Supporting records (already needed but must be correct)
  • MX records pointing to your mail servers.
  • A/AAAA records for your MX hosts, with proper rDNS/PTR for sending IPs.
  • Valid SPF and DKIM settings; DMARC enforcement when required for the intended BIMI deployment.

If you are also sending email over IPv6, we strongly recommend checking your AAAA, PTR and SPF records for consistency. Our guide on how to deliver email reliably over IPv6 goes through PTR, HELO and blocklist issues that can silently hurt deliverability.

Shared Hosting vs VPS/Dedicated: Where to Host Policies and Logos

Shared hosting, VPS, dedicated and colocated infrastructure can host policy or logo files when the plan supports the necessary DNS and HTTPS controls. Mail-server TLS and MX changes may remain the provider’s responsibility; verify those boundaries before enforcing a policy.

On Shared Hosting

On a typical shared hosting plan:

• Use the actual MX hostnames supplied by the mail service. MX targets must resolve to address records; do not use an ordinary CNAME alias as an MX target.
• Verify which SPF/DKIM settings the panel manages and whether outbound DKIM signing is actually enabled.
• Confirm access to the authoritative DNS zone and permission to publish the required TXT records; a hosting account does not automatically provide this access.

If your shared plan provides the required controls:

• Create mta-sts.example.com, configure its valid HTTPS certificate and serve the exact policy path directly with 200.
• Publish a testing policy containing the service’s real MX names and verify the SMTP certificates separately.
• Host BIMI SVG/PEM files at stable HTTPS URLs, such as https://assets.example.com/bimi/logo.svg, according to receiver requirements.
• Publish the MTA-STS, TLS-RPT and applicable BIMI TXT values in the authoritative DNS editor; avoid duplicate valid records.

Coordinate planned MX or certificate changes with the mail provider. A successful file upload does not prove every receiving MX meets the policy; check primary and backup paths and define who maintains each setting.

On VPS, Dedicated or Colocation Servers

If you run your own mail server stack (Postfix, Exim or similar) on a VPS, dedicated server or colocated hardware at dchost.com, you have more responsibility but also more flexibility:

• You define the MX hostnames and their IP addresses.
• You manage TLS certificates for SMTP, often using Let’s Encrypt.
• You control how aggressively you adopt MTA‑STS enforcement.

For a self-managed mail service, plan these maintenance tasks:

• Use explicit MX FQDNs such as mx1.example.com and mx2.example.com, with address records and valid matching SAN DNS-ID certificates on every served path.
• Automate certificate renewal and verify successful deployment to SMTP and the separate policy HTTPS host; automation itself does not prevent expiry.
• Before changing MX, add the new name alongside old names in the HTTPS policy, then update the TXT id. Account for previously served policy lifetimes and DNS TTLs, keep old MX/TLS paths usable, and verify the new path before retiring the old one. Simultaneous DNS and id edits do not instantly update senders.
• Review TLS-RPT with SMTP logs and policy-fetch monitoring. Configure alerts appropriate to your traffic and reporting coverage.

For customers building more complex setups (multiple MX, backup MX, or split delivery between on‑prem and cloud), it can be useful to revisit your underlying architecture first. Our guide on email redundancy architecture with multiple MX, backup MX and split delivery covers how redundant MX strategies interact with DNS and what to watch out for.

Monitoring, Maintenance and Troubleshooting

Publishing these records is not a fire‑and‑forget operation. They are more like security policies in code: you need to review, adjust and monitor them over time.

Using TLS‑RPT and DMARC Reports Together

In a healthy environment, you should:

• Use DMARC aggregate reports to examine sending identities, SPF/DKIM and alignment results.
• Use TLS-RPT for the recipient domain’s reported TLS session and policy outcomes, including successful-session totals and recurring errors.

These report families concern different directions and identities. Investigate them together, without assuming a one-to-one link between a DMARC message and a TLS-RPT session:

• DMARC may reveal an unauthorized sender or a legitimate platform missing alignment; investigate authorization before adding it to SPF/DKIM.
• TLS-RPT may point to an MX/certificate or policy problem that should be checked against SMTP logs.
• A concentration of failures by sender or destination IP is a lead, not proof of a geographic outage or faulty gateway.

Choose an observation period that covers normal traffic, configuration changes and deliberately tested backup paths. Continue monitoring renewals, MX updates, policy hosting and reporting after enforcement; no fixed two-to-four-week window proves lasting correctness.

Typical Symptoms and Investigation Steps

The following are hypothetical diagnostic examples; a report category alone does not establish the root cause:

• Certificate mismatch: If DNS selects mail.example.com but SMTP presents a certificate only for mx.example.com, deploy a valid certificate for the actual MX. If changing the MX is intentional, prepare policy/cache compatibility and the new endpoint before switching DNS.
• DMARC failures and no BIMI logo: Identify whether the source is an authorized CRM/marketing platform or abuse. Configure legitimate SPF/DKIM and alignment only for authorized sources; do not whitelist a failing sender simply because it appears in a report. Then check full DMARC enforcement and the receiver’s BIMI conditions separately.
• Intermittent enforce failures: Compare the reported MX/IP and result with SMTP tests and logs. Check every address, backup MX and load-balancer path for TLS/certificate inconsistencies; fix the underlying cause and verify subsequent results. Another valid MX may still deliver while one path fails.

Maintain supported TLS versions, valid certificate chains and reliable renewal on the SMTP and web endpoints. OCSP stapling is not a universal MTA-STS prerequisite: Let’s Encrypt ended OCSP in August 2025 and publishes revocation information through CRLs. For the web side, the articles on TLS protocol updates and Nginx/Apache TLS configuration cover related settings; apply certificate-authority-specific advice to your actual certificate.

A Practical Roll‑Out Plan for MTA‑STS, TLS‑RPT and BIMI

A staged rollout separates sender authentication, recipient transport policy and visual-brand eligibility:

1. Inventory identities: List authorized senders, receiving domains, MX names, DNS ownership and certificate responsibilities. A send-only subdomain does not need MTA-STS merely because it sends mail; if it receives mail, its policy is separate and is not inherited from the parent.
2. Validate authentication: Check SPF, actual DKIM signing and DMARC alignment. Preserve existing enforcement; do not weaken a working policy for a new rollout.
3. Prepare transport: Validate all receiving MX/TLS paths and the exact policy HTTPS endpoint. Set up TLS-RPT collection and test the processing pipeline.
4. Publish testing: Serve mode: testing with every intended MX and an appropriate max_age, then publish the TXT id. Observe reports and SMTP logs over representative traffic; explicitly exercise backup paths.
5. Enforce: After resolving failures, update the HTTPS body to mode: enforce and then change id. Retain a cache-aware change/removal plan.
6. Add BIMI: Confirm full DMARC enforcement, receiver eligibility, SVG Tiny PS and required VMC/CMC evidence. Publish validated HTTPS assets and TXT values, then check display in supported mailboxes without assuming a guaranteed deadline.

This staged approach avoids the common trap of deploying everything at once and then having to debug overlapping issues. It also fits well into a broader security and reliability program, where you are already handling TLS, DNS, backups and monitoring systematically. If you are in the process of modernizing your infrastructure anyway, our articles on practical VPS security hardening and 3‑2‑1 backup strategies complement the email-side work.

Conclusion: Turning DNS Into a Security and Brand Asset

MTA-STS, TLS-RPT and BIMI have separate roles: transport policy for incoming SMTP, visibility into reported connection outcomes and eligible brand-logo display. Their usefulness depends on sender/receiver support and ongoing operation; they do not guarantee inbox placement or safe message content.

The infrastructure requirements are concrete: authoritative DNS control, a reliable direct HTTPS policy endpoint, receiving MX servers with valid TLS identities and stable BIMI asset hosting where required. On shared hosting, VPS, dedicated or colocated infrastructure, document which responsibilities belong to you and which belong to the provider.

Begin with a configuration inventory, validate the actual mail paths, and move through testing and enforcement with a maintenance plan. If you use a DCHost service, confirm the plan’s DNS, web and mail controls before changing policies. Keep authentication, incoming transport and branding decisions distinct so a change in one does not silently invalidate another.