Email, the great security hole of all IT. We need it, most of our users (if not all) have access. It remains a top threat vector for the bad actors. Think about it, many ransomware attacks start with an email. Whaling and spear phishing, email, compromised credentials. So, it’s important that those of us who administer emails keep up with the current protections we have at our disposal to mitigate this threat.
Three Protections
There are three protections that we can implement that many email administrators either miss, or because they are also DNS protections, they assume the DNS team have that covered.
SPF – Sender Policy Framework (SPF) hardens your DNS servers and restricts who can send emails from your domain. SPF can prevent domain spoofing. It enables your mail server to determine when a message came from the domain that it uses.
How do we test SPF, on windows open a command prompt and type nslookup -type=txt google.com (where google.com is your domain name).
You should get the following type response: “v=spf1 include:_spf.google.com ~all” You may have other domains in there too if you allow others to send an email on your behalf. You should make sure you justify all the items in there, for example, many companies allow a third party to send on their behalf. A good example is “include:spf.mandrillapp.com.” We should check on regular intervals with the marketing team if they still use that and remove the unneeded domains when they are retired.
DKIM – DomainKeys Identified Mail (DKIM) ensures the content of your emails remains trusted and hasn’t been tampered with or compromised.
DKIM signs your email with a digital signature. That way a receiver of the email can be sure the mail came from us. It’s been proposed that if we mandate all organizations use DKIM to lower the overall amount of spam that gets through. For obvious functional reasons, there is a lot of opposition.
How do we check for DKIM? The same way we open a command prompt and type nslookup -type=txt (selector name, found in the SPF results for example the google selector was 20161025) 20161025._domainkey.gmail.com (where google.com is your domain name).
You should see a response with a cryptographic key that looks like this “k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqR””tqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB”.
While this is a protection for the people we send emails to, the more it is adopted the better our spam filtering will become. Currently, many spam filters allow to either tag emails without DKIM or block them. If you block them today, you may find you’re missing a lot of valid emails.
DMARC – Domain-based Message Authentication, Reporting and Conformance (DMARC) ties the first two protocols together with a consistent set of policies. It also links the sender’s domain name with what is listed in the From: header.
To test our DMARC again we use nslookup and type=txt and append _dmarc to the domain name like: _dmarc.gmail.com and hit enter.
And we get “v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com”
Why all Three?
Each solves a somewhat different piece of the email puzzle to prevent phishing and spam. If your email infrastructure implements all three protocols properly, you can ensure that messages can’t be easily forged and that you have a better chance to block them. Spammers are constantly adapting, so email administrators need to continuously fight this battle.
