Email Deliverability: A Critical Function of Business (Part 1)

We all hate it when an important email is caught in spam or quarantine. Luckily, with proper email security, customers will rarely have to check spam for important emails. The focus of this blog post will be on SPF, DKIM, and DMARC DNS records and how to set them up to work with Microsoft 365. Publishing these records will improve the transactional email deliverability enormously by reducing the Spam Confidence Level (SCL). There are many other things that also impact email deliverability, but these are the foundational practices that everyone should have.

A Warning:

Be careful who is given registrar access! Giving access to someone unknown could lead to potential domain theft. Ensure communication with the registrar’s support or DNS service provider to create “delegate access” for 3rd parties needing to alter records. Never provide full domain access as it could lead to domain transfer or theft. This is a new scamming technique, so exercise caution and choose reputable companies for outside assistance. Also, ensure Multi-Factor Authentication (MFA) is enabled on registrar accounts!

What is SPF, DKIM, and DMARC?

These are DNS (Domain Name System) records, a couple lines of text published to the internet that specifically help secure email. The end goal of creating these records is to publish who is authorized to send email as yourdomain.com to the world. Examples of this could be Microsoft 365, SendGrid, Constant Contacts, or a local server in the office.

DNS Records are typically held at the registrar where the business domain was purchased, such as GoDaddy, NameCheap, Network Solutions, etc. However, it can also be a DNS service such as AWS Route 53 or Cloudflare. The changes below will need to be made with the current DNS provider.

1. SPF - Sender Policy Framework is a simple record that can be created to tell the world which servers are allowed to send from the domain. This prevents spammers from ‘spoofing’ the domain and sending email as yourdomain.com. When the recipient’s server receives email from yourdomain.com, it checks the public DNS records and verifies the server that sent the email is authorized to do so. There can only be 1 SPF record, make sure there aren’t extras added!

2. DKIM – “DomainKeys Identified Mail” is a text record placed on the public DNS server that the recipient server uses to authenticate the email.

DKIM includes a security signature that is applied to each email sent from the authorized email server. The email service will provide a DKIM authentication key to add to DNS, which is then published on the public DNS server and used by the receiving email server to authenticate and verify the email was not altered by anyone during transit. The security signature is unknown, only the sending server has the correct key.

Imagine a padlock being placed on every email, and the key published to the DNS server is the mechanism that unlocks that email. That is sort of what’s happening here (in a very over simplified way). If the key doesn’t match the lock, then we know there’s an integrity problem.

Each email provider will have their own DKIM instructions to follow. In our example in Part 2, I am demonstrating Microsoft 365’s method. Furthermore, each 3^rd party sending company will have their own DKIM records to publish; it’s ok to have more than 1 DKIM record.

3. DMARC –

Think of DMARC (Domain-based Message Authentication, Reporting and Conformance) as the overseer of SPF and DKIM, further validating both records together in a way that neither SPF nor DKIM can do by themselves. The DMARC policy tells the world what to do if the checks fail. It can either instruct the recipient server to reject, quarantine, or do nothing special with the emails that fail the DMARC check.

Summary: Now that we have covered what these Domain Name Systems are and why they’re needed, read Part 2 to get pointed in the right direction on how to set these up.