Configure SPF, DKIM and DMARC for Microsoft 365 (practical 2026 guide)

In 2026, Gmail, Yahoo, Outlook.com and virtually all B2B mail servers systematically check SPF, DKIM and DMARC before accepting a message. An email without these records can land directly in spam — or, worse, be silently rejected (soft fail or hard fail depending on the receiving server's policy). For an SMB sending quotes, invoices or contracts by email, degraded deliverability directly translates to lost revenue.

The three mechanisms serve distinct but complementary roles:

• SPF (Sender Policy Framework): publishes the list of servers authorised to send from your domain. If someone tries to send an email "on your behalf" from an unlisted server, the SPF check fails. Microsoft 365 requires that include:spf.protection.outlook.com appears in your TXT record.
• DKIM (DomainKeys Identified Mail): adds a cryptographic signature to every outbound email. The receiving server verifies the signature via a public key published in your DNS. Even if an email is forwarded through a relay, the signature remains verifiable. Microsoft 365 uses two DKIM selectors (selector1 and selector2) published as CNAME records.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): orchestrates the previous two. It defines what a receiving server should do if SPF or DKIM fails (ignore, quarantine or reject), and which address to send incident reports to. Without DMARC, SPF and DKIM have no deterrent effect on spoofing: an attacker can still send an email where SPF fails and which may end up in spam rather than inbox, but without guaranteed rejection.

Google made DMARC mandatory for senders of more than 5,000 emails/day since February 2024 — and progressively extended the requirement to lower volumes. Yahoo followed immediately. In practice, if your SMB does not have DMARC at p=quarantine minimum, you are exposed to spoofing of your own domain: a competitor, a fraudster or ransomware can send emails claiming to come from yourdomain.com, and some recipients will receive them in inbox.

The good news: once correctly configured, these three records require no maintenance. The few hours of initial setup are an investment with immediate ROI in security and deliverability.

Replace yourdomain.com with your actual domain. These values are standard for Microsoft 365; the only values specific to your tenant are the two DKIM CNAMEs (retrievable in the M365 Admin Center → Settings → Domains → your domain → DNS Records).

1. MX — Email reception
   Type: MX | Host: @ | Value: yourdomain-com.mail.protection.outlook.com | Priority: 0 | TTL: 3600
   The exact value is provided by the M365 Admin Center for your domain.
2. SPF — Sender authentication
   Type: TXT | Host: @ | Value: v=spf1 include:spf.protection.outlook.com -all | TTL: 3600
   If you use third-party senders (e.g. Mailchimp, Brevo, your ERP), add their includes BEFORE -all. Only create one SPF record per domain — multiple SPF TXT records cancel each other out.
3. DKIM selector 1 — Outbound signature
   Type: CNAME | Host: selector1._domainkey | Value: selector1-yourdomain-com._domainkey.YOUR_TENANT.onmicrosoft.com | TTL: 3600
4. DKIM selector 2 — Outbound signature (rotation)
   Type: CNAME | Host: selector2._domainkey | Value: selector2-yourdomain-com._domainkey.YOUR_TENANT.onmicrosoft.com | TTL: 3600
5. DMARC — Policy and reporting
   Type: TXT | Host: _dmarc | Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1; adkim=r; aspf=r | TTL: 3600
   Start at p=none (monitoring only) — see the "Progressive DMARC strategy" section below.
6. Autodiscover — Automatic Outlook configuration
   Type: CNAME | Host: autodiscover | Value: autodiscover.outlook.com | TTL: 3600
7. SRV Teams/Skype (optional but recommended)
   Type: SRV | Service: _sip | Protocol: _tls | Host: @ | Value: sipdir.online.lync.com | Port: 443 | Priority: 100 | Weight: 1 | TTL: 3600

Recommended publication order: SPF first, then DKIM (wait for propagation — 15 to 60 min), then enable DKIM in the M365 Admin Center (click "Enable" per selector), then DMARC, and finally MX if migrating from a previous host. Publishing MX before SPF/DKIM guarantees your first outbound emails will be flagged as suspicious.

DNS interfaces vary enough between registrars that field names can be confusing. Here are specific notes for each.

Cloudflare

Log in to dash.cloudflare.com, select your zone → DNS → Add record. For MX: type MX, name @, mail server = value provided by M365, priority 0. For SPF and DMARC: type TXT, name @ for SPF, name _dmarc for DMARC. Important: for DKIM CNAMEs, disable the Cloudflare proxy (set to DNS only / grey cloud) — proxied DKIM CNAMEs break signature verification. For MX, proxy is irrelevant (MX records are never proxied). Cloudflare typically propagates in under 5 minutes.

OVH

OVH client area → Web Cloud → Domain names → your domain → DNS Zone → Add an entry. For SPF: choose "TXT", target = the full SPF value, subdomain blank (for @). For DKIM: choose "CNAME", subdomain = selector1._domainkey (without the domain suffix — OVH appends it automatically). For DMARC: TXT, subdomain = _dmarc. Recommended TTL: 3600 s. OVH propagation can take 2 to 4 hours in Europe.

IONOS

IONOS client area → Domains → your domain → DNS → Add record. For SPF and DMARC: select "TXT", hostname = @ for SPF and _dmarc for DMARC. For DKIM CNAMEs: select "CNAME", hostname = selector1._domainkey.yourdomain.com (IONOS does not append the domain automatically — enter the full FQDN with optional trailing dot). Verify in the preview that the displayed record has no domain duplication.

Gandi

Log in to admin.gandi.net → Domain name → your domain → DNS Records → Add. Gandi offers the classic zone editor or the new LiveDNS editor. In LiveDNS: type TXT, name @ for SPF (leave name blank for root), name _dmarc for DMARC, name selector1._domainkey for DKIM. If editing in classic zone mode (BIND text), copy the lines directly in @ IN TXT "v=spf1 ..." format. Default TTL: 10800 — change to 3600 to reduce propagation delay during adjustments.

GoDaddy

My Products → DNS → Manage DNS for your domain. Add TXT, CNAME and MX via the Add button. For SPF TXT: Host = @, TXT Value = the SPF value. For DMARC: Host = _dmarc. For DKIM CNAME: Host = selector1._domainkey (GoDaddy appends the domain suffix automatically). GoDaddy propagation can take 30 minutes to 1 hour. Note: GoDaddy tends to create default MX records (parking) — delete them before adding Microsoft's.

Namecheap

Dashboard → Domain List → Manage → Advanced DNS. Add TXT Record (Host @ for SPF, _dmarc for DMARC), and CNAME Record (Host selector1._domainkey for DKIM — Namecheap appends the domain automatically). MX is configured in the "Mail Settings" tab if you use Namecheap hosting, or directly as a DNS Record otherwise. Propagation: generally under 30 min.

Before declaring configuration complete, verify each record with these three free tools. Don't wait for a deliverability problem to use them.

MXToolbox (mxtoolbox.com)

The reference tool for email DNS. Use the specific checks:

• MX Lookup: confirms your MX points to *.mail.protection.outlook.com
• SPF Record Lookup: validates SPF syntax and counts DNS lookups (maximum 10 allowed by the standard)
• DKIM Lookup: enter your domain + selector (selector1 or selector2) — verifies the CNAME is resolvable and the public key is readable
• DMARC Lookup: checks DMARC syntax and shows the current policy

Read the results: any red indicator is blocking. For yellow (warnings), evaluate in your context. MXToolbox explains each error with a link to the relevant RFC.

Dmarcian (dmarcian.com)

DMARC-specialised tool. Its most useful feature: the DMARC Inspector which breaks down your DMARC record tag by tag and detects subtle syntax errors (e.g. comma vs semicolon). Dmarcian also offers a free version of the DMARC dashboard that aggregates XML reports received on rua@ — essential during the monitoring phase (p=none) to identify which services are sending from your domain.

Mail-tester (mail-tester.com)

Different approach: send a real email from your M365 mailbox to the temporary address generated by the site. Mail-tester analyses the received message and gives a score /10 with detail for each check: SPF, DKIM, DMARC, IP reputation, anti-spam score (Spamassassin), presence in blacklists. It is the only tool that tests the end-to-end flow — an SPF that passes in lookup but fails on a real email sometimes reveals a configuration incompatibility. Aim for 9/10 minimum before considering the config complete.

Reading common results

• SPF: permerror → multiple SPF TXT records published — keep only one
• DKIM: no key for selector → CNAME has not yet propagated, or you have not enabled DKIM in the M365 Admin Center
• DMARC: p=none → normal in the initial phase, move to quarantine after 4 weeks of clean monitoring
• Mail-tester score < 7/10 → check if your IP is blacklisted (the "Blacklists" section) or if an SPF include generates a PermError due to exceeding the 10-lookup threshold

Jumping directly to p=reject is a common mistake that can block legitimate emails if a third-party service (newsletter, CRM, ERP) sends from your domain without being properly authenticated. The correct approach is progressive hardening in three phases.

Phase 1 — Weeks 1 to 4: Monitoring (p=none)

Initial record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1; pct=100

At p=none, no email is rejected or quarantined, but you receive daily XML reports on all sending sources from your domain. Analyse these reports (via Dmarcian or by parsing the XML) to identify:

• Your own M365 servers (should be SPF/DKIM pass)
• Legitimate third-party services (newsletter, ERP) — add them to SPF or configure DKIM for them
• Unknown sources attempting to spoof your domain — this is exactly what DMARC is for

Phase 2 — Weeks 5 to 10: Quarantine (p=quarantine)

After fixing all legitimate services identified in Phase 1:

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

Start with pct=25 (only 25% of failing emails are quarantined). Monitor for 2 weeks. If no false positives, move to pct=100. Emails that fail DMARC land in the recipient's spam folder rather than inbox.

Phase 3 — Week 10+: Reject (p=reject)

Once p=quarantine; pct=100 has been stable for 2 weeks without incident:

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

At p=reject, any email that fails DMARC is refused by the receiving server, landing nowhere. This is the maximum protection against spoofing of your domain. Continue receiving and analysing rua reports monthly to detect any new unauthorised sending services.

If your domain sends many newsletters via Mailchimp, Brevo or SendGrid, configure DKIM via those platforms' interfaces (they provide their own CNAMEs) before moving to p=reject — otherwise all your newsletters will be rejected.

Here are the problems we encounter most often during DNS audits for our Microsoft 365 clients.

1. SPF "PermError: too many DNS lookups"
   Symptom: MXToolbox displays a lookup-count-exceeded error. Cause: each include: in your SPF generates a recursive lookup. With M365 + Mailchimp + Brevo + your ERP, you easily exceed 10. Diagnosis: use MXToolbox SPF to see the exact count. Solution: "flatten" the SPF by replacing recursive includes with direct IPs via a service like AutoSPF or SPFFlattener.
2. DKIM "selector not found" or "CNAME resolution failure"
   Symptom: MXToolbox DKIM returns "no record found". Possible causes: (a) you published the CNAME but did not click "Enable DKIM" in the M365 Admin Center — the key has not been generated; (b) your registrar doubled the domain (e.g. selector1._domainkey.yourdomain.com.yourdomain.com); (c) DNS propagation is not complete. Check with dig CNAME selector1._domainkey.yourdomain.com +short from a terminal.
3. DMARC "alignment failure" despite SPF and DKIM passing
   Symptom: DMARC reports show failures even though SPF and DKIM individually pass. Cause: DMARC requires alignment — the domain in the email's From: must match the SPF or DKIM domain. If your ERP sends from noreply@notifications.yourdomain.com but your SPF only covers yourdomain.com, strict alignment (aspf=s) fails. Solution: use relaxed alignment (aspf=r; adkim=r) or extend the SPF to the subdomain.
4. MX still pointing to the old host
   Symptom: inbound emails still arrive in the old mailbox several hours after the cutover. Cause: the old MX's TTL was high (e.g. 86400 = 24h), and upstream servers cached the old value. Diagnosis: dig MX yourdomain.com @8.8.8.8 to see what Google resolves. Prevention: lower the MX TTL to 300 s 48 hours before the cutover.
5. Mail-tester score dropping due to IP reputation
   Symptom: SPF/DKIM/DMARC are all green but the score is 6/10 due to a blacklisted IP. Cause: Microsoft 365 shares its outbound IPs among millions of tenants; an IP can be temporarily blacklisted due to another M365 customer who spammed. Short-term solution: send from a dedicated M365 IP (available on Enterprise plans) or use a warm-up service. Immediate solution: contact us at contact@africwebhosting.com — we can check your specific tenant and escalate to Microsoft support if necessary.