Skip to content

Knowledgebase

Investigating TLS delivery failures through email filtering

email, security-ssl

Review both inbound TLS connections when requiring encrypted delivery through SpamExperts: the sender to the filter, and the filter to your mailbox server. These controls are separate from outgoing filtering and from message-content encryption.

01 Apply an approved requirement

  1. Identify the sender or recipient scope and the business reason for compulsory TLS.
  2. Confirm the participating mail servers support the required secure connection and present appropriate certificates.
  3. Open the domain's Incoming - Protection Settings > Filter settings.
  4. Review the settings for incoming email TLS and delivery-to-destination TLS separately. Apply the narrow requirement that has been agreed.
  5. Save and test the relevant route. Monitor logs and the delivery queue for TLS-related failures.

02 Plan failure handling

A compulsory TLS policy can prevent delivery when a partner's server cannot establish the required connection. Agree the response and escalation route before enforcing it for important business traffic.

03 Example: find which encrypted-delivery connection failed

For mail passing through a filtering service, investigate the sender-to-filter connection separately from the filter-to-mailbox-server connection. A working TLS connection on the first leg does not prove the second leg can deliver.

Preserve the diagnostic message and identify the hostname used on the failing connection. Check the relevant certificate, trust chain, service reachability and policy requirement. A certificate for another hostname may not satisfy the configured verification.

Should I disable TLS to release queued mail?

Do not remove a compulsory security requirement without authorisation. Establish why it was required and whether an approved, time-limited exception is appropriate. Correct the underlying certificate or connection issue where possible.

After the correction, test the affected route with a harmless message and inspect the queue or delivery result. Avoid repeatedly resending important business messages while their original copies remain queued. Contact us with the filter service, destination domain, time and exact error when you need help. Keep message bodies and mailbox credentials out of the diagnostic unless a specific authorised excerpt is necessary.

Common questions

Does opportunistic TLS guarantee every message is encrypted?

It uses TLS when the participating server supports it. A requirement to reject unencrypted delivery is a separate policy choice.

Does incoming enforcement protect outgoing mail?

No. Outgoing enforcement has its own configuration and can require provider assistance. Ask us for the appropriate supported setup.

Does TLS hide the message from every mail provider?

TLS protects a network connection. It is different from end-to-end content encryption, where only intended recipients hold the decryption capability.

If delivery stops after the change, preserve the error and identify the failing connection. Correct the certificate, hostname or partner capability rather than disabling all security settings. Any temporary policy exception should have an explicit scope and review date.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support

Powered by WHMCompleteSolution