SPF, DKIM, and DMARC for Microsoft 365, a step-by-step setup that stops spoofed restaurant emails

If you run a small restaurant group, email is part of the daily rush. Reservation changes, catering quotes, vendor invoices, payroll updates, gift card promos. When a spoofed email slips through, it doesn’t just annoy guests, it can redirect payments, steal logins, and wreck trust.

That’s why I treat DMARC Microsoft 365 setup like putting a tamper seal on your outgoing mail. SPF says who’s allowed to send, DKIM proves the message wasn’t altered, and DMARC tells the world what to do when something doesn’t match.

Why spoofed restaurant emails happen (and why basic filters don’t stop them)

Spoofing is simple: an attacker forges the “From” address to look like your brand. If your domain doesn’t publish strong authentication, many inboxes can’t tell the difference between your real invoice and a fake “updated ACH info” message.

Restaurants are a popular target because teams move fast, turnover is real, and many systems send email on your behalf (online ordering, loyalty, reservation tools). If you want real-world examples of modern phishing patterns, this collection is a good reference: 50 phishing email examples from 2025.

The good news: SPF, DKIM, and DMARC are mostly DNS work plus a few Microsoft 365 clicks. The trick is rolling it out safely so you don’t block legitimate mail.

Before you touch DNS: inventory your senders (this prevents outages)

I start every deployment by listing anything that sends email as your domain:

• Microsoft 365 mailboxes and shared mailboxes
• Reservation and online ordering systems
• Marketing platforms (newsletters, gift cards)
• Payroll, accounting, AP tools
• Website contact forms and SMTP devices

If a vendor sends as @example.com but isn’t covered by SPF or DKIM, DMARC enforcement will eventually punish that mail. This is also where I decide whether a vendor should use a subdomain (like mail.example.com) to keep the main brand domain locked down.

For Microsoft’s official guidance on DMARC flow and configuration, I keep this bookmarked: Use DMARC to validate email, setup steps.

Step 1: Add SPF for Exchange Online (and avoid the common traps)

For a Microsoft 365-only domain, SPF is usually one TXT record at the root of your domain.

In your DNS host (GoDaddy, Cloudflare, Route 53, etc.), create:

• Type: TXT
• Name/Host: @ (or blank, depending on DNS host)
• Value: v=spf1 include:spf.protection.outlook.com -all

That -all is the strict setting. It tells receivers to treat anything not listed as unauthorized.

Two real-world gotchas I see in restaurant groups:

1) You already have an SPF record.
You can only have one. Merge includes, don’t add a second TXT SPF.

2) Too many SPF lookups.
SPF has a 10-DNS-lookup limit. If you stack too many include: mechanisms, SPF can “permerror” and fail even when your send is legit.

If a third-party platform sends mail for you, add its include (example only):
v=spf1 include:spf.protection.outlook.com include:vendor-example.com -all
(Use the vendor’s documented SPF include, not a guess.)

Step 2: Turn on DKIM signing in Microsoft 365 (so mail can’t be “re-written”)

DKIM is the piece that makes your email harder to counterfeit. Microsoft 365 signs outgoing mail, receivers validate it with a public key you publish in DNS.

Where I click to enable DKIM (current Microsoft 365 flow)

1. Go to the Microsoft 365 Defender portal: https://security.microsoft.com
2. Open Email & collaboration
3. Go to Policies & rules
4. Open Threat policies
5. Select DKIM
6. Choose your domain (for example, example.com)
7. Click Enable (Microsoft will prompt you to publish CNAME records first if they’re missing)

Example DKIM DNS records (placeholders)

Microsoft will show your exact targets. Conceptually, you publish two CNAMEs:

• Type: CNAME
  Name/Host: selector1._domainkey.example.com
  Target/Points to: selector1-example-com._domainkey.example.onmicrosoft.com
• Type: CNAME
  Name/Host: selector2._domainkey.example.com
  Target/Points to: selector2-example-com._domainkey.example.onmicrosoft.com

After DNS propagates, go back to the DKIM page and enable it for the domain.

If you want a second reference for the Microsoft 365 record patterns, this guide matches what I typically see in the field: Microsoft 365 SPF and DKIM configuration step by step.

Step 3: Publish DMARC, start with p=none, then enforce safely

DMARC ties your visible “From” domain to authentication results. It also gives you reporting so you can see who is sending as you.

Create this DNS record:

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

What each part means (in plain terms):

• p=none is monitor-only. Nothing gets blocked yet.
• rua= sends aggregate reports (XML) to your mailbox or DMARC tool.
• adkim=r and aspf=r use relaxed alignment, which is kinder during rollout.
• pct=100 applies the policy to all mail, but in monitor mode it’s safe.

Rollout plan I use for restaurant groups

• Days 1 to 14: p=none, collect reports, find vendors using your domain.
• Next step: move to p=quarantine (often with pct=25 first).
• Final step: p=reject once your legit sources consistently pass.

As of December 2025, Microsoft still enforces stricter expectations for high-volume senders (5,000+ emails/day) to Outlook.com consumer inboxes, so getting SPF, DKIM, and DMARC right helps avoid rejections like 550 5.7.15. Even if you’re under that threshold today, most restaurant brands grow into it.

How I test SPF, DKIM, and DMARC (DNS plus real message headers)

I test in two layers: DNS validation and “what the inbox actually saw.”

1) DNS checks

I run a DMARC lookup using MxToolbox DMARC Check Tool. I’m looking for syntax errors and missing records. If the tool can’t find your record, your receivers can’t either.

2) Send a real email and read the headers

Send a message from a real mailbox like reservations@example.com to a Gmail and an Outlook address you control.

Then check headers:

• Outlook desktop: open the message, File, Properties, view Internet headers
• Outlook on the web: open the message, menu, View, View message source
• Exchange admin center message trace (good for delivery issues): https://admin.exchange.microsoft.com, Mail flow, Message trace

In the headers, search for Authentication-Results:. I want to see:

• spf=pass
• dkim=pass
• dmarc=pass

If DMARC fails but SPF or DKIM passes, alignment is usually the issue (often a third-party sender using your domain incorrectly).

Copy/paste templates (edit the placeholders)

Use these as starting points, then adjust for vendors and your report mailbox:

• SPF (Microsoft 365 only): v=spf1 include:spf.protection.outlook.com -all
• DKIM CNAME (selector1 example): selector1._domainkey.example.com CNAME selector1-example-com._domainkey.example.onmicrosoft.com
• DKIM CNAME (selector2 example): selector2._domainkey.example.com CNAME selector2-example-com._domainkey.example.onmicrosoft.com
• DMARC (monitor mode): v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

Small add-ons that make this stick (without turning it into a huge project)

When I deliver this as part of Managed IT for Small Business, I pair email authentication with a few quick wins: enforce MFA, disable legacy auth, and tighten Conditional Access. That supports Business Continuity & Security even when a password gets phished.

This work also fits naturally inside what I already do for restaurant groups: Small Business IT, Cloud Infrastructure, Office 365 Migration, Cloud Management, Secure Cloud Architecture, and Technology Consulting. When email is trustworthy, your Cybersecurity Services, Endpoint Security, and Device Hardening efforts pay off faster, and day-to-day tools like Restaurant POS Support and Kitchen Technology Solutions aren’t stuck cleaning up avoidable incidents. It’s one of those Innovative IT Solutions that’s actually practical, and it supports Infrastructure Optimization, Data Center Technology, Digital Transformation, Tailored Technology Services, and a real IT Strategy for SMBs from a long-term Business Technology Partner.

Conclusion: lock your “From” address before attackers use it again

Spoofing works because the internet needs your domain to “vouch” for email. SPF and DKIM provide the proof, DMARC provides the policy and the visibility. If you roll out slowly, starting with p=none, you can protect the brand without breaking legitimate systems.

If you want the fastest path, I recommend publishing SPF and DKIM first, then letting DMARC reports guide your enforcement. The end goal is simple: guests and vendors can trust your email identity, even on a busy Friday night.