First, a block-all SPF txt record:

v=spf1 -all

And a DMARC policy that rejects all email that fails SPF.

v=DMARC1; p=reject; adkim=s; aspf=s;

And that’s it, quite simple steps that are enough to stop any spam emails sent from the domain.

Thanks to Alex Blackie for the excellent tip.

Not anymore with the use of TLS, StartTLS, or even better S/MIME which is suitable for your most sensitive information.

Every email sent through TLS is encrypted to protect the message in transit from one server to another. It requires both mail servers to follow along in order for the encryption to work. But not all mail servers are equally made. If an email is sent via TLS but the other end doesn’t accept TLS, the email will be degraded from TLS. Like back to the old days, email gets decrypted and delivered in plain text. Bad news for you but good news for the man in the middle.

According to Google, during a 3-month period between March 11, 2019, and June 9, 2019, 89% of emails going out from Gmail and 94% of email received by Gmail are encrypted. And who are the top bad guys?

So how to tell if my incoming emails are encrypted

Gmail

Google is on top of a lot of things. This is no different. If you are using Gmail as your main mail app, you can easily tell whether the email you received has never been intercepted by the man in the middle.

When you get an email, click the little down arrow to reveal the header and you will find if the message was received through TLS or other encryption method.

Outlook

Not as easy as Gmail but still can be done. Open the email you received from outside, click File > Properties.

And look through the Internet headers section. If you see the word TLS in there somewhere you can safely tell your email is safe during the transition.

How to tell if email I am sending is encrypted

For Gmail, if you have S/MIME enabled on your account, you will see a lock icon that shows the level of encryption supported by your message’s recipients. Otherwise, there is no direct way to tell whether your email will be safe all the way to the other end.

But there are a few workarounds that we can still take.

First, we can start with an introduction email and only start sending confidential content after receiving one email from other party and verified that it’s safe.

Or, we can use a TLS checker to scan and verify that the mail server used by the domain you are communicating with supports at least TLS. It’s safe to email me confidential stuff because it’s OK in the TLS column like below.

But never send confidential emails to the mail server that’s not safe like below.

Last, if you are using Gmail and need the highest security for sending confidential via email, you can turn on the Confidential Mode so entire email communication will be secured.

Dig it a little deeper by performing a MX lookup to all these domains that we had problem sending emails to and found out that pretty much all of them have secureserver.net associated as their MX records. Meaning that emails sent to their inboxes have to go through and pass secureserver.net.

And one of the requests in order to get pass secureserver.net is that IP address of sender’s email server has to have a valid Reverse DNS entry associated. The email won’t get rejected right away if the sender’s IP address doesn’t meet this requirement. It will be delayed and put in the message queue first to give you more time to fix the issue. And if the problem is still not resolved before the message expires, an NDR email will be sent to sender.

That makes sense. We have recently changed ISP and had one new external IP address assigned to our mail server. And one thing I totally forgot is to check this Reverse DNS. Once I got my ISP to change it to what I wanted, emails started to flow to these domains again. Problem solved!

So if you relay all your emails to your ISP before they are sent out, you actually don’t need to worry about it because they all have the proper Reverse DNS entry set up to IP addresses that belong to them.

But if your email setup like ours that all emails are sent out directly from our email server, then you will have to make sure you have the proper Reverse DNS set up on the IP addresses that are responsible for sending emails. Here is the guideline from unblock.secureserver.net.

Verify that your rDNS contains a name that includes "mail", "SMTP", "relay", or "MX". For example: mail.example.com, smtp.example.com, or mx1.example.com.