Microsoft 365 email is spoofable out of the box. Here is how to close the three gaps.

TL;DR. Microsoft 365 ships with three email-authentication gaps that let anyone spoof your domain. DKIM is off until you toggle it in the Defender portal, DMARC is absent, and the recommended SPF of -all often gets softened to ~all during rollout. Closing all three takes about 30 minutes of admin work plus a 12-week DMARC rollout. Cross-references to the full Academy guides for SPF, DKIM, and DMARC are linked in each section. If you run Google Workspace instead, that post covers the same three gaps with Google-specific clicks.

You bought Microsoft 365, pointed your MX at Exchange Online, and started sending mail. Done? Almost. The default setup protects Microsoft's reputation more than your domain's. Anyone on the internet can still send mail claiming to be from you@yourcompany.com, and most receivers will deliver it. Possibly to Junk, possibly straight to the inbox.

This post walks through the three records Microsoft 365 doesn't fix for you, what each one actually does, and the clicks in the Defender portal that lock them down. Total time: about 30 minutes. Prerequisite: you're a Microsoft 365 global admin (or Security admin with Defender access) and you can edit DNS records at your registrar.

What Microsoft 365 email security misses by default

When you connect a custom domain to Microsoft 365, the setup wizard asks you to publish an MX record (so Exchange Online can receive mail for you), an SPF include (so Microsoft's servers can send as you), an autodiscover CNAME, and a couple of service-specific records. It does not enable DKIM, does not publish DMARC, and the SPF it suggests depends on which wizard flow you used.

Concretely, after a default tenant setup, your domain typically looks like this:

None of these are bugs in Microsoft's setup. They're cautious defaults. -all is the strict recommendation but you have to keep it strict once marketing adds Mailchimp. DKIM off means "the admin can flip this on once they've published the CNAMEs." DMARC absent means "this is your call." Reasonable for Microsoft. Wrong for any production domain.

Fix 1: Keep Microsoft 365 SPF at strict fail

SPF (Sender Policy Framework) tells receivers which servers can send email as your domain. Microsoft publishes their fragment via include:spf.protection.outlook.com; you control the closing rule. -all says "reject anything that didn't match." ~all says "soft fail" so receivers usually quarantine but may still deliver. Strict is the goal.

Before locking it down, list every other service that sends mail as your domain (Mailchimp, Postmark, SendGrid, Customer.io, your invoicing tool, your support desk). Each one publishes its own SPF fragment. You merge them into a single record:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org -all

Publish this as a single TXT record at the root of your domain, replacing the Microsoft-suggested one. Do not publish two SPF records. Receivers see permerror and treat your domain as unauthenticated. Merge into one.

For the full mechanic (the 10-lookup ceiling, soft-fail versus strict-fail outcomes, how to spot a bloated record), see the SPF guide in the Academy. Microsoft's canonical reference is Set up SPF to identify valid email sources for your Microsoft 365 domain.

Fix 2: Enable DKIM in the Microsoft 365 Defender portal

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing email. Receivers fetch your public key from DNS, re-hash the message, and verify. Tampering breaks the signature; forgery never produces one in the first place. It's free, it works on every modern receiver, and Microsoft has it ready behind a couple of DNS records and one toggle.

Microsoft 365 uses two selectors (selector1 and selector2) so it can rotate signing keys on a schedule. You publish both CNAMEs up front; Microsoft signs with one at a time and swaps silently. If you only publish one, rotation breaks.

The path:

1. Open the Microsoft 365 Defender portal at security.microsoft.com
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM
3. Select your custom domain. The portal shows the two CNAME target values you need to publish. Always copy the values shown in the portal; don't guess the shape.

For new custom domains added from May 2025 onwards, the CNAME target uses the current format:

selector1._domainkey.yourdomain.com   CNAME   selector1-yourdomain-com._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft
selector2._domainkey.yourdomain.com   CNAME   selector2-yourdomain-com._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft

Where <tenant> is your onmicrosoft.com prefix and <char> is a single character (for example n or r) that Microsoft assigns automatically and you cannot change. Existing domains that enrolled before May 2025 keep the older format:

selector1-yourdomain-com._domainkey.<tenant>.onmicrosoft.com
selector2-yourdomain-com._domainkey.<tenant>.onmicrosoft.com

Don't mix the two formats for the same domain. Publish both CNAMEs in your DNS, wait for propagation (usually a few minutes), then flip the toggle "Sign messages for this domain with DKIM signatures" to On. The portal validates the records before it lets you enable.

Verify in a test email's headers. You should see DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1; … (or s=selector2 once the active key rotates). If you have other senders (Postmark, SendGrid, Mailchimp), each one needs its own DKIM key published under a different selector. The DKIM guide covers selector hunting and what each signature tag means. Microsoft's canonical reference, including the key rotation schedule and Exchange Online PowerShell cmdlets, is How to use DKIM for email in your custom domain.

Fix 3: Publish DMARC and ramp from monitor to reject

SPF says who can send. DKIM proves what was sent. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when either fails. Without DMARC, receivers run those checks and throw the result away. Your strict SPF and signed DKIM accomplish nothing for inbound spoof protection on your domain.

Don't jump to p=reject. Walk it up over a few weeks while you watch reports for legitimate senders you missed:

1. Week 1 to 4: observe. Publish at _dmarc.yourdomain.com:

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

   p=none changes nothing about delivery. The rua= address gets daily aggregate reports listing every IP that sent mail claiming to be you. Read them. Find every legitimate sender, make sure each is covered by SPF or DKIM.
2. Week 5 to 8: soft enforce. Move to p=quarantine; pct=10. 10% of failing mail gets quarantined; the rest is monitored. Low blast radius.
3. Week 9 to 12: ramp. Raise pct through 50, then 100. Reports should be quiet by the end.
4. Week 13 onward: lock. Switch to p=reject; sp=reject. Subdomains inherit. Done.

The DMARC guide has the full rollout chart, the alignment story (strict versus relaxed), and what each tag means. Microsoft's canonical walkthrough is Use DMARC to validate email, setup steps, which also covers how Microsoft 365 applies DMARC to inbound mail.

The 30-minute Microsoft 365 email security checklist

If you don't have time for a 12-week DMARC rollout right now and want immediate improvement:

1. Confirm SPF ends in -all and covers every sender (5 min)
2. Publish the two DKIM CNAMEs and flip the Defender toggle (10 min including DNS propagation)
3. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (2 min)

That's the immediate stop-the-bleeding move. SPF blocks unauthorised senders, DKIM proves outbound authenticity, and the DMARC reports give you the data to safely tighten to p=reject over the following weeks.

Beyond email: other Microsoft 365 defaults to harden

Email auth is the loudest gap, but Microsoft 365 ships with other defaults worth a look:

• Security Defaults off on older tenants. Tenants created before October 22, 2019 (or migrated from legacy SKUs) do not have Security Defaults enabled. Turn it on in the Microsoft Entra admin center under Entra ID → Overview → Properties → Manage security defaults, or replace it with Conditional Access if you are on Entra ID P1 or above.
• MFA not enforced. Without Security Defaults or Conditional Access, MFA is opt-in per user. Enforce it for all users, with an emergency break-glass account (two is Microsoft's recommendation) excluded.
• Conditional Access not configured. Sign-ins are allowed from any location and any device. Tighten via Microsoft Entra Conditional Access. Start with "block legacy auth" and "require MFA for admins."
• Safe Links and Safe Attachments defaults vary. Defender for Office 365 Plan 1 or 2 ships with a Built-in protection preset that covers all recipients by default, but custom policies are off until you create them. Review Safe Links and Safe Attachments in the Defender portal under Threat policies.
• Anti-phishing policy is generic. The default anti-phishing policy exists but does not know your executives' display names. Add high-value users to the impersonation list so spoofed-from-the-CEO mail is caught.

Future posts will dig into each of those. Email auth first because the consequences of doing nothing are most visible: phishers spoofing your domain to your customers, your support desk, your finance team.

Frequently asked questions

Want to know where you currently stand? Scan your domain. Sudory checks SPF, DKIM, DMARC, and 17 other DNS or HTTP controls in one pass. No login, no setup, about 3 seconds.