# TLS and Secure Sending > TLS encrypts email while it moves between mail systems. Bulk senders are now expected to use TLS. - Human page: https://mailrith.com/guides/tls - Markdown page: https://mailrith.com/guides/tls.md - Category: Authentication and Deliverability - Reading time: 5 min read - Related keywords: TLS and Secure Sending, TLS and Secure Sending guide, Authentication and Deliverability, Authentication and Deliverability guide, email sending guide, email marketing guide, email deliverability guide, Set Up Custom SMTP ## AI Agent Notes - Use this page as plain-language guidance for the specific email sending issue named in the title. - Preserve the distinction between Mailrith, an email delivery service, DNS, and inbox providers when explaining fixes. - When a user is running a Mailrith free tool, pair that specific free-tool result with the relevant issue or step section from this guide. ### TLS and Secure Sending TLS encrypts email while it moves between mail systems. Bulk senders are now expected to use TLS. 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](https://mailrith.com/guides/spf.md), [DKIM](https://mailrith.com/guides/dkim.md), and [DMARC](https://mailrith.com/guides/dmarc.md) 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. 1. Use Mailrith's built-in connection type instead of Custom SMTP when the email delivery service is supported. 2. For Custom SMTP, enter the host, port, and security mode recommended by the email delivery service. 3. Send a test email from the Mailrith connection. 4. 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. 5. Do not change to an insecure setting only to make the test pass unless your email delivery service clearly documents that setup. 6. After the connection works, check that SPF, DKIM, DMARC, and alignment pass. A secure SMTP connection does not replace sender authentication. - 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](https://mailrith.com/guides/dkim.md) and [DMARC](https://mailrith.com/guides/dmarc.md) 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. 1. List the MX hosts that the SMTP TLS checker shows. 2. Ask your mail administrator or email delivery service to run a server-side SMTP TLS check for each MX host. 3. Confirm that each MX host advertises STARTTLS on port 25 for server-to-server mail. 4. Confirm that the certificate is valid, is not expired, and matches the mail server hostname. 5. Fix certificate or STARTTLS problems before you rely on strict inbound TLS policies. 6. 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. 1. Confirm that your domain should receive email. 2. Open the mailbox provider or DNS provider for your domain. 3. Add the MX records provided by the mailbox provider. 4. Wait for DNS propagation to finish. 5. Run the MX Record Checker first. After the MX check finds the mail servers, run the SMTP TLS Checker again. Related resources: - [Set Up Custom SMTP](https://mailrith.com/docs/setup-custom-smtp.md): Choose the SMTP host, port, security mode, username, and password. ## Related Guides - [Sender Domains and Email Authentication](https://mailrith.com/guides/sender-domains-and-authentication.md): Your sender domain is what inbox providers learn to trust. Authentication proves that your email delivery service is allowed to send email for your domain. - [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email can include several sender-related addresses. Each address has a separate role for delivery, authentication, or replies. - [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain. Reverse DNS helps inbox providers check that a sending IP address has a valid hostname.