Exchange 2007 TLS Certificate UntrustedRoot Failure for Domain-Secured SMTP Delivery

Indicators

• Exchange event log error: 'A secure connection to domain-secured domain could not be established'
• TLS validation status reported as 'UntrustedRoot' in Exchange logs or NDR details
• Mail delivery fails only to specific domain-secured domains, not to all recipients
• Removing the affected domain from TLSSendDomainSecureList allows delivery to resume via opportunistic TLS
• Error references the 'Default external mail' send connector in Exchange 2007

Likely causes

• Remote SMTP server certificate issued by an in-house or private certificate authority not present in the Exchange server's Windows trusted root store
• Remote SMTP server recently replaced a publicly trusted certificate with a self-signed or internally signed certificate
• Root CA certificate for the remote server's issuing authority is absent from the Windows Trusted Root Certification Authorities store on the Exchange server
• Remote server's certificate chain is incomplete due to missing intermediate certificates not being presented during the TLS handshake
• Expired or revoked certificate on the remote SMTP server causing chain validation to fail

Diagnostic steps

1. Inspect the remote SMTP server's TLS certificate using STARTTLS on port 25: run 'openssl s_client -connect mail.example.com:25 -starttls smtp' and capture the full output.
2. If the remote server uses implicit TLS on port 465, run: 'openssl s_client -connect mail.example.com:465' instead.
3. Review the OpenSSL output: note the Issuer field, Subject, validity dates (Not Before / Not After), and the full certificate chain presented (look for 'Certificate chain' section and verify depth).
4. Check whether the chain is complete — confirm the root CA certificate is included or can be resolved. A depth of 0 with no chain indicates a self-signed or chain-incomplete certificate.
5. On the Exchange server, open certmgr.msc or use PowerShell ('Get-ChildItem Cert:\LocalMachine\Root') to enumerate trusted root CAs and confirm whether the issuing CA from the OpenSSL output is present.
6. If the root CA is a known private or internal CA, request the root CA certificate file (.cer or .crt) from the remote server's administrator and import it into the Windows Trusted Root Certification Authorities store (Local Computer) on the Exchange server.
7. If the certificate is self-signed or from an unrecognised CA and the remote party cannot provide a trusted root, escalate to the remote administrator to replace the certificate with one issued by a publicly trusted CA (e.g., DigiCert, Sectigo).
8. Re-test TLS delivery by sending a message to the domain-secured recipient domain and verifying Exchange logs no longer report UntrustedRoot.

Resolution path

• Run 'openssl s_client -connect mail.example.com:25 -starttls smtp' to retrieve the remote SMTP server's TLS certificate and chain.
• Identify the certificate issuer (Issuer field) and root CA from the OpenSSL output; note validity dates and chain depth.
• Open certmgr.msc on the Exchange server and check whether the identified root CA is present under Trusted Root Certification Authorities > Certificates (Local Computer).
• If the root CA is a private or internal CA and is missing: obtain the root CA certificate file from the remote administrator and import it into the Trusted Root Certification Authorities store on the Exchange server.
• If the certificate is self-signed or the issuing CA cannot be trusted, coordinate with the remote SMTP server's administrator to replace the certificate with one from a publicly trusted CA.
• Re-test mail delivery to the domain-secured recipient domain and confirm TLS validation succeeds in Exchange event logs.
• Once trust is confirmed, re-add the domain to TLSSendDomainSecureList if it was removed as a temporary workaround, and verify enforced TLS delivery resumes correctly.

Prevention

• Require all remote partners using enforced/domain-secured TLS to use certificates issued by publicly trusted certificate authorities.
• Establish a certificate change notification process with all domain-secured mail partners so that CA changes are communicated before deployment.
• Periodically inspect TLS certificates of domain-secured partner SMTP servers using OpenSSL to detect issuer or expiry changes before they cause delivery failures.
• Monitor Exchange application event logs proactively for TLS-related errors (UntrustedRoot, CertificateExpired, NameMismatch) to catch validation failures early.
• Maintain an up-to-date Windows trusted root certificate store on Exchange servers by ensuring automatic root certificate updates are enabled or managed via GPO.
• Document all non-public root CA certificates imported into Exchange servers, including the issuing partner and expiry dates, for lifecycle management.

Tools

• OpenSSL (openssl s_client) — remote TLS certificate inspection
• Windows Certificate Manager (certmgr.msc) — trusted root store management
• Exchange Management Shell (Exchange 2007 PowerShell) — TLSSendDomainSecureList management
• Exchange Management Console — send connector and domain security configuration
• Windows Event Viewer — Exchange application log for TLS and mail flow errors

References

• How to inspect a remote SMTP server's TLS certificate — ServerFault