MTA-STS MX and certificate mismatches

What mx-mismatch means

The symptom in your TLS-RPT report

When a sending mail server attempts delivery to your domain, it fetches your MTA-STS policy and compares the mx: lines against the actual MX records in DNS. If an MX hostname does not match any pattern listed in the policy, the sender logs an mx-mismatch failure. In enforce mode, the sender refuses to deliver to that MX host entirely.

A typical TLS-RPT JSON snippet for this failure looks like this:

{
  "policy": {
    "policy-type": "sts",
    "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 604800"],
    "policy-domain": "example.com"
  },
  "summary": {
    "total-successful-session-count": 0,
    "total-failure-session-count": 42
  },
  "failure-details": [{
    "result-type": "validation-failure",
    "sending-mta-ip": "198.51.100.5",
    "receiving-mx-hostname": "mail2.example.com",
    "failure-reason-code": "mx-mismatch"
  }]
}

In this example, the policy covers mail.example.com but DNS also returns mail2.example.com as an MX record. Because mail2.example.com is not listed in the policy, the sender reports a failure. In enforce mode, mail destined for that host is not delivered.

Why this matters in enforce mode

In testing mode, senders log the mismatch but deliver anyway. In enforce mode, they drop the connection. If your secondary MX handles 30% of inbound traffic and is not covered by your policy, you lose 30% of your inbound email from senders that support MTA-STS. Google, Microsoft, and other large providers all enforce MTA-STS policies.

Microsoft 365 wildcard pattern

The problem with exact hostnames

Microsoft 365 assigns MX records that look like yourdomain-com.mail.protection.outlook.com. You can verify this with a DNS query:

dig MX example.com +short
10 example-com.mail.protection.outlook.com.

You might be tempted to put the exact hostname in your MTA-STS policy. This is a mistake. Microsoft uses regional variants and can reassign your MX target during infrastructure changes. If the hostname shifts to a regional variant, your policy breaks and senders in enforce mode stop delivering.

The correct policy

Use a wildcard pattern to cover all Microsoft 365 MX hostnames:

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

The wildcard *.mail.protection.outlook.com matches any subdomain under mail.protection.outlook.com, including your tenant-specific hostname and any regional variants Microsoft may assign in the future.

Google Workspace dual MX families

Two wildcard patterns required

Google Workspace uses MX hostnames from two different domain families. A typical DNS query shows:

dig MX example.com +short
1  aspmx.l.google.com.
5  alt1.aspmx.l.google.com.
5  alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

Some Google Workspace configurations also return *.googlemail.com MX hostnames. Your policy must cover both families. If you only list one, senders that connect to an MX from the other family will report mx-mismatch.

The correct policy

version: STSv1
mode: enforce
mx: *.aspmx.l.google.com
mx: aspmx.l.google.com
mx: *.googlemail.com
max_age: 604800

Note that aspmx.l.google.com (the primary MX with no subdomain prefix) needs its own line because the wildcard *.aspmx.l.google.com does not match the bare hostname. Always verify your exact MX records with dig MX before publishing the policy.

Microsoft CNAME restriction

Exchange Online does not follow CNAMEs

If your MX record points to a CNAME rather than an A record, Microsoft's MTA-STS validation fails. This is common with shared hosting providers where your MX target is a CNAME that resolves to the hosting provider's mail server.

For example, your DNS might look like this:

dig MX example.com +short
10 mail.example.com.

dig A mail.example.com +short
# Returns a CNAME to mail.hostingprovider.com, then an IP

Gmail follows the CNAME chain and validates successfully. Exchange Online does not. It compares the MX hostname directly against the TLS certificate and the policy, without following CNAME indirection.

How to diagnose

The signature of this problem is selective failure. Your TLS-RPT reports from Google show zero failures, but reports from Microsoft show consistent validation errors. If you see this pattern, check whether your MX target resolves through a CNAME:

dig A mail.example.com +trace

If the trace reveals a CNAME step, that is your root cause. The fix is to point your MX record directly to an A record (or AAAA record) rather than through a CNAME.

Certificate-host-mismatch on MX servers

The symptom

Your TLS-RPT report shows a certificate-host-mismatch result type. This means the sending server connected to your MX host, initiated STARTTLS, and received a TLS certificate that does not cover the MX hostname.

{
  "failure-details": [{
    "result-type": "certificate-host-mismatch",
    "sending-mta-ip": "203.0.113.10",
    "receiving-mx-hostname": "mail.example.com",
    "failure-reason-code": "Certificate CN/SAN does not match MX hostname"
  }]
}

Common causes

This happens most often after a mail server migration or with shared hosting. Your MX record points to mail.example.com, but the TLS certificate on that server covers mail.hostingprovider.com. The certificate's Subject Alternative Name (SAN) list must include the MX hostname that senders connect to.

Diagnosis with openssl

Connect to your MX server and inspect the certificate it presents:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

The output shows the SAN entries in the certificate. If mail.example.com is not listed as a DNS name in the SAN field, you have found the problem.

The fix

You have two options:

• Update the certificate. Request or generate a certificate that includes your MX hostname in the SAN list. If you use Let's Encrypt, add the MX hostname to your certificate request.
• Change your MX record. If you cannot control the certificate (shared hosting), change your MX record to point to the hostname that the certificate actually covers, then update your MTA-STS policy to match.

Incomplete certificate chain

The problem

Your mail server sends only the end-entity (leaf) certificate during the TLS handshake, without the intermediate certificates that chain up to a trusted root CA. Some sending MTAs perform strict chain validation and reject the connection when intermediates are missing.

Diagnosis

Inspect the certificate chain your server presents:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com 2>/dev/null

Look at the output near the top. A healthy chain shows multiple certificates:

Certificate chain
 0 s:CN = mail.example.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

If you only see certificate 0 with no intermediates, the chain is incomplete. Check the Verify return code line at the bottom of the output. A code of 21 (unable to verify the first certificate) confirms the missing intermediate.

The fix

Configure your mail server to serve the full certificate chain. The method depends on your MTA:

• Postfix: Set smtpd_tls_cert_file to a file containing the leaf certificate followed by the intermediate certificates, in order.
• Exim: Set tls_certificate to the full chain file.
• Exchange: Re-import the certificate with the full chain using the Exchange Admin Center or PowerShell.

After updating, verify the chain with the same openssl s_client command. You should see all intermediate certificates in the chain output and a Verify return code: 0 (ok).

starttls-not-supported

The problem

A starttls-not-supported failure means a sending MTA connected to one of your MX servers and the server did not advertise STARTTLS in its EHLO response. In MTA-STS enforce mode, senders require TLS on every MX host listed in the policy. If any MX server does not support STARTTLS, mail routed to that server is rejected.

{
  "failure-details": [{
    "result-type": "starttls-not-supported",
    "sending-mta-ip": "192.0.2.50",
    "receiving-mx-hostname": "backup-mx.example.com"
  }]
}

Why backup MX servers are the usual culprit

Primary MX servers are typically well-maintained with current TLS configurations. Backup or secondary MX servers, especially those run by a different hosting provider or a legacy appliance, are often overlooked. They accept connections on port 25 but never had STARTTLS configured because they were set up years ago when opportunistic TLS was not expected.

Diagnosis

Test each MX server for STARTTLS support:

# List all MX servers
dig MX example.com +short

# Test STARTTLS on each one
openssl s_client -starttls smtp -connect backup-mx.example.com:25 -servername backup-mx.example.com

If openssl reports an error like didn't find starttls in server response, that MX server does not support STARTTLS.

The fix

• Enable STARTTLS on the backup MX. Install a valid TLS certificate and enable STARTTLS in the MTA configuration.
• Remove the backup MX from DNS. If the backup MX is not critical, remove it from your DNS MX records. Then remove it from your MTA-STS policy as well.
• Do not list it in the policy. If you keep the MX record in DNS but omit it from the MTA-STS policy, senders in enforce mode will not deliver to it. This effectively deprioritizes it for MTA-STS-aware senders, but non-MTA-STS senders may still route mail there without TLS.

Every MX hostname listed in your MTA-STS policy must support STARTTLS with a valid, matching certificate. There are no exceptions in enforce mode.

Prevention

Validate MX coverage before publishing

Before switching your MTA-STS policy to enforce mode, verify that every MX record in your DNS is covered by an mx: line in your policy. Run dig MX for your domain and compare the output against your mta-sts.txt file line by line.

Test every MX server's TLS configuration

For each MX hostname, confirm three things: STARTTLS is advertised, the certificate matches the hostname, and the full certificate chain is served. The openssl s_client -starttls smtp command covers all three checks in a single connection.

Use DMARCTrust to catch mismatches early

The DMARCTrust domain checker validates your MX coverage against your MTA-STS policy and checks TLS certificates on each MX host. Receiver Shield auto-detects your MX hosts from DNS and warns you about uncovered servers, certificate mismatches, and missing STARTTLS before they cause delivery failures.

For a deeper understanding of MTA-STS policies and deployment, see our MTA-STS fundamentals guide.

Related guides

• MTA-STS policy fetch failures: DNS errors, HTTPS problems, and policy syntax
• SPF errors: permerror, too many lookups, and syntax failures
• DKIM failures: body hash mismatch, expired signatures, and missing keys
• DMARC policy migration: from p=none to p=reject