DMARC

The Inbound Authentication Paradox: Why Clients Who Enforce DMARC Still Accept Mail From Domains That Don't

October 13, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

A client calls to say they finally reached p=reject on their DMARC record. The MSP updates the ticket, closes the project, and everyone moves on feeling good about the win. Three weeks later the same client forwards a phishing email that spoofed a vendor's domain, a vendor whose DMARC record, if it exists at all, sits at p=none. The client's reaction is predictable: didn't we just fix this?

This is the inbound authentication paradox. A domain can enforce DMARC perfectly on its own outbound mail and still accept spoofed, unauthenticated mail into its own inboxes all day long, because those are two entirely separate control surfaces that happen to share a protocol name.

What Does Publishing a DMARC Policy Actually Control?

A DMARC record only tells other mail servers what to do with messages claiming to come from your domain. It says nothing about how your own mail server evaluates incoming messages that claim to come from someone else's domain, which is a completely separate decision made by your receiving infrastructure.

The specification is explicit about this asymmetry. RFC 7489 states plainly that mail receivers "MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a 'reject' policy." The policy is a request, not an enforceable contract, and the receiving side retains full discretion over what actually happens to a failing message.

That discretion matters more than most DMARC rollout checklists admit. A client's own p=reject record governs what Gmail, Yahoo, or any other receiver does with spoofed mail impersonating that client's domain. It has zero bearing on what that client's own Microsoft 365 or Google Workspace tenant does with spoofed mail arriving from somebody else's domain. Those are configured, and often left unconfigured, independently.

Why Does Enforced DMARC Still Let Spoofed Mail Through?

The short answer is that major mailbox providers do not reject failing mail by default just because a sender's DNS record says to. Microsoft 365, for instance, ships with a setting that has to be deliberately turned on before incoming DMARC failures are actually rejected or quarantined rather than merely tagged and delivered.

Microsoft's own documentation describes this as the Honor DMARC policy setting inside anti-phishing policies, which determines "whether p=quarantine or p=reject values in sender DMARC policies are honored" and lets administrators pick separate actions for each outcome, according to Microsoft Learn's anti-phishing policy guidance. If that toggle is off, or if spoof intelligence settings override it, a message can fail DMARC outright and still land in the inbox with no visible warning to the recipient.

Microsoft's configuration documentation reinforces the same point from the sending side: what actually happens to a message that fails DMARC "depends on the destination email system," and even p=reject messages are only "typically discarded" rather than guaranteed to be, per Microsoft's DMARC configuration guide. Two different tenants can receive the same spoofed message and produce two different outcomes depending entirely on how the receiving admin configured inbound handling, independent of anything the sending domain published.

This creates the exact blind spot MSPs need to close for clients. An MSP can spend a quarter getting a client's outbound SPF, DKIM, and DMARC alignment to p=reject, hand over a report showing 100% enforcement, and leave the client's inbound mail flow exactly as exposed as it was before the project started.

The Scale of the Gap on the Sending Side

Even if inbound handling were perfectly strict everywhere, the paradox would still bite, because most of the domains a client's employees exchange mail with every day have not reached enforcement themselves. Red Sift's analysis of 73.3 million domains found that only 14.9% had published any DMARC policy at all as of December 2025, and that a mere 2.5% had reached the enforcing p=reject level, according to Red Sift's global DMARC adoption guide. The remaining 83.9% of analyzed domains had no visible DMARC record whatsoever.

Large enterprises look considerably better, but the mid-market tells a different story. EasyDMARC's 2026 adoption report found Fortune 500 adoption reached 475 of 500 companies, with more than 80% at enforcement-level policies, according to EasyDMARC's 2026 DMARC Adoption and Enforcement Report. Most of an MSP's client base, however, is transacting with smaller vendors, suppliers, and partners who look nothing like a Fortune 500 sender.

Put those two facts together and the paradox resolves into something simpler: a client's own enforcement is necessary but nowhere near sufficient. Even a perfectly configured outbound record cannot protect a client from the vast majority of domains they correspond with, because those domains have no enforced policy for the client's mail server to honor in the first place.

Google's own guidance reflects the same gap from the receiving side. Google requires DMARC only for bulk senders exceeding roughly 5,000 messages a day, and even then the minimum bar is publishing a record at p=none, which per Google's email sender guidelines tells receiving servers what to do with failing messages but imposes no enforcement floor at all. A small vendor sending invoices to a client twice a week is under no obligation to publish anything stronger than a monitoring-only record, if they publish one at all.

What MSPs Should Actually Be Checking

Closing the inbound side of this gap requires looking past the client's own DNS records entirely. A few checks matter more than the outbound scorecard most tools default to:

• Whether the client's mail platform actually honors inbound DMARC failures (quarantine or reject), not just whether the setting exists
• Whether spoof intelligence, allow lists, or transport rules are silently overriding that setting for specific senders
• Whether the client's reporting (RUA) data is being reviewed for patterns, not just collected

None of this shows up in a scan that only checks whether a domain's own DMARC record resolves. An MSP that wants to speak credibly to a client about actual risk needs visibility into both directions of the mail flow, and that is the gap ActiScan's scanning was built to surface rather than assume away. Technicians working through the platform's getting-started guide configure checks for both the outbound posture clients control and the inbound handling settings that determine whether enforcement from other domains is actually acted on.

The pricing conversation with clients gets easier once this distinction is explained plainly: enforcing your own DMARC protects your brand from being spoofed elsewhere, while inbound configuration protects your inbox from everyone else's unenforced domains. Both are worth paying for, but they are not the same line item, and MSPs who bundle them without explaining the difference tend to get the uncomfortable phone call described at the top of this post. Teams that want a structured way to track both sides across a client book can review the tiers on the pricing page before scoping the work.

The Honest Takeaway

DMARC enforcement is a real and measurable improvement, and clients who reach p=reject have genuinely reduced the odds of their own domain being weaponized against customers and partners. That fact should not be confused with inbox safety, which depends on a different set of settings that most DMARC projects never touch.

The paradox is not a flaw in the protocol. RFC 7489 was explicit from the start that receivers retain discretion, and the specification never promised inbound protection as a side effect of outbound compliance. The flaw is in how the industry talks about DMARC projects, treating a single DNS record change as if it closed a loop that was never designed to close itself.

MSPs who want to get ahead of this should treat inbound handling as its own deliverable, with its own checklist and its own client conversation, rather than an assumed bonus of outbound enforcement work. Accounts that have not yet had this conversation can start by running a baseline scan, available directly from the signup page, to see exactly where the outbound and inbound postures currently diverge.