Avoiding Spam: How We Implement Deliverability and Baseline Security Layers Within E-mail

Info Sec / Tips

Avoiding Spam: How We Implement Deliverability and Baseline Security Layers Within E-mail

It’s common for businesses to believe that their e-mail environment is configured perfectly, but in reality, although all may appear healthy, a lot of the time they haven’t implemented best practice policies to ensure the deliverability of their emails.

Below we discuss the three main e-mail authentication standards and how we work within our customers’ infrastructure to implement these. If you’re a large enterprise or have an in-house team, it’s likely you already have these implemented – but you’d also be surprised at the types of organisations we’ve come across that don’t adopt all three basic standards. The end goal is simple, we want the e-mails we send to land in the recipient’s inbox without being flagged as spam, junk or being held by a security layer.

Using SPF & DMARC to ensure e-mail deliverability

SPF records are domain TXT DNS entries that are used to identify valid ‘All senders’ who are permitted to send mail from or on behalf of your domain, including third-party systems such as marketing tools, CRM applications etc. When using SPF records, the receiving domain checks the ‘Mail from’ address within the email to validate that it has been sent from an accepted source.

A couple of examples of correct SPF records are shown below. This includes a single SPF record with no additional third-party systems and a record for multiple systems.

Single email server:

v=spf1 include:YourSendingEmailServer.com -all

Example including Microsoft 365 email server:

v=spf1 include:spf.protection.outlook.com -all

Third-party e-mail servers can be provided in either an e-mail server or public IP address format, both examples shown below:

v=spf1 include:YourSendingEmailServer.com include:YourSendingApplicationIP -all
v=spf1 include:YourSendingEmailServer.com include:YourSendingApplicationServer.com -all

When using DMARC as well as SPF, the receiving domain also checks the ‘From’ address as well as the ‘Mail from’ address to authenticate the mail. If these fails to match then the email will not be authenticated and an admin can be notified.

Example of DMARC record shown below:

Host:

_dmarc

Value:

v=DMARC1; p=none; rua=mailto: [email protected]; ruf=mailto:[email protected] ri=84600

‘Mail from’ = the actual e-mail address the sender is using i.e. [email protected]

‘From’ = displayed email address i.e. [email protected]

Using DKIM in conjunction, for best security practice

You should use DKIM in addition to SPF and DMARC to protect your domain from being spoofed. DKIM does this by adding a digital signature to your outbound e-mail header which can help the receiving email server identify if the email is legitimate or not.

For DKIM there are two domain CNAME DNS entries to be added, the examples below are values when using Microsoft 365. Both will need to include the following: the sector, your sending domain and your onmicrosoft.com domain.

Host:

selector1._domainkey

Value:

selector1-domain-com._domainkey.domain.onmicrosoft.com

Host:

selector2._domainkey

Value:

selector2-domain-com._domainkey.domain.onmicrosoft.com

Additional note: within the sending domain value, all ‘.’ must be replaced with ‘-’.

It’s amazing how implementing such simple measures can make a huge difference to the deliverability of your e-mails.