Email DMARC Failure

Definition

DMARC failure occurs when an email claiming to be from your domain fails both SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication checks, or fails identifier alignment (the authenticated domain does not match the visible From domain). When a receiving server evaluates DMARC, it checks: does SPF pass with alignment? Does DKIM pass with alignment? If neither returns a pass, the message fails DMARC authentication and the receiving server applies the policy specified in your DMARC record.

The DMARC policy determines what happens to failing messages. There are three policy levels: p=none instructs the receiving server to take no action against the message (deliver it normally) but report the failure via DMARC aggregate reports. p=quarantine instructs the receiving server to treat the message with suspicion, typically delivering it to the spam folder. p=reject instructs the receiving server to reject the message entirely, preventing delivery. The reject response can be a permanent failure (5xx SMTP code) or a temporary failure depending on the receiving server's implementation.

Gradual policy escalation is the recommended deployment approach. Start with p=none for 2-4 weeks while collecting DMARC reports to understand all legitimate sending sources. Then move to p=quarantine for 2-4 weeks to observe how spam placement affects deliverability. Finally move to p=reject once you have confirmed all legitimate senders are properly authenticated. This gradual escalation minimises the risk of false positives: messages that fail DMARC but are legitimate. Subdomain policies (sp=) can be set independently to test policy enforcement on a subset of traffic before domain-wide enforcement.

Best Practices

Begin with p=none and monitor for at least 30 days before escalating to quarantine. The initial monitoring period reveals your complete email sending ecosystem. Many organisations discover legitimate senders they did not know about during this phase, including marketing automation platforms, CRM systems, support desk tools, and partner programs. Document all senders, ensure they are properly authenticated, and only escalate after all identified senders are confirmed.

Use subdomain-level DMARC policies (sp=) for testing before domain-level enforcement. Configure a more restrictive policy on a specific subdomain first (e.g., p=reject on test.example.com) while keeping the primary domain at p=none. This allows you to understand the impact of enforcement on a controlled traffic stream before applying it to your primary email domain.

Create a DMARC false-positive response plan before moving to p=reject. Despite best efforts, some legitimate email may fail DMARC after enforcement begins. Have a plan for: detecting false positives quickly (via DMARC reports and user reports), identifying the root cause (SPF misconfiguration, DKIM signing issue, alignment problem), and remediating the issue. Communicate the plan to affected business units before enforcement.

Monitor DMARC failure reports for signs of active spoofing or phishing campaigns. A sudden surge in DMARC failures from unrecognised IPs or geographic locations may indicate someone is spoofing your domain for phishing attacks. When detected: review the failed messages in DMARC reports (and forensic reports if configured), notify your security team, and consider taking legal action against the spoofing domain via WHOIS abuse contacts.

Align subdomain policies with your organisational structure. If different departments or brands within your organisation manage their own email sending, consider using subdomain DMARC policies that match their operational autonomy. Each subdomain can progress through the policy escalation independently. This prevents a single department's authentication issues from blocking email for the entire organisation.