Defender for Office 365 is one of the more underrated components of the Microsoft security stack. Configured well, it catches phishing, impersonation, malicious attachments, and adversary-in-the-middle attempts that would have landed in user inboxes a decade ago. We have written about its newer capabilities, including post-delivery protection and AI-assisted detection, in our post on the newest Microsoft 365 security features.
But Defender for Office 365 processes the email that arrives at your tenant. It does not decide whether that email should have been delivered in the first place. That decision is made at the DNS layer, by three records that almost no SMB tenant we audit has configured correctly: SPF, DKIM, and DMARC.
When these records are weak or misconfigured, Defender for Office 365 is working with information it cannot fully trust. The sender authentication signals it relies on for impersonation detection are degraded. The MSP delivered the email security product. The DNS records that make the email security product effective were never finished.
This post is about the DNS work most MSP engagements skip, what it actually does, and why a Defender for Office 365 license without correctly configured SPF, DKIM, and DMARC is a substantial fraction of what you paid for.
What SPF, DKIM, and DMARC actually do
These three records work together. They are often discussed individually, but the protection only emerges when all three are deployed and aligned. The short version:
SPF (Sender Policy Framework) publishes, in your DNS, the list of mail servers authorized to send email on behalf of your domain. When a receiving server gets an email claiming to come from yourdomain.com, it checks whether the sending server's IP appears in your SPF record. If not, the email is suspicious.
DKIM (DomainKeys Identified Mail) cryptographically signs outbound email from your domain. The receiving server retrieves your public key from DNS and validates the signature. If the signature is valid, the receiver knows the email was sent by someone with access to your private key, and that the message body has not been altered in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails SPF and DKIM checks (do nothing, quarantine, or reject), and where to send reports about authentication failures. Without DMARC, SPF and DKIM are advisory. With DMARC, they become enforceable.
What we typically find in SMB tenants
When we audit email authentication posture during a Reality Check, the patterns are remarkably consistent. The findings below appeared in roughly 7 out of 10 tenants we reviewed in the past 18 months:
SPF: too many DNS lookups or never updated for new services. SPF has a hard limit of 10 DNS lookups per record. Tenants that have added Mailchimp, SendGrid, HubSpot, Zendesk, Stripe, and a marketing automation platform routinely exceed this limit. When the limit is exceeded, SPF returns a "permerror" result, which DMARC then treats as a failure. The legitimate marketing emails the company is sending start failing authentication, and the tenant either backs off SPF enforcement or accepts the deliverability loss.
The fix is SPF flattening or restructuring (consolidating includes, removing unused services), not just adding more include statements. Most MSPs add includes when asked and never come back to clean up.
DKIM: enabled for Microsoft 365 but not for third-party senders. Microsoft 365 ships with DKIM that can be enabled in a few clicks (it is off by default for new tenants). Most MSPs enable it. The third-party services sending email on behalf of the domain (transactional email providers, CRM platforms, support ticketing systems) almost never have DKIM correctly configured by those MSPs. The result: emails from yourdomain.com via SendGrid pass SPF but have no DKIM signature, and DMARC alignment breaks.
DMARC: stuck at p=none for years. DMARC has three policy levels: none (monitor only), quarantine (send failing email to spam), and reject (do not deliver failing email at all). The correct deployment path is none → quarantine → reject, with each step validated using DMARC aggregate reports before progressing.
In our audits, roughly 80% of tenants with DMARC published have it stuck at p=none. The policy has been in monitor mode for 18 months, two years, or longer. Nobody has reviewed the aggregate reports. The protection it should be providing (rejection of spoofed email) is theoretical because the policy never moved to enforcement.
DMARC reports never collected. When DMARC is set up correctly, it sends daily aggregate reports to a designated mailbox. These reports show which mail streams are authenticating, which are failing, and where unauthorized senders are spoofing your domain. The mailbox usually exists. The reports usually arrive. Nobody usually reads them, because they are dense XML files that require a parsing tool to be interpretable.
Why this matters even with Defender for Office 365 active
A reasonable question at this point: if Defender for Office 365 is doing impersonation detection, anti-phishing, and Safe Links, does the DNS authentication really matter?
Yes, for three specific reasons:
1. Inbound: DMARC reject blocks spoofed email before Defender sees it. When an attacker spoofs yourdomain.com to phish your own employees (the "CEO sending wire transfer instruction" scenario), DMARC with p=reject causes the receiving mail server (which is often Microsoft itself for your tenant) to refuse delivery outright. Defender for Office 365 anti-spoofing also catches many of these, but DMARC enforcement closes the door at the protocol level rather than at the content-scanning level. It is a lower layer of defense that fails closed.
2. Outbound: your domain's reputation depends on authentication. Major receivers (Gmail, Yahoo, Microsoft itself, Apple Mail, large corporate gateways) now enforce SPF, DKIM, and DMARC for bulk senders. Gmail and Yahoo both implemented stricter sender requirements in 2024. Domains without proper authentication are increasingly silently filtered to spam folders at the receiver, regardless of content. Your legitimate emails to clients land in junk because your authentication looks weak.
3. Reputation defense against domain abuse. Without DMARC, attackers can spoof your domain to phish your customers, partners, or the broader internet. Those attacks may never touch your tenant directly, but they do attach themselves to your domain's reputation. DMARC reports surface this activity. DMARC enforcement stops it.
The realistic deployment sequence
The mistake we see most often is jumping to DMARC enforcement before SPF and DKIM are clean. This breaks legitimate email and forces a rollback that destroys trust in the project.
The sequence that works:
Phase 1: Inventory and remediation (weeks 1-4). Identify every service sending email on behalf of the domain. Document the SPF includes needed. Flatten SPF if necessary. Enable DKIM for Microsoft 365. Configure DKIM for each third-party sender that supports it (most major platforms do). Validate using MXToolbox, dmarcian, or similar.
Phase 2: DMARC in monitor mode (weeks 5-8). Publish DMARC with p=none and configure aggregate reports to a parsable mailbox. Use a DMARC analysis tool (Dmarcian, EasyDMARC, Valimail, Microsoft 365's own Email Authentication Insights, or a custom parser) to interpret the daily reports. Identify any legitimate mail streams still failing authentication and fix them.
Phase 3: DMARC at p=quarantine (weeks 9-12). Move the policy to quarantine for a subdomain first if possible, then for the apex domain. Aggregate reports continue. Any newly broken streams are remediated.
Phase 4: DMARC at p=reject (week 13 onward). Final policy state. Spoofed email is now blocked at the protocol level. Aggregate reports continue indefinitely as part of operational hygiene, not as a project deliverable.
For most SMBs, this sequence takes 3-4 months end-to-end. Rushing it produces deliverability incidents. Skipping the DMARC reports phase produces a deployment that breaks email in production without anyone understanding why.
The connection to broader identity protection
Email authentication sits in the same domain as the identity-layer attacks we wrote about in our posts on token theft and why MFA alone is not enough and the Conditional Access mistakes that leave your tenant exposed. The phishing email that captures the session token has to land in the inbox first. SPF, DKIM, and DMARC are the first-mile defense that determines whether it arrives or not. Without them, the rest of the identity protection stack is doing remedial work on emails that should never have been delivered.
This is also why we treat email authentication as part of identity and email protection rather than as a separate "deliverability" concern. The DNS records and the Conditional Access policies are different layers of the same attack chain.
What does correct configuration cost
The license cost is zero. SPF, DKIM, and DMARC are DNS records that any domain owner can publish for free. The DMARC reporting tools have a free tier sufficient for most SMBs (Dmarcian Personal, Valimail Monitor, MXToolbox free DMARC monitoring) or low-cost paid tiers under $50 per month.
The cost is the labor: the inventory of sending services, the remediation of third-party senders, the DMARC report interpretation, and the project management to walk from p=none to p=reject without breaking production. For a typical SMB, the total engagement runs 30-60 hours of expert work spread across 3-4 months. The cost is meaningfully lower than most other security improvements with comparable impact.
How NeoDefender helps
Our Email Protection service treats SPF, DKIM, and DMARC as foundational work that gets completed before more advanced email security configurations are layered on top. Defender for Office 365 tuning is more effective when the authentication layer is clean. The deliverability conversation with marketing is easier when the domain reputation is solid. The phishing defense is materially stronger when spoofed email is blocked at the protocol level.
If your tenant has Defender for Office 365 deployed and you are not certain whether your SPF, DKIM, and DMARC are configured correctly, schedule a Reality Check with the NeoDefender team. We will pull your current records, run them through analysis, and tell you honestly whether your foundation is solid or whether the email security product you are paying for is operating at half capacity.
