SPF, DKIM and DMARC for Microsoft 365: A Step-by-Step Setup

If your invoices or quotes have started landing in customers' junk folders, or a customer has received a fake email that looked like it came from you, the cause is often the same: your domain is missing the three DNS records that prove your email is genuine. They are called SPF, DKIM and DMARC.

This guide explains what each one does, why the big mailbox providers now insist on them, and how to set all three up for a domain that sends email through Microsoft 365.

Why this became mandatory

Since February 2024, Google and Yahoo have required senders to authenticate their email:

• Gmail: Google's sender guidelines require all senders to set up SPF or DKIM. Bulk senders (around 5,000 or more messages a day to personal Gmail accounts) must have SPF, DKIM and DMARC, with the From domain aligned, plus one-click unsubscribe for marketing mail. Google's sender FAQ says that starting November 2025, Gmail is ramping up enforcement, including temporary and permanent rejections of non-compliant mail.
• Yahoo: Yahoo's sender requirements are similar: SPF or DKIM for everyone, and SPF, DKIM and a DMARC policy of at least p=none for bulk senders.
• Outlook.com (Hotmail, Live, Outlook.com consumer addresses): Microsoft announced that from May 5, 2025, domains sending more than 5,000 messages a day must pass SPF, DKIM and DMARC, with non-compliant mail first routed to Junk and rejection to follow later.

A small office rarely sends 5,000 emails a day from its own mailboxes. But newsletters, invoicing systems and marketing tools often send as your domain, and the providers' filters treat unauthenticated mail with suspicion regardless of volume. Setting up all three records is now simply the baseline.

What each record does

Record	What it answers	Where it lives
SPF	Which servers are allowed to send email for this domain?	TXT record on your domain
DKIM	Was this message really signed by the domain, and unchanged in transit?	Two CNAME records pointing to Microsoft 365 keys
DMARC	What should receivers do if SPF and DKIM fail to match the From address, and where should they send reports?	TXT record at _dmarc.yourdomain

You create all of these at your DNS host (often your domain registrar, or a service like Cloudflare), not inside Microsoft 365. The examples below use contoso.com; replace it with your domain.

Before you start: list everything that sends as your domain

This is the step most people skip, and the reason DMARC later blocks legitimate mail. Make a list of every system that sends email with your domain in the From address:

• Microsoft 365 mailboxes
• Newsletter or marketing platforms
• Invoicing, accounting, CRM and help desk systems
• Website contact forms and online stores
• Copiers and scanners that email scans
• Any old on-premises server or line-of-business app

Each of these will need to be included in SPF, set up to sign with DKIM for your domain, or moved to a subdomain. Microsoft recommends using a subdomain (for example news.contoso.com) for services you do not directly control, so their reputation does not affect your main domain.

Step 1: SPF

If Microsoft 365 is your only sender, your SPF record is a single TXT record on the root of your domain. Microsoft's SPF guide recommends ending it with -all (hard fail):

Type:  TXT
Host:  @
Value: v=spf1 include:spf.protection.outlook.com -all

If other services send for you, add their include: values (from their documentation) to the same record:

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

SPF rules to remember

• Only one SPF record per domain or subdomain. Two records cause SPF to fail with a permanent error.
• SPF allows a maximum of 10 DNS lookups. Each include: uses at least one, and nested includes add more. Too many and SPF fails.
• Do not "flatten" Microsoft's include into IP addresses; Microsoft's sending addresses change.
• For domains you own but never send email from, publish v=spf1 -all.

Step 2: DKIM

DKIM adds a digital signature to every message. Microsoft 365 holds the private keys; you publish two CNAME records that point to the public keys. Microsoft generates the exact values for your tenant, so copy them from the portal rather than typing them from an example.

Using the Microsoft Defender portal

1. Go to security.microsoft.com/authentication (Email & collaboration > Policies & rules > Threat policies > Email authentication settings) and open the DKIM tab.
2. Click the row for your domain to open its details. If DKIM is not enabled yet, the Publish CNAMEs section shows the two records to create.
3. Create both CNAME records at your DNS host.
4. Wait for DNS to update (minutes to a few hours), then return and switch Sign messages for this domain with DKIM signatures to enabled.

The records look like this; the right-hand value is unique to your tenant:

Type: CNAME
Host: selector1._domainkey
Points to: selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

Type: CNAME
Host: selector2._domainkey
Points to: selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

Or with Exchange Online PowerShell

Per Microsoft's DKIM guide, the default key size is 1024-bit and 2048-bit is available. Google recommends 2048-bit keys, so it is worth choosing that when you create the configuration:

Connect-ExchangeOnline

# See current status and the CNAME values to publish
Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# If the domain has no DKIM configuration yet, create one with 2048-bit keys
New-DkimSigningConfig -DomainName contoso.com -KeySize 2048 -Enabled $false

# After publishing both CNAME records
Set-DkimSigningConfig -Identity contoso.com -Enabled $true

# Existing 1024-bit keys can be rotated to 2048-bit
Rotate-DkimSigningConfig -Identity contoso.com -KeySize 2048

Step 3: DMARC, starting in monitor mode

DMARC ties SPF and DKIM to the address people actually see in the From line, tells receivers what to do when a message fails, and sends you reports. Start with a monitoring-only policy:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]

• p=none means "take no action, just report." This is the minimum Gmail, Yahoo and Outlook.com require of bulk senders.
• rua= is where daily aggregate reports go. Use a dedicated shared mailbox, not someone's inbox. The reports are XML files; a DMARC reporting service makes them readable.
• Microsoft 365 does not send per-message failure (ruf) reports, so you can leave that tag out.

Step 4: Move to enforcement, gradually

Microsoft's DMARC guidance recommends working up to p=reject in stages:

1. Monitor with p=none for a few weeks. Use the reports to find legitimate senders that fail, and fix them (add to SPF, enable DKIM at that service, or move them to a subdomain).
2. Quarantine: change to p=quarantine, optionally with pct= to apply it to a percentage of failing mail first (for example 10, 25, 50, 100).
3. Reject: change to p=reject once reports show your legitimate mail consistently passes.

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
v=DMARC1; p=reject; rua=mailto:[email protected]

Don't forget these

• Parked domains: domains you own but never email from should have v=spf1 -all and v=DMARC1; p=reject; so nobody can spoof them.
• Your onmicrosoft.com domain: if you do not send from it, Microsoft recommends adding a DMARC record for it too, which you do in the Microsoft 365 admin center under Settings > Domains.
• Subdomains each need their own SPF and DKIM; they inherit DMARC from the parent unless you publish a separate record.

Quick checklist

Step	Done when
List all senders	Every system that sends as your domain is known
SPF	One TXT record, includes Microsoft 365 and other senders, ends in -all, under 10 lookups
DKIM	Both CNAMEs published, signing enabled, 2048-bit keys
DMARC p=none	Record published, reports arriving in a shared mailbox
Fix failures	Reports show legitimate mail passing
Enforce	p=quarantine, then p=reject
Parked domains	SPF -all and DMARC reject published

Need a hand with your DNS?

Email authentication is mostly careful bookkeeping: finding every sender and getting each record exactly right. Right On Tech sets up and monitors SPF, DKIM and DMARC for Microsoft 365 customers as part of our managed IT service. If your mail is landing in spam or you are not sure what your records say today, contact us and we will check them with you.