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

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

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. is a great resource. Try using their SuperTool and select SPF, DKIM, DMARC and enter 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
  • (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, is a Microsoft 365 customer, and ALL email is sent through Microsoft 365. This means they do not use any 3rd party services such as SendGrid or Constant Contacts. If 3rd 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 3rd party service, will return the information needed to append to the SPF record. However, 365 customers can follow this section with ease.


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

  1. Check and use the SuperTool to see if 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.SPF RECORD
  1. Once this is verified, proceed
  2. For simplicity, and to get up and running with as little headache as possible, the TXT record should look like this below

v=spf1 -all

  1. It starts with “v=spf1”, which basically tells the world to apply these settings to all emails
  2. The 2nd part with “include:” tells the world which servers to accept email from
    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, 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
  1. 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:

v=spf1 -all

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 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:

v=spf1 ip4:123.456.789.101 -all

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

Step 2. Implementing DKIM (DomainKeys Identified Mail):

  1. Browse here
  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

DKIM Setting

Record 1:

Type: CNAME or TXT depending on the instructions

Hostname: selector1._domainkey

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

Record 2:

Type: CNAME or TXT depending on the instructions

Hostname: selector2._domainkey

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

  1. After creating the records, switch back to Microsoft 365 and Enable “Sign messages for this domain with DKIM signatures”
  2. 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 “” 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 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;;
  • 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!


Email authentication in Microsoft 365 | Microsoft Learn

*Disclaimer*: Harvard Business Services, Inc. is neither a law firm nor an accounting firm and, even in cases where the author is an attorney, or a tax professional, nothing in this article constitutes legal or tax advice. This article provides general commentary on, and analysis of, the subject addressed. We strongly advise that you consult an attorney or tax professional to receive legal or tax guidance tailored to your specific circumstances. Any action taken or not taken based on this article is at your own risk. If an article cites or provides a link to third-party sources or websites, Harvard Business Services, Inc. is not responsible for and makes no representations regarding such source’s content or accuracy. Opinions expressed in this article do not necessarily reflect those of Harvard Business Services, Inc.

More By Brock Albitz
Leave a Comment
* Required
* Required, will not be published