Every Day roughly 350 billion emails are send globally, which equals 44 emails per person on earth each day. Most people don't know that emails by default are sent unencrypted over the wire, leaving them vulnerable to interception as well as person in the middle attacks.

So how do we protect our companies?

For starters we can use three DNS entries - SPF, DKIM and DMARC - to protect our employee inboxes from potentially harmful email messages.

SPF - Sender Policy Framework

The Sender Policy Framework or SPF is the first line of defense, which some email providers now even enforce SPF settings for all the emails that they receive (e.g. gmail). That means if your company does not set SPF records your emails will not be delivered.

SPF in general defines the domains/IPs that are allowed to send emails in the name of your domain and how to handle failures.

SPF Structure

In order to have a functional SPF record you need three things - first up the SPF version. Currently, the version in use is v1 - v=spf1.

The second part is the allowed IP addresses which can be defined as IPv4 (v4=192.168.0.0/16), IPv6 (v6=2001:0db8:85a3:0000:0000:8a2e:0370:7334) or as domains. The domains are typically used when you have third party email providers (e.g. gmail, outlook or similar) and defined via the include keyword (include:_spf.google.com). Keep in mind that each domain/IP needs a separate keyword-IP or keyword-domain combination. Another thing to note is that spf records are bound to the 255 character-limit of DNS txt records.

Lastly, the SPF record should include either a soft- or a hardfail as the last keyword - softfail is indicated by ~all, while hardfails are defined by -all.

Should you want to generate your SPF records with an online tool we recommend - https://mxtoolbox.com/SPFRecordGenerator.aspx

DKIM - DomainKeys Identified Mail

The DomainKeys Identified Mail feature tackles another commonly use-case, used to protect against malicious emails. How would you know if someone tampered with your email between you clicking the send button and the recipient opening the email? Email is unencrypted unless specific measures are taken and that means person in the middle attacks need to be taken into account whenever email is concerned. The DKIM DNS records are essentially a signature-based tamper protection method. Each Email provides the receiver with a verifiable signature that has two functions - 1. make sure the sender address was not spoofed, 2. ensure the email message that was send is exactly the one received. Like SPF records DKIM are DNS txt which means they are also limited to 255 characters - keep that in mind. DKIM settings are specific to your email provider and should be setup with their documentation and technical support if necessary.

DMARC - Domain-based Message Authentication, Reporting & Conformance

Last but not least in order to know what to do with emails that fail either SPF or DKIM the outgoing email server can specify DMARC rules. DMARC records are associated with the _dmarc subdomain that holds the DNS records. First up in such records is the version - currently v1 - v=DMARC1. Followed by one of the 3 different policies that can be set for DMARC - none, quarantine & reject - we recommend setting this to at least quarantine, if no business requirements have the need for other settings, ideally it would be set to reject. This way you can be sure that non-conformat emails are not reaching your email inboxes. The remaining two keywords are rua and ruf, where rua is the email address(es) that will receive aggregated DMARC reports and the email mentioned by ruf receives forensic DMARC reports to identify potential abuse cases.

Our recommended DMARC record would consist of at least v=DMARC1; p=reject; and ideally mentions at least a rua for aggregated reports. A tool for guided DMARC setup is available at https://mxtoolbox.com/DMARCRecordGenerator.aspx .

Should you need assistance with configuring your email security DNS settings we would be delighted to support you, please reach out for more information.