Key takeaway: SPF, DKIM, DMARC, and ARC are the four-layer email authentication framework every Microsoft 365 tenant needs to block spoofing and phishing. SPF authorizes your sending IPs in DNS, DKIM adds a cryptographic signature to every outbound message, DMARC enforces policy and requires alignment between the visible From address and the authenticated domain, and ARC preserves authentication results through email security gateways like Mimecast and Barracuda. Deploy them in that order — never enable DMARC enforcement before verifying SPF and DKIM pass for all your sending sources.

In This Article

  1. What Does SPF Do and How Do You Configure It for Exchange Online?
  2. How Does DKIM Work and How Do You Enable It in Exchange Online?
  3. What Is DMARC and How Do You Set a DMARC Policy?
  4. What Is ARC and Why Do You Need It with Email Security Gateways?
  5. In What Order Should You Deploy SPF, DKIM, DMARC, and ARC?

Email spoofing accounts for the majority of phishing attacks targeting Microsoft 365 tenants. SPF, DKIM, DMARC, and ARC are the four-layer authentication framework that closes that door. Each one does a different job, they work together, and you need all four to reach a defensible posture. Here is how to implement each correctly in Exchange Online as of 2025.

What Does SPF Do and How Do You Configure It for Exchange Online?

Sender Policy Framework (SPF) tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. It lives as a TXT record in DNS and is evaluated by the receiving server before the message is even accepted.

For a domain sending exclusively through Exchange Online, the SPF record is straightforward:

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

The include:spf.protection.outlook.com mechanism covers all Exchange Online datacenter IP ranges. Microsoft maintains that list, so you do not need to enumerate individual IP addresses. The -all at the end means hard fail — any server not listed is explicitly unauthorized. Use -all, not ~all (softfail). Softfail was a transitional mechanism and no modern anti-spam filter treats it differently from a neutral result.

If your organization also sends through a third-party service — a marketing platform, a CRM, a helpdesk ticketing system — each one needs its own include: mechanism. Watch the DNS lookup count. SPF has a hard limit of 10 DNS lookups during evaluation. Each include: consumes one lookup, and those includes may chain into more. Exceeding 10 causes a PermError, which most receivers treat as an SPF fail. If you are near the limit, use IP4/IP6 mechanisms for services that publish static IP ranges instead of include references.

One domain can have exactly one SPF TXT record. Multiple SPF records cause a PermError. If you are inheriting a domain with an existing SPF record, merge all mechanisms into a single record rather than adding a second one.

Current Microsoft guidance: Microsoft's Defender for Office 365 documentation recommends -all explicitly. As of 2025, Microsoft's own sending infrastructure for Exchange Online is covered entirely by spf.protection.outlook.com.

How Does DKIM Work and How Do You Enable It in Exchange Online?

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outbound message. The receiving server retrieves your public key from DNS and verifies the signature. If the message was tampered with in transit — headers modified, body changed — the signature fails. SPF validates the sending IP; DKIM validates the message itself.

Exchange Online generates DKIM keys automatically and enables signing for the initial *.onmicrosoft.com domain. For your custom domain, you need to enable it manually. In the Microsoft Defender portal, navigate to Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM. Select your domain and enable DKIM signing.

Enabling DKIM generates two CNAME records that you publish in your domain's DNS:

Exchange Online uses 2048-bit RSA keys as the default since 2023. Do not downgrade to 1024-bit. Microsoft manages key rotation automatically — they rotate between selector1 and selector2 — but you can also trigger a manual rotation in the Defender portal when needed.

DKIM signs the message body and specific headers including From, To, Subject, Date, and Content-Type. Any downstream system that modifies these headers — a mailing list manager, a bulk forwarding rule — will break the DKIM signature. This is exactly the problem that ARC was designed to solve.

What Is DMARC and How Do You Set a DMARC Policy?

Domain-based Message Authentication, Reporting and Conformance (DMARC) ties SPF and DKIM together under a policy that tells receiving servers what to do with messages that fail authentication. It also introduces alignment: the domain in the visible From header must align with the domain that passed SPF or DKIM. This closes the gap where an attacker could pass SPF on a different domain while spoofing your From address.

DMARC is a DNS TXT record at _dmarc.yourdomain.com. A standard progression:

Phase 1 — Monitor: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1;

Phase 2 — Quarantine: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com;

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

Start at p=none and collect aggregate reports (rua) for at least 30 days before advancing. Aggregate reports arrive as XML files — use a reporting service like Dmarcian, Valimail, or PowerDMARC to parse them into readable form. You are looking for all legitimate sending sources and making sure every one of them passes SPF or DKIM before you advance to enforcement.

Do not rush to p=reject. Moving to reject before auditing your sending infrastructure will cause legitimate mail to be silently dropped at receiving servers. Transactional mail from third-party systems is the most common casualty.

DMARC alignment can be relaxed (aspf=r, adkim=r) or strict (aspf=s, adkim=s). Relaxed alignment allows subdomain matches — a message signed with mail.yourdomain.com passes relaxed DMARC alignment for yourdomain.com. Strict alignment requires an exact match. Relaxed is the default and is appropriate for most organizations.

What Is ARC and Why Do You Need It with Email Security Gateways?

Authenticated Received Chain (ARC) solves one of DMARC's most painful operational problems: email security gateways and forwarding scenarios. When a message passes through Mimecast, Barracuda, Proofpoint, or any other gateway, the gateway typically modifies the message — rewrapping the SMTP envelope, adding headers, sometimes rewriting links. This breaks DKIM signatures and changes the SPF-validating IP, causing legitimate mail to fail DMARC even though it was authenticated when it entered the gateway.

ARC works by having the gateway preserve the original authentication results in a chain of signed headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal). The final receiving server checks the ARC chain and, if it trusts the gateway's seal, can honor the original authentication result even though SPF and DKIM would otherwise fail.

Exchange Online supports ARC verification and evaluates incoming ARC chains from trusted sealers. To add a trusted ARC sealer in Exchange Online, use Exchange Online PowerShell:

Set-ArcConfig -Identity Default -ArcTrustedSealers mimecast.com

You can add multiple trusted sealers comma-separated. Mimecast, Barracuda, and Proofpoint all implement ARC sealing. Check your vendor's documentation to confirm their sealer domain — it is not always the same as the product domain.

Without ARC trust configured, any mail that routes through a gateway before landing in Exchange Online will fail DMARC alignment at your tenant. With ARC trust in place and the gateway configured to seal, the chain is preserved and DMARC enforcement works correctly across the entire flow.

In What Order Should You Deploy SPF, DKIM, DMARC, and ARC?

The correct order of implementation matters. Do not enable DMARC enforcement before both SPF and DKIM are verified passing for all your sending sources.

  1. Publish SPF for all sending domains. Confirm passing with an external test sender.
  2. Enable DKIM in Defender portal. Publish the two CNAME records. Allow 24–48 hours for DNS propagation, then verify signing.
  3. Publish DMARC at p=none with rua reporting address. Wait 30+ days and review aggregate reports.
  4. Configure ARC trusted sealers in Exchange Online PowerShell for any email gateways in your mail flow.
  5. Advance DMARC to p=quarantine once you have confirmed all legitimate sources pass. Monitor for 2 weeks.
  6. Advance to p=reject once quarantine is clean.

The Microsoft Defender portal's Email Authentication Settings page now includes a DMARC configuration panel that shows current SPF, DKIM, and DMARC status for each of your accepted domains alongside any failures detected in inbound mail. Use the Threat Protection Status report in Defender for Office 365 to track authentication pass rates over time and catch regressions when mail flow changes.

Email authentication is not a one-time configuration — it requires maintenance. When you add a new sending service, add it to SPF before it goes live. When you deploy a new gateway, configure ARC trust before you cut MX records. Build these steps into your change management process and DMARC enforcement will hold.

Exchange OnlineDKIMSPFDMARCARCEmail SecurityMimecastBarracuda
← All Articles Free Assessment