# TLS and Secure Sending > TLS protects email while it moves between mail systems and is now a baseline expectation for bulk sending. - Human page: https://mailrith.com/guides/tls - Markdown page: https://mailrith.com/guides/tls.md - Category: Authentication and Deliverability - Reading time: 4 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 free tool, pair the tool result with the relevant issue or step section from this guide. ### TLS and Secure Sending TLS protects email while it moves between mail systems and is now a baseline expectation for bulk sending. TLS is encryption for email while it travels between systems. It helps protect the message as it moves, much like HTTPS protects a website connection. TLS does not prove that a message is wanted, and it does not prove that a sender is allowed to use a domain. That job belongs to [SPF](https://mailrith.com/guides/spf.md), [DKIM](https://mailrith.com/guides/dkim.md), and [DMARC](https://mailrith.com/guides/dmarc.md). TLS protects the transport path. Authentication protects sender trust. There are two TLS paths to think about. First, Mailrith connects to your email delivery service or SMTP server. Second, that service connects to receiving inboxes. With API-based email delivery services, the service usually handles this for you. With custom SMTP, the host, port, and security mode decide how Mailrith connects to the SMTP server. Common SMTP setups use port `587` with STARTTLS or port `465` with TLS from the start. Your SMTP provider's documentation should tell you which one to use. Guessing the port and security mode can cause test sends to fail. Some domains also use advanced policies such as MTA-STS or TLS reporting. These are useful for organizations that need stronger transport rules, but most Mailrith users should first make sure the email delivery connection works securely and authentication passes. Do not lower security settings just because a test send fails. A TLS error often means the SMTP host, port, certificate, or security mode is wrong. Fix that root cause before using the connection for real subscribers. 1. For API-based email delivery services, use the built-in connection type Mailrith offers instead of custom SMTP when possible. 2. For custom SMTP, choose the host, port, and security mode recommended by the SMTP provider. 3. Send a test email from the Mailrith connection. 4. If the test fails with a TLS or certificate error, fix the SMTP settings or SMTP provider certificate before using the connection. 5. Do not downgrade to an insecure setting just to make the test pass unless your SMTP provider explicitly documents that setup. 6. After the connection works, still check SPF, DKIM, DMARC, and alignment. A secure SMTP connection does not replace sender authentication. - Use secure email delivery service APIs or SMTP security settings whenever available. - For custom SMTP, choose the port and security mode recommended by your SMTP provider. - Do not ignore TLS-related errors during test sends. - Keep email delivery service credentials private because TLS does not help if the credential itself is exposed. - 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 about certificates, STARTTLS support, reverse DNS, and IP reputation. ## Fix Common Issues ### STARTTLS Needs a Server-Side Check A browser-based 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 shown by the checker. 2. Ask your mail administrator, SMTP provider, or email delivery service to run a server-side SMTP TLS check for each MX host. 3. Confirm each host advertises STARTTLS on port 25 for server-to-server mail. 4. Confirm the certificate is valid, not expired, and matches the mail server hostname. 5. Fix certificate or STARTTLS problems before relying 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 A checker could not find mail servers for the domain, so it has no SMTP hosts to test. 1. Confirm the domain is supposed to receive email. 2. Open the mailbox provider or DNS provider for the domain. 3. Add the MX records given by the mailbox provider. 4. Wait for DNS propagation. 5. Run the MX Record Checker first, then run the SMTP TLS Checker again. Related resources: - [Set Up Custom SMTP](https://mailrith.com/docs/setup-custom-smtp.md): Choose 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 the name inboxes learn to trust, and authentication proves that your email delivery service is allowed to send for it. - [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email has several sender-related addresses, and each one has a different job in delivery and replies. - [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain, while reverse DNS helps inboxes check whether a sending IP has a sensible hostname.