Article: Email Security Explained for 2024 and beyond

Simple Glossary to know:

Domain: e.g. abc.com

Sending server: Where the email originates from

Recipient Server: The server which the email is sent to

DNS Record: A publicly available record on any given domain.

  • Can include where to send email (MX record), which IP to go for the www address (website) (e.g. A record) and for email security the details needed for SPF, DKIM and DMARC checks.

Phishing Email: Phishing emails are designed to get you to respond with details such as bank account details or credit card details that criminals can use to siphon funds and/or scam you into paying them or handing over confidential info.

SPF: Sender Policy Framework

DKIM: DomainKeys Identified Mail

DMARC: Domain-based Message Authentication, Reporting & Conformance

 

Emails as postcards:

Sending an email could be compared to sending a postcard with all your potentially confidential data shown on the outside along with the addressee and the sender. To get to its destination that postcard must pass through various post collection centres (routing servers) and during this process if someone manages to intercept that simple email with no security setup that someone could read everything in your postcard or email. They could even write another postcard with slightly different information and send it on to the same person. Sending an email without any email security can therefore be seen as it truly is; remarkably insecure!

SPF Email Security:

Back in the early days of the internet and email the biggest problem stemmed from spammers “spoofing” who the email was sent from and fooling the recipient into thinking it was from a different legitimate sender.

Scammers utilised this process to get false invoices paid and/or gain information in return they would otherwise not be trusted for. In between 2000 and 2004 SPF (“Sender Policy Framework” originally called “Sender Permitted From”) security was invented with collaboration. An SPF record is a simple line of text that is added to the sending domain’s publicly available DNS records so that anyone receiving the email can check to see if the sender mentioned in the email itself is “on the list”  as an authorised sender. If your name’s not on the list you’re not coming in!

For Example: A company called Universal Exports (yes I’m a Bond fan) with a domain name UniversalExports.com and an email server that only sends from one IP address which is 111.111.111.111 the SPF record would be “V=spf1  IP4:111.111.111.111 -all”.

The -all bit at the end is super important as anything other than this basically makes the whole SPF check process useless (more on this later on).

[TLDNR (If the mail delivery (MX) record was also the same IP that the email is sent from then the SPF could be : “V=spf1 mx -all” similarly if the A record present on the domain is the correct IP for the mail server then it could be “V=SPF1 a -all”]

Scenario 1

Legitimate Email is sent by Joe.Bloggs@UniversalExports.com via the company email server from IP address 111.111.111.111

It gets to the recipient server which sees the email is from @UniversalExports.com domain

The recipient server looks up the DNS records for UniversalExports.com and finds the SPF record that shows 111.111.111.111 is an authorised sending IP address.

Recipient Server records this as a PASS and allows the email to be delivered.

The recipient gets the email. Yay! All is well!

 

Scenario 2

Spoofing criminal sends an email purporting to be from Joe.Bloggs@UniversalExports.com from his own IP address 666.666.666.666

It gets to the recipient server which sees the email is from @UniversalExports.com

The recipient server looks up the DNS records for UniversalExports.com and finds the SPF record that shows 666.666.666.666 is NOT an authorised sending IP address.

Recipient Server records this as a FAIL, the -ALL bit in the record tells the recipient server to HARD FAIL and the email should not be delivered. Crucially no response is sent back as this would tell the spoofing criminal he has failed on this attempt ergo encouraging them to try again.

 

Whilst a great idea unfortunately SPF was not historically properly and widely implemented with many IT guys scared of failed email delivery and so tagging the record with a “allow delivery even if fail” marker. Putting  a “~all” at the end of an SPF in place of “-all” was and sometimes still is widely used and this essentially makes SPF protection redundant as a spammer can still send a message pretending to be from UniversalExports.com and the when recipient checks the SPF rule and the email fails the check the email is still allowed through. You check your own domain’s status in this regard by typing in your own domain on mxtoolbox.com under their SPF record lookup  HERE. If your record ends in anything other than “-all” your SPF check is not enforced! Additionally, (clears throat) some IT guys get even basic SPF implementation wrong and ignore the rules that are out there to abide by causing SPF errors when performing this check. So they switch it off or leave SPF on soft fail (“~all”) or even “-?” Ignore all fails. Yuck. One technical note worth pointing out is there is a limit on SPF records in that you can only have a limit of 10 DNS lookups. If you use Microsoft’s SPF record, you use mailchimp for bulk sending and your finance and/HR system has its own email tie in then you can quite easily end up going over this 10 address limit.

 

DKIM:

Whilst SPF security addresses who the actual sender is what it does not protect against  content manipulation. If a nefarious hacker managed to gain access to an email mid-transit (without going into the complicated ways this could happen) they could in theory change the content of the email (lets say bank details) and then carry on sending the email potentially with all the SPF security intact. Here enters DKIM security.

DKIM put simply is an additional check that receiving servers can lookup (if present) to check that the email content is the same as when it was sent by the authorised server.

If a domain (like UniversalExports.com) has a DKIM record on its domain records then the recipient server checks this record and compares the encryption with the cryptographic information included in the message (this is hidden within the email header). Assuming the details of the message and the encryption corresponds to the public encryption then the email hasn’t been changed in transit and can be delivered to the intended email recipient.

A DKIM pass therefore not only confirms that the email hasn’t changed from the sending server but also that the specific sender is authorised.

N.B. If you could only aim for one security type SPF or DKIM, DKIM would always be the better option.

N.N.B. Although there is encryption involved DKIM security does not result in the actual email itself being sent encrypted. In other words DKIM secures against manipulation post sending and better identifies the authorised sending server but is not full email encryption.

 

DMARC:

In modern day organisations there are frequently more than one email system in use and therefore due to the nature of checks performed by recipient servers if SPF and DKIM are configured on a domain there has to be another record which can indicate what to do if either of these checks fail. Let’s say you have the main office email setup with DKIM however there is another mailout service that only supports SPF. Here is where DMARC policy comes in.

DMARC (also present on the sending domain’s DNS records) checks for alignment with SPF and/or DKIM where present and checks the advertised ‘from’ field and then quite simply tells any recipient server what to do if the DMARC check fails. It can be set to quarantine, reject or none (disabled). Reporting post delivery is also a useful function for IT administrators to monitor both email delivery successes and failures.

There are four possible DMARC results (well there are more but for the layman)

  1. SPF fails but DKIM passes and aligns with “from” field
  2. SPF passes and aligns but DKIM fails
  3. both pass (and align)
  4. both fail

 

a and b and c should cause DMARC to pass and allow the email to be delivered as long as the SPF and DKIM pass in a or b are aligned with the “from” field in the message. If DMARC fails then the record tells the recipient server whether to reject the email, quarantine the email or allow it through anyway. Obviously the last setting should only be present in a testing/proving environment as this would let all failures through!

DMARC also allows for “identity alignment” which addresses the accuracy of the “from” field given to recipients and not checked by either SPF or DKIM. IT administrators can also monitor delivery of their emails and address any issues that arise and in doing so raises the confidence level that other servers have in your sent emails. Ultimately having properly configured SPF, DKIM and DMARC will lead to higher security and fewer of your emails being marked as spam (as long as their content isn’t spam worthy).

** With both SPF and DKIM active, organisations should absolutely (some say MUST) have DMARC else many emails that pass one of the SPF/DKIM checks but not the other may not be delivered. This leads to confused parties thinking they are being spoofed or intercepted when really they are not.

In short with SPF and DKIM but no DMARC policy, if an email fails either SPF or DKIM the email could be blocked. In reality (without going in to too much detail for this article) if either DKIM or SPF passes and aligns the email should be allowed. Ideally you are after full alignment of DMARC with both SPF and DKIM passing and aligning. DMARC ties both SPF and DKIM securities in a neat bow together and is the big difference between a  secure email security system that is practical and one that is incorrectly blocking many safe emails or worse allowing other 3rd parties to tarnish your brand by sending rogue emails that purport to be from your organisation.

Should another company start receiving spam that appears to be legitimately from your organisation and you don’t have email security configured correctly their IT guys might ask why your IT guys are idiots and block all your email until it’s corrected.

Additional Enterprise Email Security

BIMI:

BIMI is a recent addition to the email security world and is a logo based addition to the above domain related checks. Essentially BIMI requires and builds on DMARC and includes your company verified logo from a registered trademark in the email linked back to a BIMI record posted on the authorised sending domain. The result is an easy to spot verified logo on compatible email platforms such as Google, Yahoo etc that allows a person to easily distinguish between emails from their bank that always come with the correct bank logo from spam emails that purport to be from the bank but don’t have the verified logo. This is all designed for brand recognition and hopefully making it easier to spot phishing emails.

(Phishing emails are designed to get you to respond with details such as bank account details or credit card details that criminals can use to siphon funds or scam you)

 

Full Email Encryption:

Some email security platforms (such as the one HDIT implement) also employ the ability to encrypt emails from source and allow only the recipient to separately access said encrypted email post delivery. This is the ultimate step in email security and is currently underused mainly due to the lack of understanding passed from IT administrators to staff. For more information on this please contact the HDIT helpdesk technician who can expand on this option for you.

 

Credit card detail recognition and blanking:

A simple way to protect both customers and companies alike. If you have a professional spam control platform that both delivers and receives all your email it is possible to set up processes that blank out any credit card numbers that may be sent in an email. Credit card details should never be given out or shared via email and this automatic process can protect employees and companies alike from inadvertently handing out details they shouldn’t in a rush.

Simple Procedures to prevent fraud:

Common sense and logic can solve many scams before they even rise.

Lets say you need to transfer ten thousand pounds to a supplier for the first time and they’ve given you the invoice with the bank details. Don’t send £10,000! Send £10 and then call and ask if they received it. If they say yes then send the remaining £9990.

Do you have a regular supplier who has informed you via email that they have changed bank details? Call them!

Do you have a member of staff who say they want their pay going somewhere else? Why not wait and talk to them in person to confirm.

If more companies followed this logic then fraudsters would have a very difficult time trying to fleece money from organisations via fake emails and invoices etc.

 

Conclusion:

A combination of SPF, DKIM and DMARC security drastically mitigates impersonation, spoofing, and improves deliverability confidence for your emails for your domain(s).

 

The more companies employ fully implemented SPF,DKIM and DMARC the fewer spam and phishing attacks we would all get. Whilst Enterprise level AI backed inbound/outbound email security can be as much as £10-15 per member of staff per month the cost of implementing SPF, DKIM and DMARC security doesn’t have to cost very much at all. Assuming your email system is compatible with all of these any good IT company should be capable of enabling these processes easily.

That being said SPF, DKIM and DMARC security on its own does not protect your users from receiving unwanted emails and so one must carefully consider that and advanced email antispam, antivirus, antifraud platform be additionally implemented alongside. One successful fraudulent scam can equate to 100s of years of this protection at this level and therefore when seen in these terms is highly worth it especially when your organisation deals with any amounts of money that your business cannot afford to lose.

For more details please contact a member of the HDIT team.