DMARC Enforcement: Getting from p=none to p=reject Without Breaking Email

The DMARC specification defines three policy levels: none, quarantine, and reject. At p=none, receiving mail servers check incoming mail against the DMARC record, record the result, and deliver the message regardless of whether it passes or fails. A spoofed email from an attacker claiming to be from your domain arrives in the recipient's inbox as if it were legitimate, because the receiving server's DMARC check is in reporting-only mode. The only thing p=none provides is aggregate reports that tell you about spoofing attempts; it does nothing to stop them.

This is a widespread misunderstanding. Many organizations receive compliance audit findings addressed by deploying DMARC, deploy a DNS record at p=none, and report to their auditors that DMARC is implemented. Technically, this is accurate. Practically, it is meaningless from a spoofing protection standpoint. Auditors who accept p=none as evidence of email spoofing protection are not evaluating the control correctly. The relevant question is whether the DMARC policy is enforced (p=quarantine or p=reject), not merely whether a DMARC record exists.

At p=quarantine, receiving servers deliver failing messages to the spam folder. This provides partial protection: recipients may still see and act on spoofed emails, but the spam folder placement creates a signal that many users and security tools use as an indicator of untrustworthiness. At p=reject, receiving servers drop messages that fail DMARC checks. The spoofed email is never delivered. This is the objective.

The practical reason organizations stay at p=none is that moving to enforcement requires confidence that all legitimate mail streams will pass DMARC alignment. Most organizations have more legitimate email streams than they know about, and discovering them requires methodical analysis of DMARC aggregate reports. This analysis takes time, but it is finite work with a clear end state. The organizations that have been at p=none for two or more years have not been unable to move to enforcement; they have been unwilling to invest the analysis effort.

Sender Policy Framework (SPF) works by publishing a DNS TXT record at the sending domain that lists the mail servers authorized to send email as that domain. When a receiving server gets a message, it looks up the SPF record for the domain in the envelope From (MAIL FROM) field and checks whether the sending server's IP address is in the authorized list. If it is, SPF passes; if not, SPF fails.

The SPF record syntax uses mechanisms to specify authorized senders: a for the domain's own A/AAAA records, mx for the domain's MX records, ip4 and ip6 for explicit IP ranges, and include to reference another domain's SPF record. SaaS email service providers (Salesforce, Mailchimp, Zendesk, ServiceNow) all provide SPF include directives to add to your record. Each include mechanism triggers a DNS lookup when the SPF record is evaluated.

SPF has a hard limit of 10 DNS lookups per evaluation. Each include mechanism counts as one lookup, and any lookups triggered within included records count toward the same total. An organization that has added SPF includes for many SaaS providers over the years frequently exceeds this limit, causing SPF to return PermError rather than a pass or fail result. A PermError from SPF counts as a failure for DMARC purposes, which means a PermError can cause legitimate mail to fail DMARC even when it was sent from an authorized server.

Diagnosing SPF PermError requires counting the total DNS lookups in your SPF record chain. Tools like MXToolbox, dmarcian's SPF surveyor, and the spf-engine Python library can trace the full lookup chain and count total lookups. If you are over the limit, there are two approaches: flatten the SPF record (replace include directives with their resolved IP ranges, which avoids lookup counts but requires updates when providers change their IP ranges), or use a dynamic SPF service (PowerDMARC's SPF flattening, EasyDMARC) that automatically maintains a flattened SPF record and stays within the lookup limit.

DomainKeys Identified Mail (DKIM) works differently from SPF. Rather than checking whether the sending server is on an authorized list, DKIM verifies a cryptographic signature added to the message headers and body by the sending mail server. The sending domain publishes the public key in a DNS TXT record under a selector subdomain (e.g., selector1._domainkey.example.com). The receiving server retrieves the public key and verifies the signature. If verification succeeds, DKIM passes.

DKIM has a significant operational advantage over SPF for handling email forwarding. When a message is forwarded, the forwarding server relays the message from a new IP address that is not in the sender's SPF record, causing SPF to fail. The DKIM signature, however, is attached to the message headers and body; it survives forwarding as long as the headers and body are not modified. Mailing lists that rewrite headers or add footers to the message body will break DKIM signatures; simple forwards that leave the message intact preserve them. For DMARC purposes, passing either SPF or DKIM alignment is sufficient for a message to pass DMARC, so DKIM's forwarding resilience is important for reducing false positives at p=quarantine and p=reject.

DKIM key rotation is operationally important and frequently neglected. DKIM private keys should be rotated periodically (annually at minimum, quarterly for high-value domains) to limit exposure if a key is compromised. Rotation requires: generating a new key pair, publishing the new public key at a new selector, configuring the sending mail server to sign with the new key, waiting for DNS TTL to expire so all caches have the new key, and then removing the old selector record. M365 has built-in DKIM key rotation initiated from the Defender portal. Google Workspace supports manual DKIM key rotation. For custom mail servers, automation of this rotation process is worth implementing to ensure it actually happens.

For high-volume senders, DKIM signing length matters. A signature over the full message body is more secure but more fragile; any body modification breaks the signature. DKIM supports l= tags that limit the signed body length, but this creates security risks because content appended after the signed length is not authenticated. Use full body signing without length limits for transactional mail.

DMARC adds an alignment requirement on top of SPF and DKIM. A message passes DMARC only if it passes SPF or DKIM, AND the authenticated domain aligns with the domain in the message's From header. This alignment requirement is what makes DMARC effective against direct spoofing: an attacker can send from an authorized IP for their own domain and pass SPF, but they cannot align that SPF pass with a forged From header claiming to be from your domain.

SPF alignment compares the domain in the SPF-authenticated MAIL FROM (envelope sender) with the domain in the From header. Relaxed SPF alignment requires only that the two domains share the same organizational domain (example.com matches mail.example.com and outbound.example.com). Strict SPF alignment requires exact domain match. Relaxed alignment is the default and is appropriate for most configurations because email service providers commonly use subdomains or custom MAIL FROM domains that share the organizational domain with the From header.

DKIM alignment compares the domain in the DKIM d= tag with the From header domain. Relaxed DKIM alignment is again the default and allows subdomain matches at the organizational domain level. The alignment mode is configured in the DMARC record using aspf=s for strict SPF and adkim=s for strict DKIM.

Subdomain policy is a frequently overlooked DMARC configuration dimension. The sp= tag in the DMARC record specifies the policy for subdomains that do not have their own DMARC records. If your main domain is at p=reject but your subdomains are not explicitly covered by DMARC records, subdomains fall back to the sp= policy (which defaults to the main domain's policy if not explicitly set). If you have subdomains that send legitimate email (mail.example.com, notifications.example.com), they need their own SPF and DKIM configuration and, ideally, their own DMARC records. Subdomains used only for web hosting or other non-email purposes can be covered by setting sp=reject in the parent domain's DMARC record.

DMARC aggregate reports (rua) are XML files sent by receiving mail servers to the address specified in the rua tag. Each report covers a 24-hour period and contains, for each mail source, the count of messages received, the SPF and DKIM disposition, and the DMARC policy result. Reading raw XML is impractical; use a DMARC analysis service.

Dmarcian, Proofpoint Email Fraud Defense, Valimail, EasyDMARC, and Google Postmaster Tools are the major DMARC reporting platforms. Each ingests your rua reports and presents aggregate data in a web interface showing which mail sources are sending as your domain, whether they pass SPF and DKIM alignment, and the volume of passing versus failing messages. Set up at least one of these services before starting the p=none data collection phase.

The key questions to answer from aggregate reports are: What sources are sending as your domain? Which sources are passing full DMARC alignment (both SPF and DKIM pass, both aligned)? Which sources are sending large volumes and failing alignment? Which sources appear to be unauthorized senders (no legitimate business purpose for sending as your domain)?

Legitimate senders that fail alignment are your actionable items: you need to either fix their alignment or remove them from your mail stream. Unauthorized senders are the spoofing attempts that p=reject will block. Do not be surprised by the volume of unauthorized sending you discover; domains with recognizable brand names are spoofed constantly by phishing campaigns, and seeing thousands of spoofed messages in your rua reports is normal before p=reject is in place.

The analysis phase typically takes four to eight weeks for organizations with complex mail environments. Do not rush this phase. Missed legitimate mail streams become incidents when you reach p=reject.

The most challenging part of the path to p=reject is comprehensive discovery of every system that sends email as your domain. Organizations have accumulated SaaS integrations, on-premises applications, and mail relay configurations over years, and many of these are not documented anywhere.

The systematic discovery approach combines DMARC aggregate report analysis (what is actively sending) with a cross-team inventory process (what should be sending). Start with IT and business system owners: ask each team to list every system that sends email, including transactional email from applications, marketing automation platforms, ticketing system notifications, monitoring alerts, and batch job reports. Cross-reference this inventory against the senders appearing in your DMARC reports.

Common mail stream categories that are frequently missed: marketing automation (Marketo, HubSpot, Mailchimp, Salesforce Marketing Cloud), customer support and ticketing (Zendesk, Salesforce Service Cloud, ServiceNow), transactional email services (SendGrid, Mailgun, Amazon SES, Postmark), HR and benefits platforms (Workday, ADP, Greenhouse), accounting and finance applications (NetSuite, SAP, Oracle), security tools that send alert emails, and legacy on-premises applications with embedded SMTP configurations.

For each discovered mail stream, verify that SPF includes the service's sending IP ranges (or that the service has been configured with a custom MAIL FROM domain that is covered by your SPF record), and that DKIM signing is configured either by the service itself or through a DKIM signing delegation. For SaaS services, check the service's documentation for DMARC alignment instructions. Many services support DKIM signing from your domain via a TXT record published in your DNS. Enabling this is typically a matter of copying a CNAME or TXT record value from the service's admin console into your DNS configuration.

After four to eight weeks of aggregate report analysis and mail stream alignment remediation, you should have a picture of your mail flow where all known legitimate mail streams pass DMARC alignment. The next step is moving from p=none to p=quarantine, which directs receiving servers to deliver failing messages to spam rather than the inbox.

Update the DMARC record to p=quarantine with a percentage tag of pct=25 to start: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com. The pct tag applies the quarantine policy to only 25 percent of failing messages; the remaining 75 percent are still delivered normally (as if policy were p=none). This graduated approach limits the impact of any legitimate mail streams you missed during the discovery phase, because only a fraction of their failing messages will be quarantined.

Monitor for two to three weeks at pct=25. Check your aggregate reports for changes in the pass/fail ratio for known legitimate senders. Check with business teams for any reports of email not being received. If any legitimate sender is now failing and getting quarantined, investigate the alignment issue and fix it before proceeding. If the two to three week period is clean, increase to pct=50, wait another two weeks, then pct=100. At pct=100 with p=quarantine, all failing messages are going to spam.

Spend at least 30 days at p=quarantine with pct=100 before moving to p=reject. This is the observation period where you verify that no legitimate mail is being caught by the quarantine policy. Review the spam folder delivery rates for key communication flows: automated notifications from business systems, marketing emails, transactional receipts. Any legitimate mail consistently landing in spam at this stage indicates an alignment issue that needs to be resolved before p=reject.

Moving from p=quarantine to p=reject is the final step and the one that provides full spoofing protection. At p=reject, receiving servers that check DMARC drop messages from your domain that fail alignment; they are not delivered at all, not even to spam. Update the DNS record to v=DMARC1; p=reject; rua=mailto:dmarc@example.com.

Before flipping to p=reject, perform a final check: review the last 30 days of aggregate reports and confirm that the only failing sources are known unauthorized senders (spoofing attempts), not legitimate mail streams with alignment issues. If your p=quarantine phase produced any complaints about missing email, resolve all of them before moving to reject. A p=reject error for a legitimate mail stream means the message is dropped silently; the sender receives a bounce, the recipient never sees the message, and the root cause may not be obvious.

Email forwarding is the most common legitimate scenario that fails DMARC at p=reject. When an email is forwarded from a personal mailbox at one provider to a mailbox at another, the forwarding server typically relays the message with the original From header intact but from a new IP that is not in the sender's SPF record. If the DKIM signature survived forwarding (no header or body modifications), DKIM alignment can still pass DMARC. If the forwarding server strips or modifies DKIM-signed headers, both SPF and DKIM fail and the forwarded message is rejected.

Authenticated Received Chain (ARC) is the IETF standard mechanism for handling this scenario. ARC allows a mail intermediary (the forwarding server) to add its own signed seal to the message attesting to the results of DMARC-aligned authentication at the previous hop. Receiving servers that trust the ARC seal can use it to deliver messages that would otherwise fail DMARC due to forwarding. ARC is supported by Google, Microsoft, and many other major mail providers. The practical implication for senders reaching p=reject is that legitimate forwarded messages from well-known forwarding services should still be delivered; messages forwarded through unknown or untrusted intermediaries may be rejected.

Brand Indicators for Message Identification (BIMI) is a standard that allows organizations with DMARC at p=quarantine or p=reject to display their brand logo in the email client's message list, adjacent to the sender name. BIMI is a reward for organizations that have done the work to reach enforcement; it provides a visible trust signal that helps recipients identify legitimate emails from an organization in a crowded inbox.

BIMI requires DMARC at p=quarantine (with pct=100) or p=reject. It requires a verified mark certificate (VMC) issued by a CA authorized to issue VMCs (DigiCert and Entrust currently), which in turn requires that the logo be a registered trademark. The certificate is expensive (typically $1,200 to $1,500 per year) and the trademark registration process takes months if not already complete. For organizations with registered trademarks, the ROI is brand protection and increased email engagement metrics from the trust signal.

The BIMI DNS record is a TXT record at default._bimi.example.com specifying the URL of an SVG-format logo file and the URL of the VMC certificate. The SVG must meet BIMI SVG Profile specifications (simplified profile, no external references, specific aspect ratio). Google Workspace and Yahoo Mail are the major email clients currently displaying BIMI logos; Apple Mail added support in iOS 16.

Even for organizations not ready to invest in a VMC, reaching p=reject is the correct outcome of a DMARC implementation. The spoofing protection is unconditional at p=reject; BIMI is an enhancement on top of that protection, not a prerequisite for it.