< back to blog

Mandatory DANE for Exchange Online Outbound Connectors

TLS ReportingMail Providers

Introduction

Microsoft has released configurable SMTP DANE and MTA-STS modes for Exchange Online outbound connectors. This gives administrators explicit, per-connector control over how strictly Exchange Online enforces transport security when sending email to external domains.

Replacing IP-pinned connectors with DANE Mandatory in Exchange Online

For MSPs and IT teams, the headline feature is the new Mandatory mode for SMTP DANE — which effectively lets you require that a partner domain supports DANE with DNSSEC before Exchange Online will deliver mail to them. If the destination doesn’t support it or validation fails, mail is queued, retried for 24 hours then eventually dropped.

This is a significant step forward for organisations that have historically relied on IP-pinned outbound connectors to secure mail flow to critical partners.

What Are the New Modes?

The new -SmtpDaneMode and -MtaStsMode parameters on Set-OutboundConnector support the following values:

SMTP DANE Modes

  • Opportunistic (default): Exchange Online attempts SMTP DANE validation when the destination supports it. If the destination doesn’t support DANE, mail is delivered normally.
  • Mandatory: Enforces full SMTP DANE with DNSSEC validation. If the destination doesn’t support DANE or validation fails, mail is queued for 24 hours and then dropped.
  • None: Disables SMTP DANE validation entirely for the connector.

MTA-STS Modes

  • Opportunistic (default): Exchange Online attempts MTA-STS validation when available but continues delivery if the destination doesn’t support it.
  • None: Disables MTA-STS validation for the connector.

Note that MTA-STS does not have a Mandatory mode — only SMTP DANE does.

Example: Setting DANE to Mandatory

Set-OutboundConnector "Contoso Bank Connector" -SmtpDaneMode Mandatory

The Real Use Case: Replacing IP-Pinned Partner Connectors

Many MSPs and IT teams will recognise this pattern: a customer needs to send email to a critical partner — a bank, an insurer, a government agency — and wants assurance that mail is going to the right place. The traditional solution was an outbound connector configured with:

  • RecipientDomains scoped to the partner’s domain
  • UseMxRecord $false with SmartHosts locked to specific IP addresses
  • TlsSettings set to require a certificate matching a specific domain

This works, but it’s fragile. IPs change when partners migrate infrastructure. Certificate subjects change when partners renew or switch providers. Every change requires manual coordination and connector updates — often discovered only when mail starts bouncing.

How DANE Mandatory Replaces This

With DANE Mandatory on an outbound connector, you get the same security guarantee through cryptographic verification instead of hardcoded infrastructure details:

  1. The partner publishes DNSSEC-signed DNS records and TLSA records for their mail servers
  2. You scope an outbound connector to their domain and set -SmtpDaneMode Mandatory
  3. Exchange Online verifies the full DNSSEC chain and TLSA certificate match on every delivery attempt
  4. If anything is wrong — spoofed MX, invalid certificate, missing TLSA records, or the partner removes DANE support entirely — mail is held, not delivered to the wrong place

The partner can change IPs, rotate certificates, and migrate infrastructure without you needing to update your connector. As long as their DANE and DNSSEC records are correct, mail flows securely. No more emergency calls when a bank changes hosting providers.

What About MTA-STS?

MTA-STS achieves similar goals to DANE but without requiring DNSSEC. It’s simpler to deploy and is already widely supported. However, the new connector modes only offer Opportunistic and None for MTA-STS — there’s no Mandatory option.

In practice, this means:

  • If your partner supports DANE with DNSSEC, you can enforce it with Mandatory mode
  • If your partner only supports MTA-STS, you can’t enforce it at the connector level — Exchange Online will use it opportunistically but won’t hold mail if the partner doesn’t have an MTA-STS enforce policy
  • You can still disable either protocol per connector using None, which is useful for troubleshooting delivery issues with partners that have misconfigured implementations

For most MSP-managed environments, DANE Mandatory on critical partner connectors combined with default Opportunistic MTA-STS or DANE where enforced by partners is a practical configuration.

Monitoring with TLS Reporting

Enforcing DANE on your outbound connectors is one side of the equation. Exchange Online message tracking will show you when outbound DANE validation fails on your connectors.

But as DANE adoption grows, your partners and other sending organisations may also enforce DANE when delivering mail to your domains. If your own TLSA records become stale after a certificate rotation or your DNSSEC chain breaks, those senders will fail to deliver to you.

This is where SMTP TLS Reporting (TLS-RPT) comes in. TLS reports provide feedback from sending servers about their TLS connection outcomes when delivering to your domains — including DANE and MTA-STS validation failures. Before a partner enforces DANE for mail they send to you, make sure your own house is in order.

With VerifyDMARC, you can:

  1. Monitor TLS failures across all your managed domains from a single dashboard
  2. Receive TLS failure alerts when issues are detected, helping you catch problems before they escalate
  3. Track TLS connection trends to identify senders experiencing DANE or MTA-STS validation failures when connecting to your domains

Tip: Enable TLS Reporting for your managed domains and monitor reports in VerifyDMARC to ensure sending servers can validate your TLSA records and DNSSEC chain successfully.

Practical Steps for MSPs

Before You Start

  1. Identify which domains have IP-pinned outbound connectors to partner domains
  2. Check whether those partner domains support DANE with DNSSEC using the VerifyDMARC domain checker — look for DNSSEC Enabled, DANE TLSA Records Found, and ideally SMTP TLS Reporting configured
  3. Talk to your clients and their respective partner’s technical teams about the benefits of moving from IP-pinned connectors to DANE — reduced maintenance, no more emergency changes when IPs or certificates rotate, and cryptographic verification instead of infrastructure-level trust
  4. Ensure TLS Reporting is enabled for your domains in VerifyDMARC

Transitioning a Connector

  1. Leave the existing connector in place — don’t remove the IP-pinned configuration yet
  2. Verify the partner supports DANE: Confirm their domain has valid DNSSEC signatures and TLSA records published for their MX hosts
  3. Update the connector to use MX records: Set -UseMxRecord $true and remove the SmartHosts configuration
  4. Set DANE to Opportunistic first: -SmtpDaneMode Opportunistic — this is the default, so you’re confirming Exchange Online can validate DANE for this partner without enforcement
  5. Monitor message trace in Exchange Online for a few weeks to confirm consistent DANE validation success
  6. Switch to Mandatory: -SmtpDaneMode Mandatory — mail will now only deliver if DANE validation passes
  7. Document the change and set a reminder to review TLS reports periodically

If the Partner Doesn’t Support DANE

If the partner only supports MTA-STS, you still benefit from default Opportunistic validation but can’t enforce that the partner maintains this security posture at the connector level. In this case, the existing IP-pinned connector may still be the most appropriate option until the partner adopts DANE.

Encourage partners to adopt DANE with DNSSEC or at minimum MTA-STS with an enforce policy — it’s in everyone’s interest to move beyond IP-based trust.

Summary

Microsoft’s new connector modes are a welcome addition. The ability to enforce DANE on a per-connector basis gives MSPs and IT teams a modern, cryptographic alternative to the fragile IP-pinned connectors that have been the go-to for securing critical partner mail flows.

The key takeaway: if you have customers with outbound connectors locked to partner IPs, check whether those partners now support DANE with DNSSEC. If they do, you have a path to replace brittle infrastructure-level controls with protocol-level security that survives partner infrastructure changes.

And whatever you do, make sure you have TLS Reporting in place on your mail receiving domains.

Sign up for a 30-day free trial of VerifyDMARC to monitor your TLS connections and get visibility into DANE and MTA-STS validation across all your managed domains.

Start Free Trial