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

Part 2: Implementing SPF, DKIM, and DMARC to Increase Email Deliverability.

Can I set up DNS Records by myself?

Yes! Although reading about this on the internet is overwhelming and confusing, if this guide is followed, there shouldn’t be any problem setting the DNS records up to work with Microsoft 365. With a little understanding, you can handle this! If the business has an IT department, this is something they should handle. If not, give it a try, changes can always be undone!

What if I mess something up?

A fair warning: it is possible to mess things up and email can stop working, but it’s ok. Just undo the settings, delete the records created, and email will flow again. Call a local trusted tech person if it comes to that because these are needed to ensure email deliverability.

There are also tools that can check these to make sure the syntax is right. Mxtoolbox.com is a great resource. Try using their SuperTool and select SPF, DKIM, DMARC and enter yourdomain.com to view the records and suggestions. I would suggest using that tool before implementing SPF, DKIM, and DMARC, just to make sure these things aren’t implemented already. The tool will even show where DNS is hosted, so there isn’t confusion there. Don’t bother checking DKIM at this point, that will get cleared up later.

What do I need to start setting up DNS Records?

• Registrar or DNS service credentials
• Microsoft 365 Admin Credentials
• Yourdomain.com (Replace references in this document with the business domain)

Step 1. Implementing SPF (Sender Policy Framework):

Preface: Depending on the email service used, the values will be defined differently. In this example, yourdomain.com is a Microsoft 365 customer, and ALL email is sent through Microsoft 365. This means they do not use any 3^rd party services such as SendGrid or Constant Contacts. If 3^rd parties are used, the SPF requirements can be searched online. For example, “SPF record requirements for Microsoft 365” or “SPF record requirements for Gmail”, or a 3^rd party service, will return the information needed to append to the SPF record. However, 365 customers can follow this section with ease.

Note: THERE CAN ONLY BE 1 SPF RECORD!

Multiple SPF records will disrupt email, make sure there’s only 1 TXT record that starts with “v=spf”

1. Check mxtoolbox.com and use the SuperTool to see if yourdomain.com already has a SPF record. This is what it will look like if a SPF record exists and is set up correctly. Also, note at the bottom it mentions who the DNS Hosting provider is for this test domain.

2. Once this is verified, proceed
3. For simplicity, and to get up and running with as little headache as possible, the TXT record should look like this below

1. It starts with “v=spf1”, which basically tells the world to apply these settings to all emails
2. The 2^nd part with “include:” tells the world which servers to accept email from yourdomain.com
   1. In our example, we redirect that over to Microsoft’s SPF record and this instructs the world to just use Microsoft’s list of servers, so we don’t have to maintain a list of them ourselves
3. Finally, the “-all” means to hard fail and REJECT all emails that do not originate from Microsoft 365’s servers
   1. There is an option to do a soft fail and quarantine emails instead, that is ~all
   2. As long as it’s 100% certain no one else is sending as yourdomain.com, then use the hard fail. Soft fail is typically used when organizations use a lot of sending partners and have a lot of moving parts and they don’t want any emails to get rejected by mistake
   3. If SPF is enabled and some emails are still being rejected, change this to ~all until it is figured out which services are being used that need to be added to the SPF record

4. At the registrar/DNS server, create a TXT record (or edit the existing SPF) to match:

• Type: TXT
• Hostname: @
• TTL (Time to live): Default Setting
• Value:

It’s that easy for Microsoft 365 customers!

Now, let’s say there’s a local server at the office which has the ability to send email as yourdomain.com and it doesn’t support relaying off of Microsoft 365 directly. The office IP address needs to be added to this record or else any emails that are sent from that SMTP server will be rejected. If there’s a server like this, a static IP address is also needed for the business, at which point the static IP address can be added to the SPF record as seen in red below:

Congratulations! At this point, the world knows who is authorized to send email as yourdomain.com and they will not accept email from anyone else trying to spoof yourdomain.com.

Step 2. Implementing DKIM (DomainKeys Identified Mail):

1. Browse here https://security.microsoft.com/authentication
2. On the Email authentication settings page, select the DKIM tab
3. On the DKIM tab, select the custom domain to configure
   1. Note, if this is already enabled do not proceed
   2. Select Create DKIM keyNote, do not click “Rotate DKIM Keys”

Follow the instructions presented to create the 2 CNAME records needed

1. Use a different browser window and go to the Registrar/DNS server
2. If TTL is not defined, use the default value

Record 1:

Type: CNAME or TXT depending on the instructions

Hostname: selector1._domainkey

Value (use the given values, not this example):

selector1-quick-inc-com._domainkey.quick-inc.com

Record 2:

Type: CNAME or TXT depending on the instructions

Hostname: selector2._domainkey

Value (use the given values, not this example):

Selector2-quick-inc-com._domainkey.quick-inc.com

7. After creating the records, switch back to Microsoft 365 and Enable “Sign messages for this domain with DKIM signatures”
8. It will now verify and validate the records just published. If it fails, the registrar may need more time to publish the records, try again in 30 minutes - 1 hour

Note: The MxToolbox verification tool is tricky with DKIM, but if “yourdomain.com:selector1” is entered, hit DKIM Lookup and it will pass. If Microsoft 365 already verified it as working, this step is unnecessary.

Congratulations! DKIM is now enabled!

Step 3. Implementing DMARC (Domain-based Message Authentication, Reporting and Conformance):

Prerequisites: Before beginning, create a shared mailbox called DMARC@yourdomain.com so it can receive reports of DMARC reports and failures. Then grant yourself full access to this mailbox so the reports can be viewed as needed.

Add this record to the registrar/DNS to reject email that fails the checks:

• Type: TXT
• Hostname (Make sure to include the “_” ): _dmarc
• Value: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com
• Specify “reject”, “quarantine”, or “none” depending on what you want the DMARC policy to do when a recipient finds an email failed the security checks
  • Rua is the address that will receive aggregate DMARC reports.
  • Ruf is the address that will receive forensic DMARC reports.

You won’t typically need to review these once it’s all up and running successfully, but this is why I mentioned you should have a shared mailbox created, as you may want to use that shared mailbox in these values.

Congratulations! DMARC is now enabled! You are finished!

References:

Email authentication in Microsoft 365 | Microsoft Learn