How do I handle spoofing when DMARC reject is set but not enforced on inbound mail server?
Michael Ko
Co-founder & CEO, Suped
Published 4 Jul 2025
Updated 16 Aug 2025
7 min read
It can be frustrating to find that despite having a DMARC record set to p=reject, spoofed emails are still making their way to recipients. This scenario often arises not because your DMARC record is misconfigured on your sending domain, but because the recipient's inbound mail server isn't fully enforcing your stated DMARC policy.
This means your outbound email security measures are strong, yet inbound messages to your own users, or others, from fraudulent senders using your domain are not being blocked as expected. The critical distinction here lies between a domain's published DMARC policy (how you want others to treat your mail) and a receiving server's actual enforcement of that policy (how they interpret and act on it).
DMARC, or Domain-based Message Authentication, Reporting and Conformance, is a protocol that builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide domain owners with a way to tell receiving mail servers how to handle emails that fail authentication. When you set your DMARC policy to p=reject, you are explicitly requesting that receiving servers reject emails that fail DMARC authentication checks for your domain. This is the strongest policy available for preventing email spoofing and phishing attempts using your domain.
However, DMARC is fundamentally a request, not a command. While major providers like Google, Microsoft, and Yahoo generally adhere to DMARC policies, smaller or less sophisticated mail server configurations may not. These servers might still deliver emails that fail DMARC, even when the policy is set to reject, due to a lack of proper DMARC enforcement mechanisms on their end. This is a common reason why spoofed emails can still get through.
The problem isn't necessarily with your DMARC record or its p=reject setting. It's that the receiving mail server, which processes incoming mail for your domain, is not configured to check or act on DMARC policies for inbound emails. Without this inbound enforcement, your DMARC policy cannot protect your own users from spoofing attempts targeting your domain.
Identifying inbound enforcement gaps
To determine if your inbound mail server is failing to enforce DMARC, you need to examine the full email headers of a spoofed message that successfully reached an inbox within your organization. Look for the Authentication-Results header. If it shows dkim=none, spf=none, or no explicit DMARC result, it indicates that the server is not performing these checks, or not reporting them clearly. Even if SPF and DKIM pass, DMARC alignment is also crucial for DMARC to apply its policy.
Example of an email header indicating no SPF/DKIM authentication and neutral DMARC (not enforced)plain
Additionally, paying close attention to the From: header (RFC 5322.From) versus the Return-Path: (envelope-from) can reveal spoofing techniques. Spoofers often use a legitimate-looking From: address while using a different Return-Path address that won't align with your domain's SPF or DKIM. Without inbound DMARC enforcement, the mail server won't link these two addresses to apply your p=reject policy.
The fundamental issue is that DMARC is often seen as a sending domain's tool, not an inbound filter for receivers. While major email providers increasingly enforce DMARC for all incoming mail, many smaller or self-hosted mail servers (like those managed through cPanel or similar systems) might not have DMARC enforcement enabled by default. They rely on other spam filtering mechanisms, which may not specifically target DMARC-failed spoofed emails.
Strategies to address inbound spoofing
If your mail server or provider is not enforcing DMARC on inbound mail, the primary solution is to address it directly with them. You should contact your mail server administrator or hosting provider (e.g., OVH if that's who manages your mail) and specifically ask them to enable or strengthen DMARC inbound checking for your domain. Frame it as a security measure to protect your organization from phishing and spoofing threats.
For self-managed servers, you may need to configure your mail transfer agent (MTA) – like Postfix, Exim, or Sendmail – to include DMARC verification for incoming messages. This typically involves installing and configuring additional modules, such as OpenDMARC, and ensuring they are properly integrated with your mail flow to apply the DMARC policy (reject or quarantine) set by the sender's domain. If your current provider is unwilling or unable to implement this, changing providers to one that offers robust inbound DMARC enforcement should be considered.
While your focus is on inbound enforcement, ensuring your own domain's SPF and DKIM records are correctly configured and aligned is paramount. DMARC relies on these foundational authentication methods. If there are issues with your SPF or DKIM setup, even receiving servers that *do* enforce DMARC might incorrectly reject or quarantine your legitimate outbound emails. Regularly review your DMARC reports for signs of legitimate mail failing authentication, which might indicate a misconfiguration on your end. Review a simple guide to DMARC, SPF, and DKIM for more details.
Why some providers don't enforce DMARC strictly
Mailbox providers, especially smaller ones, sometimes hesitate to fully enforce DMARC policies like p=reject due to the potential for false positives. Legitimate emails, such as those from mailing lists or forwarded messages, often break SPF or DKIM alignment, causing them to fail DMARC. If a provider blindly rejects all DMARC-failed emails, their users might miss important communications, leading to an influx of support requests. This is why many larger providers use a combination of DMARC, ARC (Authenticated Received Chain), and even AI/ML to make nuanced delivery decisions.
The risks of incorrect DMARC deployment
Deploying DMARC policies, particularly p=reject, without thorough testing and monitoring can inadvertently block legitimate email traffic. Organizations have experienced severe disruptions, such as blocked invoices or critical notifications, simply because they moved to p=rejecttoo quickly without understanding their email ecosystem. This complexity contributes to some providers' reluctance to enforce stringent DMARC policies universally.
It's important to distinguish between DMARC's purpose for domain authentication and general spam filtering. DMARC is specifically designed to prevent unauthorized use of your domain for sending emails (spoofing), not to catch all types of spam. Other sophisticated tools and techniques are used for broader spam detection. While DMARC contributes to reducing unwanted emails, it's not a standalone spam filter.
Ensuring comprehensive spoofing protection
Facing email spoofing despite having a DMARC p=reject policy highlights a crucial point: your domain's DMARC settings only control how *other* receiving servers treat your mail. To protect your *own* users from inbound spoofing, your incoming mail server must actively check and enforce DMARC policies of the sending domains.
The solution typically involves contacting your mail server provider or configuring your own server to enable DMARC validation for inbound mail. While DMARC is gaining widespread adoption, it's not universally enforced by all receiving mail servers due to various factors, including complexity and the risk of blocking legitimate mail. Proactive monitoring of DMARC reports and direct communication with your provider are your best tools to ensure comprehensive protection against spoofing.
Views from the trenches
Best practices
Actively monitor your DMARC aggregate reports to identify legitimate sending sources and spot any unauthorized use of your domain. This data is critical for safe DMARC policy progression.
Work closely with your inbound mail server provider or administrator to ensure they have DMARC checking enabled and configured for incoming messages.
Prioritize a gradual DMARC rollout, starting with p=none, then p=quarantine, and finally p=reject, to avoid disrupting legitimate email flows.
For larger organizations, implement ARC (Authenticated Received Chain) to ensure forwarded emails maintain their authentication status.
Regularly verify the authenticity of email senders in your organization via SPF and DKIM authentication to ensure DMARC alignment.
Common pitfalls
Assuming all mail servers worldwide automatically enforce DMARC p=reject policies, leading to a false sense of security.
Overlooking the distinction between the Return-Path (envelope-from) and the From (RFC 5322.From) headers, which spoofers often manipulate.
Not monitoring DMARC aggregate reports, missing crucial insights into email authentication failures and potential spoofing attempts.
Failing to configure inbound DMARC enforcement on your own mail server, leaving internal users vulnerable to domain impersonation.
Implementing DMARC p=reject too quickly without thorough testing, risking the blocking of legitimate, but unaligned, email.
Expert tips
DMARC is not a spam filter, it's a domain authentication protocol to prevent impersonation, focusing on identity verification.
Some providers may have a client-controlled switch to enable or disable DMARC checks, often to reduce support requests from false positives.
Large mailbox providers like Google, Yahoo, and Microsoft globally check DMARC, often using ARC and AI/ML for nuanced decisions.
A DMARC policy is a request, not a command, meaning not all receiving servers are obligated to strictly enforce it, especially smaller ones.
Incorrectly deployed DMARC can cause legitimate emails from mailing lists or forwarded messages to fail authentication and be blocked.
Expert view
Expert from Email Geeks says DMARC is an experimental emerging internet standard which is optional to use, and not every provider deploys it properly or at all.
2022-03-22 - Email Geeks
Marketer view
Marketer from Email Geeks says that if your provider does not enforce DMARC, you should ask them to do so, or consider changing providers.
