// how to fix
Emails sent without TLS encryption (STARTTLS)
Your server delivered the email in clear text, without encryption. Gmail flags this with a red padlock and expects bulk senders to use TLS. Turn on STARTTLS.
What it means
When your server delivers an email to another server, the two can agree to encrypt the connection. This is called TLS, and the command that starts it on a normal mail connection is STARTTLS.
Your email was delivered without encryption. Anyone able to watch the network between the two servers could read it.
Why it matters
- Gmail shows a red open padlock on emails received without encryption, which worries readers.
- Gmail and Yahoo expect bulk senders to use TLS.
- Emails often contain personal or business information that should not travel in clear text.
- Delivmail removes a small part of the score for an unencrypted delivery.
How to check
- Send a test email: on the home page, copy your unique test address, send it a normal email from the mailbox or tool you want to check, then open the report. The "Encryption (TLS)" line says whether the email arrived encrypted.
- In Gmail, open a received email, click the small arrow under the sender name and look at the "security" line.
How to fix it
If you use a provider
Google Workspace, Microsoft 365 and all serious newsletter tools use TLS automatically. If your test shows no TLS, the email probably went through another system: a website, a printer, a business application or an old relay server. Find it and make it send through your provider instead.
If you run your own mail server
- Get a certificate for your server name, for example
mail.yourdomain.com. A free certificate from Let's Encrypt works well. - Turn on outgoing TLS. On Postfix, for example:
smtp_tls_security_level = may smtp_tls_loglevel = 1
The settingmayencrypts whenever the other server supports it, which almost all do today. - Turn on incoming TLS too, so others can send to you securely:
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail.yourdomain.com/privkey.pem smtpd_tls_security_level = may
- Reload the server and check its logs for lines mentioning TLS.
- Renew the certificate automatically. An expired certificate can break encrypted delivery.
If you send from an application
In your application's SMTP settings, choose port 587 with STARTTLS, or port 465 with SSL/TLS. Avoid port 25 without encryption. This protects the connection between your application and your provider; your provider then handles TLS to the recipient.
Check that it is fixed
Send a new test email from the home page with the same server or tool. The "Encryption (TLS)" line should say yes. In Gmail, the red padlock should be gone. If it still says no, check that the email really left through the server you changed, and look at its logs for TLS errors such as an expired or untrusted certificate.
Check that it is fixed
DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.
Related guides
- Move DMARC from p=none to quarantine or reject safelyp=none only watches. To really stop fake emails using your domain, move step by step to quarantine and reject, without blocking your own emails.
- Your sending IP address is on a blacklistA blacklist is a public list of IP addresses known for sending spam. Find out if the IP is yours, fix the cause, then ask for removal.
- Your domain is on a blacklist (Spamhaus DBL, SURBL, URIBL)Domain blacklists list domain names seen in spam. They follow your domain wherever you send from. Find the cause, clean up, then request removal.
- Protect your incoming mail with MTA-STS and TLS-RPTMTA-STS forces other servers to use encryption when they deliver email to your domain. TLS-RPT sends you reports when that fails. Both are optional but recommended.
- Someone sends fake emails with your domain (spoofing)Scammers can send emails that look like they come from your domain. A DMARC policy at reject tells receivers to refuse them. Monitor first, then enforce.