Can People Trust Your Emails? Are You Protected? A Guide on How to Implement DMARC DNS Records

Trust.

It’s central to every commercial relationship, whether that’s B2B, B2C or even employee to employee. Communication is even more crucial, with email being integral to a business’ communications. Did you know, there are more than 5 billion email accounts worldwide?

Can you trust your emails?

95% of all hacking attacks and data breaches involve email. It’s not just employees that you put at risk by not implementing anti-spoofing methods; imagine if your customers or clients received an email spoofed so that it looked like you sent it? Do you think they would know it wasn’t from you?

Just taking into consideration your employees, there’s an almost endless number of premises that attackers can use to try and socially engineer them; one of the most popular is fear, with blackmail emails on the rise. Blackmail emails usually relate to something you wouldn’t want to be made public, whether it’s commercial data, customer data, or things of a very personal nature.

You may have received many of these emails from random addresses, and likely dismiss them at a glance, but when you get one that has been sent from your own work address, or at least looks as though it has, you take a second look. When the content of the email claims to have compromised your account, and your inbox confirms it was sent from your own address, it’s easy to get sucked into believing someone has really compromised it.

Can you prevent it?

The recent trend of these ‘scareware’ emails is not exploiting anything new, they’re doing something that’s been possible for a long time, but it’s also something that most organisations are unaware of. In short, anyone can send an email ‘from’ a domain, and by default, there is no verification of the ‘from domain’ sent with the email by the recipients SMTP server. This is exactly how attackers trick people into believing they have had their accounts compromised. They simply edit the ‘from domain’ to [email protected] and send an email to their target user. That’s it. It’s as simple as that. As a result, you get an email in your inbox from your own account.

If no DMARC DNS record has been configured, the email then goes straight to the domain’s email service provider, which does its standard validation and processing. This is unlikely to pick up spoofed emails if you don’t have the appropriate protections in place.

The diagram above from dmarc.org shows the flow an email goes through from sender to receiver if a DMARC record has been configured.

So how do you implement DMARC for a domain, to ensure you’re protected?

Implementing DMARC is a straightforward process, once you know the precautionary steps to take. There are 3 DNS TXT records that you need to add, in order to protect your domain. These are:

SPF (Sender Protection Framework)

• This creates a whitelist of mail servers that can send emails for your domain
• An email will only pass the SPF check if it originated from a server that is on the whitelist
• The exact info that goes into this record is dependent upon your email service provider
• If Google is your email service provider then you can use the following: v=spf1 include:_spf.google.com ~all

DKIM (Domain Keys Identified Mail)

• When DKIM is set up, a DKIM header is sent with an email which contains a cryptographic key
• The cryptographic key is used to verify the integrity of the email's content to prevent it being tampered with whilst it is in transit
• Multiple DKIM records can be added to a domain to accommodate different signatures for multiple email service providers
• The exact info that goes into this record is dependent upon your email service provider
• If Google is your email service provider then you can follow this guide https://support.google.com/a/answer/174124?hl=en
• v=DKIM1; k=rsa; p=

DMARC (Domain-based Message Authentication, Reporting and Conformance)

• This defines how emails that fail SPF and DKIM checks are handled
• A phased approach to implementing DMARC is recommended to stop any unwanted disruption.

Phasing in DMARC protection

At Razor, we began with just reporting emails that fail DMARC checks, then quarantine them (emails marked as quarantined will still be sent, but will reside in the recipient’s spam folder) and finally ‘block’ rejects all emails that fail DMARC checks completely.

There are additional options if a more specific configuration is required. This includes limiting the DMARC checks to a certain percentage of emails, for gradual implementation, or for receiving forensic reports that allow you to identify legitimate emails being flagged.

Below shows the format for the DMARC records as per the phases that we have utilised at Razor:

Phase 1: v=DMARC1; p=none; rua=mailto:[Your Support Email Address]

Phase 2: v=DMARC1; p=quarantine; rua=mailto:[Your Support Email Address]

Phase 3: v=DMARC1; p=block; rua=mailto:[Your Support Email Address]

Remember, small changes can make a big difference. Whilst DMARC records may not stop 100% of spoofed emails, correctly implementing them reduces the chance of a spoofed email landing in the inbox of people who are most valuable to your business.

For further information on how you can implement DMARC protocols, please feel free to contact us to find out more.