How do I handle spoofing when DMARC reject is set but not enforced on inbound mail server?

Key findings

• Inbound enforcement: Your DMARC reject policy is a request, and receiving mail servers (including your own for inbound mail) must be configured to honor it. If they are not, spoofed emails can bypass your policy.
• Header analysis: Mail headers provide critical clues. The absence of SPF or DKIM authentication results, or a DMARC authentication status of 'none' or 'neutral' for a spoofed message that should have failed, indicates a lack of inbound enforcement by the recipient server.
• DMARC reports: DMARC aggregate reports (RUA) are essential. They detail how receiving mail servers processed your emails, including disposition statuses (reject, quarantine, none), helping to identify if your policies are being honored. For more information, read our guide on understanding DMARC reports.
• Mailbox provider variability: Major providers like Gmail, Yahoo, and Microsoft generally enforce DMARC, often using additional protocols like ARC or AI/ML to mitigate false positives. Smaller or local providers may not have the technology or choose not to enforce DMARC to avoid false positives. This variability affects email deliverability. Read more about why email providers might not honor a DMARC policy.

Key considerations

• Local enforcement: Ensure your own inbound mail server is configured to check and enforce DMARC for your domain. This prevents spoofed emails appearing to be from your domain from reaching your internal users.
• Contact your provider: If your email provider (like OVH in the provided scenario) is not enforcing DMARC on inbound mail, you need to contact their support and request them to enable it for your domain. Alternatively, consider migrating to a provider that offers robust DMARC enforcement.
• Phishing URLs: If you have phishing URLs from spoofed emails, report them to relevant security organizations or blocklist providers. This helps in wider mitigation efforts against bad actors.
• DMARC's purpose: Remember that DMARC is primarily an anti-spoofing and authentication protocol, not a general spam filter. While it helps reduce unwanted mail by preventing impersonation, it's not a standalone solution for all spam. For further reading, explore Mailgun's DMARC explanation.

Key opinions

• Unexpected spoofing: Many marketers are surprised when spoofed emails bypass their DMARC reject policy, especially when the spoof is from a separate domain using their 'friendly from' address.
• Phishing concerns: The primary concern is often internal users receiving phishing emails that appear to be from their own domain, posing a significant security risk.
• DMARC data limitations: There can be a delay in DMARC monitoring data, making it difficult to immediately ascertain the effectiveness of a newly implemented or updated policy.
• Distinguishing attacks: It can be challenging to differentiate between direct spoofing and replay attacks without a complete set of email headers for analysis.

Key considerations

• Verifying DMARC enforcement: It's crucial to confirm if the recipient's mail server is actually checking for DMARC. The absence of SPF/DKIM authentication in headers, or specific 'authentication-results' fields, can indicate a lack of enforcement, which is a key part of how to identify and handle spoofed emails.
• Recipient-side configuration: The issue often lies with the incoming mail server for the recipient's domain not checking DMARC. This is a configuration setting on their end, not a flaw in the sender's DMARC record. For insights into resolving DMARC errors, consider Kinsta's guide on DMARC fail errors.
• Proactive communication: If a specific recipient's mail provider (e.g., OVH) is not enforcing DMARC, direct communication with their support is necessary. It's about requesting them to enable DMARC checking for the domain.
• Domain vs. subdomain policies: Be aware that a DMARC policy with sp=none will only enforce DMARC on the main domain, not subdomains. If spoofing occurs on subdomains, ensure your policy covers them or configure DMARC for multiple domains.

Key opinions

• Optional standard: DMARC is an experimental and optional internet standard; not all providers deploy it, or they may do so incorrectly, leading to gaps in enforcement.
• Inbound enforcement gap: The problem often lies with the incoming mail server for the recipient's domain not actively checking for or enforcing DMARC policies.
• False positives: Many smaller mailbox providers avoid strict DMARC enforcement due to the potential for generating numerous false positives, which would block legitimate emails (e.g., mailing lists) that cannot pass DMARC.
• Advanced enforcement: Major providers like Google, Yahoo, and Microsoft globally check DMARC, often complementing it with ARC (Authenticated Received Chain) and AI/ML to deduce whether to honor a DMARC policy, thereby reducing false positives.
• Policy vs. request: Publishing a DMARC policy is essentially making a request; there's nothing in the standard that mandates receivers to respect it fully. This highlights the importance of how to safely implement DMARC p=reject.

Key considerations

• Inbound server configuration: Administrators for a domain must configure their own inbound mail servers to check for DMARC policies. This is a crucial step to protect internal users from spoofing attempts targeting their own domain. Explore Practical365's insights on DMARC policy changes.
• Provider advocacy: If your mailbox provider does not enforce DMARC, advocate for its implementation or consider changing providers to one that offers robust security measures.
• Staged rollout: Avoid simply 'cutting and pasting' DMARC records to a reject policy without proper monitoring and understanding. Incorrect deployment can break legitimate email flows. Learn how to safely transition DMARC policy.
• Reputation factor: While global providers use DMARC, they also weigh it as one of many data points for reputation and delivery decisions, so policy enforcement might not be absolute.

Key findings

• Anti-spoofing focus: DMARC is fundamentally an anti-spoofing tool, not a general spam filter, designed to give domain owners control over unauthenticated messages using their domain.
• Policy options: DMARC offers three main policy options: p=none (monitoring), p=quarantine (move to spam/junk), and p=reject (block entirely), with p=reject being the strictest for maximum protection. For more, see our guide on DMARC best practices.
• Receiver responsibility: The sender's DMARC policy informs the recipient's mail server on how to handle unauthenticated messages, but it is ultimately up to the receiver to implement and enforce these policies.
• Gradual enforcement: Documentation often recommends a phased approach to DMARC enforcement, starting with p=none to monitor impacts before moving to quarantine or reject. See our guide on DMARC, SPF, and DKIM.

Key considerations

• Compliance variations: Different mail providers have varying levels of DMARC compliance and enforcement. Some may fully honor the policy, while others may treat a reject policy as a quarantine (or even none) based on their internal algorithms and reputation scores. Find out more about DuoCircle's DMARC enforcement rules.
• Header interpretation: Understanding email headers, particularly the Authentication-Results and Received-SPF fields, is crucial for diagnosing whether a recipient mail server is performing DMARC checks.
• Local network protection: For your own organization, implementing DMARC checking on your inbound mail server is paramount to protect your employees from internal spoofing or phishing attempts that use your domain.
• Forwarded emails: Be aware that DMARC policies can impact forwarded emails due to changes in authentication paths, which is why ARC was developed. This is especially important for handling DMARC failures with forwarded emails.