TLS and Secure Sending
TLS encrypts email while it moves between mail systems. Bulk senders are now expected to use TLS.
Overview
TLS encrypts email while the message travels between systems. It helps protect the message in transit, much like HTTPS protects a website connection.
TLS does not prove that recipients want a message, and it does not prove that a sender can use a domain. SPF, DKIM, and DMARC handle sender authentication. TLS protects the transport path. Authentication protects sender trust.
There are two secure connections to consider. First, Mailrith connects to your email delivery service. Second, that service connects to receiving inboxes. A built-in service connection manages most of the first connection for you. With Custom SMTP, the host, port, and security mode control how Mailrith connects.
Common Custom SMTP setups use port 587 with STARTTLS or port 465 with TLS from the start. Use the port and security mode listed by your email delivery service. If you guess, test sends can fail.
Some domains also use advanced policies such as MTA-STS or TLS reporting. These policies help organizations that need stronger transport rules. Most Mailrith users should first confirm that the email delivery connection works securely and that SPF, DKIM, DMARC, and alignment pass.
Do not lower security settings only because a test send fails. A TLS error often means the SMTP host, port, certificate, or security mode is incorrect. Fix the cause before you use the connection for real subscribers.
What to Do
- Use Mailrith's built-in connection type instead of Custom SMTP when the email delivery service is supported.
- For Custom SMTP, enter the host, port, and security mode recommended by the email delivery service.
- Send a test email from the Mailrith connection.
- If the test fails with a TLS or certificate error, fix the Custom SMTP settings or ask the email delivery service to fix the certificate before you use the connection.
- Do not change to an insecure setting only to make the test pass unless your email delivery service clearly documents that setup.
- After the connection works, check that SPF, DKIM, DMARC, and alignment pass. A secure SMTP connection does not replace sender authentication.
What to Check
- Use secure connection settings whenever they are available.
- For Custom SMTP, use the port and security mode recommended by your email delivery service.
- Do not ignore TLS-related errors during test sends.
- Keep email delivery service credentials private because TLS cannot protect an exposed credential.
- TLS protects transport; DKIM and DMARC protect sender trust.
- A TLS pass does not mean the email will reach the inbox. It only means the transport was encrypted.
- If you manage your own SMTP server, ask your server or hosting provider to confirm certificates, STARTTLS support, reverse DNS, and IP reputation.
Fix Common Issues
STARTTLS Needs a Server-Side Check
A browser-based SMTP TLS checker can review MX, MTA-STS, and TLS reporting records, but it cannot open a real SMTP STARTTLS connection to each mail server.
- List the MX hosts that the SMTP TLS checker shows.
- Ask your mail administrator or email delivery service to run a server-side SMTP TLS check for each MX host.
- Confirm that each MX host advertises STARTTLS on port 25 for server-to-server mail.
- Confirm that the certificate is valid, is not expired, and matches the mail server hostname.
- Fix certificate or STARTTLS problems before you rely on strict inbound TLS policies.
- After the server-side check passes, review MTA-STS and TLS-RPT if your organization uses them.
No MX Records for SMTP TLS Check
An SMTP TLS checker could not find mail servers for your domain, so the SMTP TLS check has no SMTP hosts to test.
- Confirm that your domain should receive email.
- Open the mailbox provider or DNS provider for your domain.
- Add the MX records provided by the mailbox provider.
- Wait for DNS propagation to finish.
- Run the MX Record Checker first. After the MX check finds the mail servers, run the SMTP TLS Checker again.