A Step by Step Guide to DMARC, SPF, DKIM Configuration of Office 365 and Domain

Feature Image

Sep 20 2023

Abhay Nawathey
by Abhay Nawathey

When utilizing a third-party application for email transmission, there may be no necessity to set up the SPF record for that specific app. The reason behind this is that the third-party app relies on your SMTP server for sending emails. As long as your SMTP server is properly configured and your IP addresses are incorporated within your SPF record, any emails dispatched through the third-party app will be deemed legitimate. 

For instance, consider the case where your domain is example.com, and you employ Clodura.AI as your email platform. Clodura.AI operates by utilizing your SMTP server to transmit emails. Consequently, it's unnecessary to configure an SPF record for Clodura.AI itself. Instead, the focus should be on configuring your own SPF record, ensuring that it encompasses the relevant IP addresses. 

Think of Clodura.AI in a similar vein as common email clients such as Outlook or webmail. These clients draft and deliver emails to your server. Consequently, there is no requirement for a separate SPF record for Clodura.AI in this context. The integrity of the emails sent through Clodura.AI is established through the proper configuration of your SMTP server and the inclusion of relevant IP addresses in your domain's SPF record. 

Let's take a closer look at A Step-by-Step Guide for Configuring DMARC in Office 365. 

Set up DMARC for inbound mail 

You don't need to take any action to establish DMARC for incoming emails in Microsoft 365. Everything is handled automatically. If you're curious about what occurs with emails that don't pass our DMARC verification, you can find out more by - How Microsoft 365 handles inbound email that fails DMARC. 

Set up DMARC for inbound mail

Set up DMARC for outbound mail from Microsoft 365 

If you use Microsoft 365 but you aren't using a custom domain (you use onmicrosoft.com), SPF is already set up for you and Microsoft 365 automatically generates a DKIM signature for your outgoing mail (for more information about this signature, see Default behavior for DKIM and Microsoft 365). To set up DMARC for your organization, you need to Form the DMARC TXT record for the onmicrosoft.com domain and publish it to DNS via  

Office 365 Admin Center > Settings > Domains > click on onmicrosoft.com domain > Add record. 

For those with a custom domain or employing on-premises Exchange servers in conjunction with Microsoft 365, configuring DMARC for outbound emails requires manual steps. The process of setting up DMARC for your custom domain encompasses the following actions: 

Step 1: Identify valid sources of mail for your domain 

If you've previously established SPF, you've already completed a similar task. However, there are additional factors to bear in mind when dealing with DMARC. To determine the origins of emails associated with your domain, it's important to address these two key questions: 

  • What IP addresses send messages from my domain? 
  • For mail sent from third parties on my behalf, will the 5321.MailFrom and 5322.From domains match? 
Set up DMARC for outbound mail from Microsoft 365

Step 2: Set up SPF for your domain 

Now that you have a list of all your valid senders you can follow the steps to Set up SPF to help prevent spoofing. 

For example, assuming contoso.com sends mail from Exchange Online, an on-premises Exchange server whose IP address is, and a web application whose IP address is, the SPF TXT record would look like this: 

contoso.com  IN  TXT  " v=spf1 ip4: ip4: include:spf.protection.outlook.com -all" 

As a best practice, ensure that your SPF TXT record takes into account third-party senders. 

Step 3: Set up DKIM for your custom domain 

After configuring SPF, the next step is to establish DKIM. DKIM enables the inclusion of a digital signature within the email message header. If you opt not to configure DKIM and instead permit Microsoft 365 to employ the default DKIM settings for your domain, it could lead to potential DMARC failures. This issue arises because the default DKIM configuration employs your original onmicrosoft.com domain as the 5321.MailFrom address, rather than your customized domain. This creates a disparity between the 5321.MailFrom and 5322.From addresses in all emails originating from your domain. 

In cases where you have third-party senders responsible for sending emails on your behalf, and these emails exhibit a mismatch between the 5321.MailFrom and 5322.From addresses, it can lead to DMARC failures for those specific emails. To prevent this, it's essential to configure DKIM specifically for your domain in collaboration with that third-party sender. This not only enables Microsoft 365 to authenticate emails from this third-party service but also allows other email services like Yahoo, Gmail, and Comcast to verify these emails as if they were sent directly from you. 

This practice is advantageous as it helps build trust in your domain among recipients, regardless of their email provider. Simultaneously, it ensures that Microsoft 365 doesn't flag these messages as spam due to spoofing because they successfully pass authentication checks for your domain. 

For instructions on setting up DKIM for your domain, including how to set up DKIM for third-party senders so they can spoof your domain, see Use DKIM to validate outbound email sent from your custom domain. 

Set up DKIM for your custom domain

Step 4: Form the DMARC TXT record for your domain 

Although there are other syntax options that aren't mentioned here, these are the most commonly used options for Microsoft 365. Form the DMARC TXT record for your domain in the format: 

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; p=policy; pct=100" 


  • domain is the domain you want to protect. By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as housewares.contoso.com or plumbing.contoso.com. 
  • TTL should always be the equivalent of one hour. The unit used for TTL, either hours (1 hour), minutes (60 minutes), or seconds (3600 seconds), will vary depending on the registrar for your domain. 
  • pct=100 indicates that this rule should be used for 100% of email. 
  • policy specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to none, quarantine, or reject. 
  • For information about which options to use, become familiar with the concepts in Best practices for implementing DMARC in Microsoft 365.



Once you've formed your record, you need to update the record at your domain registrar. 


Q. What is DMARC, SPF, and DKIM? 

DMARC, SPF, and DKIM are email authentication protocols that help protect against email spoofing and phishing attacks.

Q. Why is DMARC important for Office 365 and domain security? 

DMARC enhances email security by preventing unauthorized use of your domain for phishing and spoofing.

Q. How do I configure SPF for Office 365 and my domain? 

Configure SPF records to specify which mail servers are authorized to send emails on behalf of your domain.

Q. What is DKIM, and how do I set it up for Office 365? 

DKIM adds a digital signature to your emails; set it up in Office 365 to verify message authenticity. 

Q. What are the key steps for implementing DMARC for Office 365 and my domain? 

Implement DMARC by publishing a DMARC record, monitoring reports, and gradually enforcing email authentication policies. 

Abhay Nawathey
by Abhay Nawathey

Abhay Nawathey is Co-founder and Chief Technology Officer of Clodura.AI.
He has more than 22 years of experience in technology creation and software development, having worked in various leadership roles for software companies.