How to identify a risky email like a pro

According to Egress, 94% of organisations were victims of phishing attacks in 2023, which is a 40% increase from 2022

In fact 79% of ATO attacks started with phishing and 95% of cybersecurity leaders are stressed about email security. 

Email is a big deal and a major industry because it’s how the world communicates, the rest of the world is built on excel, everyone knows this.  That is why you need to be able to identify a risky email.  I am not talking about the front end of the mail here, like how the logo is slightly not aligned or been skewed.  Or that the fonts are different, the tone is off and there are spell checks.  I am talking about the email domain and the servers who send the email.

If you could check to see if all those specific built in email protocols are in place, most of the time you wouldn’t even open the email, as it would most likely be a phishing email at worst or at best spam.

Be sure to get your FREE Security Risk Assessment on us which covers most of the controls listed below.

Here is a step-by-step guide on how to identify risky email like a pro.

1. SPF Records

A sender policy framework (SPF) record is a type of DNS TXT record that lists all the servers authorised to send emails from a particular domain.  This record is checked when receiving an email, the domain is referenced to the SPF record and if things don’t match up the mail is rejected or marked as spam.

Basically, you want to look at the structure of the SPF record and cross reference that with the email received.  If the servers don’t match, you have a problem.  If the domain or ip’s are flagged for sending some dodgy messages, guess what, you have a problem.

For a detailed breakdown check out this article on Cloudflare

The SPF records can be checked from a number of sites like MxToolbox & EasyDMARC

Or go pro and use a tool from GitHub like checkdmarc

Checkdmarc does an in-depth look into SPF records and checks all records and provided warnings when it finds issues.

2. DKIM

DomainKeys Identified Mail (DKIM) is a method of email authentication that helps prevent spammers and other malicious parties from impersonating a legitimate domain.

Basically, DKIM uses private and public keys to ensure that the email coming from the sender is actually from the sender, and this is super important because if this did not exist, anyone could spoof an email and pretend to be someone else.

For a deep dive into how DKIM works check out this article by Cloudflare

You could use DKIM Record Checker to bring back results on a domain by using EasyDMARC however this is not cut and dry test as you don’t have the keys to compare.

Which is why you need our next step.

3. DMARC

Domain-based Message Authentication Reporting and Conformance (DMARC) is a method of authenticating email messages. A DMARC policy tells a receiving email server what to do after checking a domain's Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records, which we have already covered. 

So the DMARC policy checks the SPK and DKIM results and then tells the email server what to do with that email.  It also tells other email servers if that domain doesn’t even send emails.  Check out the full write up by Cloudflare.

To keep you on your toes I have found another DMARC checker other than the other sites I have listed above.  Use dmarcian to check a DMARC record.

And as a pro you can run the GitHub repo checkdmarc which will showcase any warnings in the DMARC config.

4. DNSSEC

DNS Security Extensions (DNSSEC) is a security protocol created to mitigate this problem. DNSSEC protects against attacks by digitally signing data to help ensure its validity. In order to ensure a secure lookup, the signing must happen at every level in the DNS lookup process.

I believe Cloudflare does a great deep dive into DNSSEC, so I am not going to do that here.  The TLDR is that you should enable DNSSEC because it will make sure the DNS chain is trusted, so that no sneaky attackers can poison the chain and perform DNS attacks.

Use Verisign Labs to check DNSSEC

Or like a pro just run the GitHub repo checkdmarc

5. MTA-STS

Emails crossing the internet use secure connections encrypted using Transport Layer Security (TLS). However, there remain vulnerabilities in this method of protecting the confidentiality of emails, whereby a person-in-the-middle can trick incoming connections to send to another server and/or send information in the clear. MTA-STS is a standard designed to address these vulnerabilities and is set out in the internet standard IETF RFC 8461.

Read a more in-depth breakdown at National Cyber Security Centre

To perform a MTA-STS Lookup check out MxToolbox MTA-STS Lookup

Or like a pro just run the GitHub repo checkdmarc

6. SMTP TLS reporting

SMTP TLS Reporting (sometimes abbreviated as TLS-RPT) is a reporting standard for secure email delivery.

SMTP TLS reporting is a way to check if emails sent to your domain are using a secure connection. It helps you make sure your emails are protected from being intercepted or tampered with.

Read a full description here at Mailhardener 

Use the SMTP TLS reporting validator from Mailhardener to verify a domains policy

Or like a pro just run the GitHub repo checkdmarc

7. Display Name (From) vs Sender Address

This is something that has grown increasingly over the past few months and while primitive very sneaky and effective.  The reason it is so effective is that this method will most likely pass SPF, DKIM and DMARC as the senders domain could be 100% legit.

However, this is where the issue lies.  The “Display Name” vs “From Address” are two different things.  And to the untrained eye, most people will just review the “Display Name” as it is shown in the mail and in some cases shown instead of the actual email address.

The “From” header in the mail will show the “Display Name” and then the email address.

“From: Bill Clinton <notbillclienton123c3@gmail.com>”

 In this scenario the user might think that the email is from Bill Clinton and believe the contents. 

Always check the From Email address of a mail before reading it.

Pro tip – setup an exchange rule to check if the Display Name of your directors or employees doesn’t match your domain and block it.

There you have it, you can now become a pro at checking the risk of emails.  At Vendifi we use a number of these checks in our automated vendor onboarding and risk evaluation process.  A good vendor will appreciate that protecting their email is a priority and implement everything from DNSSEC to DMARC.  If you would like to see how Vendifi can help your business perform vendor due diligence, please request an demo.