SPF, DKIM and DMARC for Microsoft 365: a step-by-step setup

Without email authentication, anyone can send a message that claims to come from ceo@yourcompany.com. SPF, DKIM and DMARC let receiving mail systems check that claim. Together they reduce spoofing of your domain, protect your customers and suppliers from impersonation, and improve delivery of your legitimate mail, as large mailbox providers increasingly expect authenticated senders.

Microsoft's overview, email authentication in Microsoft 365, explains how the three work together. This guide is the practical order of work.

Step 1: Inventory everything that sends as your domain

This is the step people skip, and the reason DMARC projects stall. List every system that sends email with your domain in the From address:

• Microsoft 365 (Exchange Online) itself.
• Marketing and newsletter platforms.
• CRM, helpdesk and ticketing systems.
• Billing, invoicing, HR and payroll systems.
• Website contact forms and e-commerce platforms.
• On-premises servers, scanners and line-of-business apps relaying through a connector.

Ask finance, marketing and operations as well as IT. DMARC aggregate reports (step 4) will catch what you miss, which is why you start in monitoring mode.

Step 2: Publish SPF

SPF is a single TXT record at the root of the domain listing who may send. For a domain that sends only through Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Add an include: (or ip4:/ip6:) for each other sender from your inventory, using the value that sender documents. Rules to keep in mind:

• One SPF record per domain. Two TXT records starting with v=spf1 make SPF fail. Merge them.
• Ten DNS lookups maximum. Each include, a, mx and redirect counts, including nested ones. Exceeding the limit causes a permanent error.
• -all vs ~all. Hard fail (-all) tells receivers to reject unlisted senders; soft fail (~all) marks them as suspicious. With DMARC in place, the DMARC policy ultimately decides; Microsoft's SPF guidance discusses the choice.
• Subdomains need their own records if they send mail.

Microsoft's instructions: set up SPF to help prevent spoofing.

Step 3: Enable DKIM signing

DKIM adds a cryptographic signature to each outgoing message. Microsoft 365 signs with the tenant's onmicrosoft.com domain by default; to sign with your own domain (which DMARC alignment needs), enable DKIM per custom domain:

1. In the Microsoft Defender portal, go to Email & collaboration › Policies & rules › Threat policies › Email authentication settings › DKIM.

2. Select your domain. The portal shows two CNAME records (selector1._domainkey and selector2._domainkey) to publish in your DNS.

3. Create both CNAME records exactly as shown. The target format has changed over time, so always copy the values from the portal or from Get-DkimSigningConfig rather than from an old guide.

4. After DNS propagates, toggle Sign messages for this domain with DKIM signatures to enabled.

Repeat for every custom domain, and enable DKIM in each third-party sending service using its own instructions. Details: set up DKIM to sign mail from your Microsoft 365 domain.

Step 4: Publish DMARC in monitoring mode

DMARC is a TXT record at _dmarc.yourcompany.com. It passes when SPF or DKIM passes and the passing domain aligns with the From address. Start with a policy of none so nothing changes for delivery while you collect reports:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com

• rua is where aggregate reports go. They're XML files; a DMARC reporting service or a parser makes them readable.
• Use a dedicated mailbox or a reporting service address, not a person's inbox.

Microsoft's guide: set up DMARC to validate the From address domain.

Step 5: Read the reports and move to enforcement

For two to four weeks, review the aggregate reports:

1. Legitimate senders failing: add them to SPF or, better, enable DKIM signing with your domain in that service.
2. Unknown senders passing: investigate. Something may be sending on your behalf without anyone knowing.
3. Unknown senders failing: usually spoofing. This is what enforcement will stop.

When legitimate mail consistently passes, tighten the policy in stages:

Give each stage a week or two and keep reading the reports. Reject is the goal; quarantine is a reasonable resting point if a business sender can't yet authenticate properly.

Don't forget domains that don't send email

Attackers spoof parked and unused domains precisely because nobody monitors them. For every domain you own that never sends mail, publish:

TXT  @        v=spf1 -all
        TXT  _dmarc   v=DMARC1; p=reject;

What about inbound mail?

SPF, DKIM and DMARC on your domain protect others from mail pretending to be you. Protection for mail arriving at your users comes from Exchange Online Protection and, if licensed, Defender for Office 365. Microsoft 365 evaluates the sender's authentication as part of anti-spoofing. Applying the Standard or Strict preset security policies is the simplest way to get consistent inbound protection.

Checklist

• Every sending service is inventoried, with an owner.
• Each domain has exactly one SPF record, within the ten-lookup limit.
• DKIM is enabled in Microsoft 365 for every custom domain, and in each third-party sender.
• DMARC is published with aggregate reporting to a monitored address.
• DMARC is at quarantine or reject, or has a dated plan to get there.
• Non-sending domains publish v=spf1 -all and p=reject.

Troubleshooting common failures

• SPF "permerror": usually more than ten DNS lookups or two SPF records. Remove senders you no longer use, and prefer DKIM for third-party services instead of adding more includes.
• DKIM passes but DMARC fails: the service signs with its own domain, not yours, so there's no alignment. Configure the service to sign with your domain (it will give you CNAME or TXT records to publish).
• Forwarded mail failing SPF: expected, because the forwarding server isn't in your SPF record. DKIM survives forwarding when the message isn't modified, which is another reason to enable it everywhere.
• Mailing lists changing messages: lists that add footers or change subjects can break DKIM. Many list services rewrite the From address to handle DMARC; check yours before moving to reject.
• New DKIM records not detected: DNS changes can take time to propagate. Check the records with a DNS lookup tool before enabling signing again.

Keeping it working

Email authentication isn't a one-time project. Every new marketing tool, billing system or website plugin that sends as your domain needs to be added before it goes live, or its mail will be quarantined or rejected once DMARC is enforcing. Make "does it send email as us?" part of your purchasing checklist, keep reading aggregate reports monthly, and rotate DKIM keys on the schedule your providers recommend.

How M365Assessments helps

The early-access Exchange & Security module reads the tenant's domains and checks SPF, DKIM and DMARC for each one, alongside Exchange Online settings such as external forwarding and suspicious inbox rules. Like the rest of the assessment, it's read-only; the security page lists exactly what it requests. See modules explained.