Email Authentication for Office 365: SPF, DKIM, and DMARC Setup Guide

Email authentication O365 usually means configuring SPF, DKIM, and DMARC so Microsoft 365 can prove that messages using your domain are legitimate. The records live in public DNS, but successful deployment depends on mapping every system that sends mail as your domain before you enforce a DMARC policy.

What email authentication means in Office 365

Microsoft 365 and Office 365 are commonly used interchangeably in email administration, but the relevant service is Exchange Online. When recipients receive a message claiming to be from you@example.com, their mail system needs a way to distinguish your authorized infrastructure from a criminal, misconfigured application, or random internet host impersonating your domain.

The core standards are:

• SPF (Sender Policy Framework): declares which mail sources are allowed to send using an envelope-sender domain.
• DKIM (DomainKeys Identified Mail): attaches a cryptographic signature that recipients can validate using a public key in DNS.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): checks whether SPF or DKIM passes and aligns with the visible From domain, then publishes a requested disposition for failures.

Microsoft describes DMARC as a validation method for mail from your organization that helps prevent spoofing used in phishing, business email compromise, and ransomware campaigns. A message can pass DMARC when either aligned SPF or aligned DKIM passes; it fails only when both fail. (learn.microsoft.com)

This distinction matters: a green SPF result alone is not proof that the address people see in Outlook is genuine. A sender can use one domain in the SMTP envelope and display another in the visible From field. DMARC binds authentication to the domain users actually see.

The goal: authorize every legitimate sender, then block impersonation

A safe email authentication O365 project has two goals that can seem opposed:

1. Ensure legitimate Microsoft 365 mail and approved third-party mail continue to deliver.
2. Tell recipients to quarantine or reject unauthenticated mail that falsely claims to be from your domain.

The first goal comes before the second. If you publish a strict DMARC policy before identifying every sender, you can interrupt password-reset mail, invoices, CRM campaigns, form notifications, printer scans, helpdesk messages, and application alerts.

Start by listing every outbound stream that can use your domain in a visible From address. In a typical organization, that inventory includes:

• Exchange Online user mailboxes and shared mailboxes.
• Microsoft 365 groups and automated workflows.
• Marketing platforms and newsletters.
• Customer-support, ticketing, and CRM tools.
• Transactional email services used by product teams.
• Website contact forms and ecommerce platforms.
• Multifunction printers, scanners, monitoring tools, and line-of-business applications.
• On-premises or cloud relays.
• Subdomains such as news.example.com, notify.example.com, or support.example.com.

For each stream, record the visible From domain, the return-path or envelope-sender domain, the sending service, whether it supports custom DKIM, and the owner who can test it. This inventory is the operational work that prevents a DMARC rollout from becoming an email outage.

Microsoft recommends configuring SPF, DKIM, and DMARC in that order for custom domains, including parked domains and subdomains. (learn.microsoft.com)

How SPF, DKIM, and DMARC work together

SPF: authorize the mail path

SPF is a DNS TXT record placed at the sending domain. Receiving systems compare the connecting sender against mechanisms in that record. For a domain that sends only through Microsoft 365, the common record is:

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

include:spf.protection.outlook.com authorizes Microsoft 365’s published sending infrastructure. -all is a hard fail for sources not covered by earlier mechanisms. The exact record belongs on the domain used as the envelope sender, which is often represented in a message’s Return-Path header.

SPF is useful, but it is path-sensitive. Normal forwarding can make SPF fail because the forwarding server’s IP address is not in the original sender’s SPF record. Microsoft explicitly identifies this as expected behavior, which is one reason DKIM is important for modern mail flows. (learn.microsoft.com)

DKIM: sign the message

DKIM adds a signed DKIM-Signature header to outgoing mail. The recipient fetches the signer’s public key from DNS and verifies that the signed portions of the message have not changed. DKIM normally survives forwarding better than SPF, although some intermediaries can modify a signed message enough to invalidate it.

For Microsoft 365 custom domains, you publish two CNAME records and then enable DKIM signing in the Microsoft Defender portal. Microsoft uses two selectors so keys can be rotated without interrupting validation. (learn.microsoft.com)

A DKIM signature includes a d= domain value. For DMARC, that signing domain must align with the visible From domain. A third-party sender that signs with only its own domain may show dkim=pass, yet still fail DMARC for your domain.

DMARC: add identity alignment, policy, and reporting

DMARC lives at _dmarc.example.com as a TXT record. It checks whether either of these conditions is true:

• SPF passes and the envelope-sender domain aligns with the visible From domain.
• DKIM passes and the DKIM d= domain aligns with the visible From domain.

The two domains do not always have to be character-for-character identical. DMARC supports relaxed alignment by default, allowing organizational-domain alignment such as mail.example.com with example.com. Strict alignment can be configured when needed, but it is not a sensible first move for most organizations.

DMARC additionally tells receivers what you request for failures: monitor only (p=none), place in spam or quarantine (p=quarantine), or refuse delivery (p=reject). It also supports aggregate reports, which show who is sending mail that claims to be from your domain. (dmarc.org)

Step 1: build the correct SPF record for Microsoft 365

Start with one SPF record, not one per sender

A domain can have one SPF policy record. Publishing multiple TXT records that begin with v=spf1 commonly produces an SPF permanent error. Microsoft lists multiple SPF records as a cause of permerror, along with exceeding SPF’s DNS lookup limit. (learn.microsoft.com)

If Microsoft 365 is the only source sending envelope mail for example.com, use:

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

DNS host interfaces vary: @, a blank host field, or the bare domain may all represent the zone apex. Use your provider’s convention, but verify the published result with a DNS lookup rather than assuming the interface saved it correctly.

Add authorized third-party services before -all

If a marketing platform sends with an envelope sender under example.com, add the mechanism that the vendor publishes before the final -all. For example, the pattern looks like this:

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

Do not copy vendor-example.invalid; it is only a placeholder. Obtain the real include domain, IP range, or custom bounce-domain instructions from that sender’s official documentation.

Do not use +all. It effectively authorizes every IP address on the internet and defeats SPF’s purpose. Avoid ~all as a permanent substitute for an accurate policy; it signals a soft failure and can hide incomplete sender discovery.

Respect SPF’s lookup budget

SPF evaluation has a limit of 10 DNS-querying mechanisms and modifiers. include, a, mx, exists, redirect, and some other mechanisms can consume that budget. A long chain of nested vendor includes can therefore turn an otherwise valid-looking record into permerror.

Before adding another SaaS include, ask two questions:

1. Does the service actually send with your root domain as the envelope sender?
2. Can it instead use a dedicated sending subdomain such as mail.example.com or notify.example.com?

Subdomains are usually cleaner. They isolate vendor-specific SPF policy, reputation, and DKIM configuration while leaving employee mail on the primary domain.

Step 2: enable DKIM signing for your Microsoft 365 domain

Publish the two CNAME records Microsoft gives you

In the Microsoft Defender portal, open the DKIM configuration area, choose your custom domain, and copy the two CNAME records displayed for that domain. Microsoft-specific values depend on your tenant and initial .onmicrosoft.com domain, so do not reuse values from another company or a generic blog post.

The record names follow this shape:

selector1._domainkey.example.com CNAME selector1-example-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.example.com CNAME selector2-example-com._domainkey.<tenant>.onmicrosoft.com

The target values above are illustrative. In production, copy the exact targets presented in your tenant. Domain punctuation is represented differently in the Microsoft target value, and your tenant’s initial domain is unique.

After DNS publishes, return to the DKIM page and enable signing for the domain. Microsoft’s guidance is to publish the CNAME records first and enable DKIM after they are available. (learn.microsoft.com)

Do not confuse Microsoft 365 DKIM with vendor DKIM

Enabling DKIM in Microsoft 365 signs mail that Exchange Online sends. It does not automatically sign messages sent directly by your marketing platform, ecommerce provider, or transactional email service.

Each external sender must be configured separately. A reputable sender normally provides one or more DNS records for custom DKIM, often CNAME records. Complete that vendor’s domain-authentication flow and make sure the resulting d= value is your domain or an aligned subdomain.

For application notifications, prefer an authenticated dedicated subdomain rather than attempting to route every product email through a personal mailbox. If your team is evaluating an API-based sending workflow, the provider’s email API setup guides should be treated as part of the sender inventory and authenticated before production traffic starts.

Why two selectors matter

The selector is the part before ._domainkey. A signature might show:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

The recipient looks up:

selector1._domainkey.example.com

Microsoft can move signing from selector1 to selector2 during key rotation while both records remain available. Do not delete one selector merely because your latest test message uses the other.

Step 3: publish DMARC in monitoring mode

Once Microsoft 365 mail is SPF-authorized and DKIM-signed, publish a DMARC record at the _dmarc host name:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

This is a conservative starting point. Its components are:

Use a dedicated address or reporting service for rua; aggregate reports arrive as compressed XML files and are not designed for routine human reading. Monitor-only DMARC does not itself instruct recipients to block failing mail, but it gives you visibility into legitimate and unauthorized sources.

If reports go to an address outside the domain being evaluated, external reporting authorization may be required. DMARC report generators check for that authorization before sending reports to an external destination. (dmarc.org)

Include a subdomain policy deliberately

A parent-domain DMARC record can influence subdomains that lack their own DMARC record. If you want a clear policy for subdomains, include sp= explicitly:

v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

This is particularly valuable when a marketing subdomain, application subdomain, or unused subdomain has a different authentication posture from employee mail on the apex domain.

Step 4: read the reports and fix alignment failures

DMARC aggregate reports tell you which IP addresses sent mail using your domain, how often they did so, and the observed SPF and DKIM results. The key task is classification, not merely counting passes and failures.

For every notable sending source, decide whether it is:

• Expected and correctly authenticated: no change required.
• Expected but failing: repair its SPF, DKIM, return-path, or From-domain configuration.
• Unknown but legitimate: identify the business owner before authorizing it.
• Unauthorized: do not add it to SPF; prepare DMARC enforcement to protect against it.

Common alignment patterns

Here are the results that matter most:

Microsoft’s message processing adds an Authentication-Results header to inbound email, containing SPF, DKIM, DMARC, and Microsoft composite authentication results. That header is useful for investigating a single message, while aggregate reports are better for finding systemic problems. (learn.microsoft.com)

Step 5: move from p=none to quarantine and reject

DMARC becomes protective only when you request an enforcement policy. The usual progression is:

1. Publish p=none and collect reports.
2. Fix every known legitimate sender that fails alignment.
3. Move to p=quarantine.
4. Continue investigating report data and delivery issues.
5. Move to p=reject when you are confident in sender coverage.

A strict destination state looks like this:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

p=reject asks recipient systems to reject mail that fails DMARC. Recipient systems ultimately apply their own local policies, so no domain owner can guarantee identical treatment at every mailbox provider. But an enforcement record gives receivers a strong, standardized instruction and makes straightforward spoofing significantly harder.

Avoid treating pct= as a universal rollout control. Older DMARC practice used pct to request policy application to a percentage of failing messages, but DMARC standardization has evolved and some tags have been deprecated in newer protocol work. A cleaner operational approach is to keep monitoring until your sender inventory is complete, then use a full policy for domains that are ready. (dmarc.org)

Worked example: authenticate northstar.example in Microsoft 365

Assume Northstar uses Exchange Online for employee mail, a helpdesk platform for support messages, and a transactional provider for product receipts. The company sends people-facing mail from:

• alice@northstar.example through Microsoft 365.
• support@northstar.example through a helpdesk platform.
• receipts@notify.northstar.example through a transactional provider.

1. Separate the traffic where practical

Northstar keeps employee mail on the root domain and puts product receipts on notify.northstar.example. This means the product team can authenticate its provider on a dedicated subdomain without modifying the primary SPF record for every vendor change.

2. Configure root-domain SPF

The root domain sends through Exchange Online and the support platform. The final value depends on the helpdesk vendor’s official authorization instructions, but the structure is:

northstar.example TXT "v=spf1 include:spf.protection.outlook.com include:<helpdesk-authorized-domain> -all"

The administrator confirms there is no second v=spf1 TXT record at northstar.example and checks that the combined policy remains within SPF’s lookup limit.

3. Enable Microsoft 365 DKIM

In Microsoft Defender, Northstar selects northstar.example, copies the tenant-specific selector1 and selector2 CNAME values, publishes them at its DNS host, then enables DKIM. It sends a message from an Exchange Online mailbox to an external test inbox and verifies a result resembling:

spf=pass
DKIM=pass header.d=northstar.example
dmarc=pass header.from=northstar.example

4. Authenticate the helpdesk sender

The helpdesk vendor is configured to sign mail with d=northstar.example or an aligned subdomain and to use a correctly configured custom return path where the platform supports one. Northstar sends a real ticket notification to an external mailbox and checks headers again.

If the message shows spf=pass for the vendor’s unrelated bounce domain and dkim=pass header.d=vendor.example, it can still fail DMARC because neither identifier aligns with northstar.example. The fix is not adding random vendor IP ranges to SPF; it is finishing the platform’s custom-domain authentication setup.

5. Authenticate the product sender on a subdomain

The transactional provider receives DKIM and SPF configuration for notify.northstar.example. Northstar publishes a dedicated DMARC record there:

_dmarc.notify.northstar.example TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r"

The product mail uses From: receipts@notify.northstar.example, and the provider signs with d=notify.northstar.example. This is aligned and passes DMARC independently of the employee-mail configuration.

6. Publish monitoring DMARC at the root

Northstar then publishes:

_dmarc.northstar.example TXT "v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r"

After reviewing reports and resolving any authorized failures, Northstar changes the policy to p=quarantine, then eventually to p=reject. The result is that an attacker sending from an unrelated server with From: ceo@northstar.example has neither aligned SPF nor aligned DKIM and is subject to the requested DMARC enforcement.

Office 365 mail sources that commonly break authentication

Printers, scanners, and legacy applications

A multifunction printer or legacy business application is not automatically a secure mail server. Microsoft documents several sending methods for these devices: authenticated client SMTP submission, SMTP relay through a connector, Direct Send for internal recipients, and High Volume Email for internal volume scenarios. Direct Send cannot relay to the internet through Microsoft 365. (learn.microsoft.com)

The wrong solution is to allow a device to impersonate arbitrary users or to leave a broad relay exposed. Choose a method appropriate to the recipients, authentication capabilities, network design, and sender identity. If mail leaves your organization using your domain, ensure the actual sending path has aligned SPF or DKIM.

Third-party senders that use the root domain

Marketing and SaaS platforms are frequent DMARC failure sources because their default setup often uses a vendor return path and vendor DKIM domain. Use their custom-domain or domain-authentication workflow. If they cannot sign with an aligned domain, send from a clearly separate vendor-controlled subdomain only if that arrangement fits your branding and risk model.

Forwarding lists and message modification

Forwarding commonly breaks SPF, and mailing lists or security gateways can break DKIM by changing the body, subject, footer, or MIME structure. ARC can preserve authentication results through legitimate intermediaries, and Microsoft supports configuring trusted ARC sealers for services you explicitly trust. Do not trust an ARC sealer simply because it appears in a header; validate the service and scope first. (learn.microsoft.com)

Parked and unused domains

A domain that does not send mail can still be spoofed. Publish a restrictive SPF record such as v=spf1 -all and a DMARC record requesting rejection after validating that the domain truly has no sending use. Microsoft specifically includes parked domains in its DMARC guidance. (learn.microsoft.com)

How to test that email authentication O365 worked

Do not treat a successfully saved DNS record as proof. Test the final mail flow from each source.

Check DNS directly

Confirm these lookups return exactly the intended records:

nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com
nslookup -type=cname selector1._domainkey.example.com
nslookup -type=cname selector2._domainkey.example.com

On macOS or Linux, dig is often more readable:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME selector1._domainkey.example.com

Look for duplicate SPF policies, misplaced _dmarc labels, missing CNAME targets, quotation errors introduced by a DNS interface, and records published in the wrong DNS zone.

Inspect message headers

Send one test message from every outbound platform to an independent external mailbox. In the full headers, find Authentication-Results and verify:

spf=pass
dkim=pass
dmarc=pass

For the strongest result, check that header.from= is your intended visible domain and that either the SPF domain or DKIM header.d= aligns with it. Microsoft notes that the Authentication-Results header is the primary place to inspect SPF, DKIM, DMARC, and composite authentication outcomes for messages received by Microsoft 365. (learn.microsoft.com)

Confirm the sender identity, not only the pass/fail labels

A pass result from a vendor domain may not protect your brand domain. Inspect:

• The visible From: address.
• The Return-Path: or envelope sender.
• The DKIM d= domain.
• The DMARC header.from= domain and result.

This catches the classic false sense of security: SPF and DKIM each pass, but DMARC fails because neither pass is aligned with the visible From domain.

A practical maintenance checklist

Email authentication is not a one-time DNS task. Treat it as a change-management control whenever your company adopts or retires a sender.

• Add a sender review to procurement and application-launch checklists.
• Require a test message and header review before a new platform sends to customers.
• Recheck SPF lookup count whenever adding a vendor include.
• Keep DKIM records available during provider and key-rotation changes.
• Review DMARC reports for new sending IPs, failures, and unexpected geographies or services.
• Remove old sender authorizations when a vendor is retired.
• Publish DMARC on active and non-sending domains, with policies appropriate to their real use.
• Investigate sudden delivery problems by looking at headers before weakening DMARC.

The important long-term rule is simple: do not authorize a source merely because it appears in a report. First establish whether it is a legitimate sender, whether it needs to use your domain, and whether it can authenticate in an aligned way.

Conclusion

Email authentication O365 is successful when all authorized Microsoft 365 and third-party senders produce aligned SPF or DKIM results, your DMARC reports contain no unexplained legitimate traffic, and your organization can enforce a quarantine or reject policy without disrupting mail.

Start with a sender inventory, publish one accurate SPF record, enable DKIM for every domain and sending platform, monitor DMARC reports, and only then enforce DMARC. That sequence protects your domain from direct spoofing while giving legitimate business mail a path to keep delivering.

FAQ

Does Microsoft 365 automatically configure SPF, DKIM, and DMARC for my custom domain?

No. Microsoft 365 has service defaults and uses its own infrastructure, but custom-domain authentication requires DNS configuration. You must publish SPF, add the tenant-specific DKIM CNAME records and enable signing, then publish DMARC for each domain you want to protect. (learn.microsoft.com)

What is the SPF record for Office 365?

For a domain that sends only through Microsoft 365, the standard pattern is v=spf1 include:spf.protection.outlook.com -all. If other systems send mail using that envelope domain, add only their verified authorization mechanisms before -all and keep a single SPF record. (learn.microsoft.com)

Should I set DMARC to p=reject immediately?

Usually no. Begin with p=none, review aggregate reports, and fix legitimate sources that fail alignment. Move to p=quarantine and then p=reject when all intended senders are authenticated. This avoids blocking valid mail from overlooked applications or vendors.

Why does SPF pass but DMARC fail?

DMARC requires SPF alignment as well as an SPF pass. If the envelope sender is vendor.example but the visible From address is example.com, SPF can pass for the vendor while remaining unaligned with your brand domain. An aligned DKIM signature can still make DMARC pass. (learn.microsoft.com)

How do I know DKIM is enabled in Microsoft 365?

Send a message from Exchange Online to an external inbox, view the full headers, and look for dkim=pass plus a DKIM signature with your custom domain in the d= value. Also verify that both Microsoft-provided selector CNAME records resolve in public DNS.