TLS Failure Alerts: Monitoring for MTA-STS and DANE

Introduction

For organisations using MTA-STS or DANE to enforce encrypted email delivery, monitoring for TLS failures is crucial. When these policies are enforced, configuration issues can lead to email delivery failures rather than falling back to unencrypted delivery. Today, we're introducing TLS Failure Alerts to help quickly notify you of potential disruption to your inbound email.

Why You Need TLS Failure Alerts

If you're using MTA-STS or DANE with TLSA records, your email infrastructure is configured to require encrypted connections. While this significantly enhances security, it also means that TLS connection failures will prevent email delivery entirely. Common scenarios include:

• MX record changes that don't match your MTA-STS policy
• DNS changes affecting your MTA-STS policy file availability
• Expired or misconfigured SSL/TLS certificates
• Outdated DANE TLSA records after certificate rotation

Without proactive monitoring, you might only discover these issues when important emails fail to arrive.

How It Works

TLS Failure Alerts leverage SMTP TLS Reporting (TLS-RPT) to monitor connection attempts from external mail servers. When an external mail server attempts to deliver email to your domain and encounters TLS failures, they generate an SMTP TLS report. As soon as we process this report, you'll receive an alert email containing the affected domain.

From there you can go to the VerifyDMARC Dashboard to further investigate the nature of the failure.

To prevent alert fatigue we suppress further failure alerts for the same domain for 7 days.

Note that there is typically a delay between when TLS failures occur and when we receive the reports from external mail servers. This means alerts are not real-time notifications of failures, but rather prompt notifications when we learn about failures through received reports.

Setting Up Monitoring

To enable TLS Failure Alerts, you'll need:

1. Turn On TLS Reporting for the domains
2. Alert Email Addresses configured in Settings > Organisation

Recommended: Out-of-Band Alert Addresses

When enforcing TLS with MTA-STS or DANE, it's a good idea to use an "out-of-band" email address for alerts. For example:

• If your domain is contoso.com, don't use alerts@contoso.com
• Instead, use alerts@contoso.onmicrosoft.com or another domain without enforced TLS
• This ensures you'll receive alerts even when TLS issues would prevent delivery to your primary domain

Example: Preventing Email Disruption

Here's how TLS Failure Alerts help in a common scenario:

1. Your organisation changes email providers
2. New MX records are published
3. External servers attempt delivery but fail TLS verification
4. We receive and process TLS reports about the failures
5. You receive an alert from VerifyDMARC
6. In the VerifyDMARC Dashboard you identify the root cause
7. You update your MTA-STS policy file with the new MX records and MTA-STS DNS record ID
8. Email delivery continues with disruption minimised

Without alerts, this situation could lead to a configuration issue being overlooked for longer than necessary.

Best Practices

If you're using MTA-STS or DANE:

1. Setup SMTP TLS Reporting in VerifyDMARC
2. Configure an out-of-band alert address in Settings > Organisation
3. Document your response procedure for TLS failure alerts

Stay Secure Without Disruption

TLS Failure Alerts are now automatically enabled for all customers using SMTP TLS Reporting with Alert Email Addresses configured. This feature helps you maintain strict security requirements without risking email availability.

Not a VerifyDMARC Customer?

Sign up for our 30-day free trial to experience the benefits of TLS Reporting and our comprehensive DMARC management platform. Don't wait - take control of your email security today with VerifyDMARC.​​​​​​​​​​​​​​​​