How to set up SPF, DKIM and DMARC for Microsoft 365

If your company uses Microsoft 365 for email, three DNS records decide whether criminals can send email that looks like it came from you. This guide sets them up in the safe order, then adds the extras that earn an A on our checker.

Before you start

• Admin access to the Microsoft 365 admin center and the Microsoft Defender portal (security.microsoft.com).
• Access to your DNS host, wherever your domain's DNS records are managed (Cloudflare, GoDaddy, your registrar or your website host).
• A list of everything that sends email as your domain. Think newsletters, invoicing and accounting, CRM, help desk, website forms, payroll and HR systems, and scanners or copiers. Most problems at go-live come from a sender someone forgot.
• Time: about an hour of hands-on work, spread across 2–4 weeks of watching reports before full enforcement.

In the examples below, replace yourdomain.com with your domain.

Step 1: SPF (who may send as you)

SPF is one TXT record at the root of your domain (host @) that lists the services allowed to send your email. For Microsoft 365 alone:

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

If other services send as you, add the include: value each one documents, before the ~all. For example: v=spf1 include:spf.protection.outlook.com include:other-service.example ~all

• Only one SPF record. Two v=spf1 records make SPF fail everywhere. Merge them.
• Ten lookups maximum. Each include:, a and mx counts, including the ones inside other includes. Remove services you no longer use.
• ~all now, -all later. Start with soft-fail. Switch to -all once DMARC reports show every legitimate sender passing.

Step 2: DKIM (signed email)

DKIM adds a cryptographic signature to every message, so receivers can tell it really came from you and wasn't altered.

1. In the Microsoft Defender portal, go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings, then the DKIM tab.
2. Select your domain. Microsoft shows two CNAME records, for hosts selector1._domainkey and selector2._domainkey.
3. Copy both values exactly into your DNS host. The target format differs between older and newer tenants, so don't copy it from another guide. If you use Cloudflare, set both to DNS only (grey cloud).
4. Wait for DNS to update (usually minutes, sometimes an hour), then turn on Sign messages for this domain with DKIM signatures. If you see "CNAME record does not exist", wait and try again.

Every third-party service that sends as you should also sign with DKIM for your domain. Look for "domain authentication" or "custom sending domain" in each service's settings.

Step 3: DMARC in monitoring mode

DMARC tells receivers what to do with mail that fails SPF and DKIM, and sends you reports about who is sending as your domain. Start in monitoring mode. Add a TXT record with host _dmarc:

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

Create that mailbox first (a shared mailbox or group works well). Reports arrive daily as zipped XML files that are hard to read raw, so most teams forward them to a DMARC report service; several have free tiers for small domains.

For 2–4 weeks, look for legitimate services that fail. Fix each one by adding it to SPF or setting up its DKIM. Ignore unknown senders you don't recognize: that's usually spoofing, which is exactly what enforcement will block.

Step 4: Enforce DMARC

When the reports show your real senders passing, tighten the policy in two steps:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Leave quarantine in place for 1–2 weeks. Failing mail goes to spam rather than disappearing, so mistakes are recoverable. Then move to full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Now change SPF from ~all to -all. At this point, email forged from your domain is blocked by Gmail, Outlook, Yahoo and most business mail systems. Large mailbox providers already require SPF, DKIM and DMARC from bulk senders, so this also protects your deliverability.

Step 5: Extras for an A

MTA-STS (forces encrypted delivery to you)

Two parts. A TXT record with host _mta-sts:

v=STSv1; id=20261112

And a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

Use the mx pattern that matches your MX record: if it ends in mx.microsoft rather than mail.protection.outlook.com, use mx: *.mx.microsoft. You can list more than one mx line. After a few weeks of clean TLS reports, change mode to enforce, raise max_age to 604800, and change the id in the TXT record (any new value, such as today's date) so senders fetch the new policy.

TLS reporting

TXT record with host _smtp._tls:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

DNSSEC

Turn on DNSSEC at your DNS host. If your registrar is a different company, copy the DS record it gives you into your registrar's DNSSEC settings. With Cloudflare, it's one click plus that one copy.

CAA

CAA records limit which certificate authorities can issue HTTPS certificates for your domain. Add one CAA record (host @) for each authority you actually use, for example 0 issue "letsencrypt.org". Check which ones your website host uses first.

Domains that never send email

Parked and redirect-only domains get spoofed too. Lock them down with SPF v=spf1 -all, DMARC v=DMARC1; p=reject; and a "null MX" record (MX priority 0, host .).

Common mistakes