DMARC Policies: The Complete Guide to SPF, DKIM, Email Authentication, and Protecting a Domain From Spoofing Attacks

Every day, cyberattackers send millions of emails that appear to come from legitimate domains: a bank, a CEO, a payroll provider. When a domain has no enforcement policy in place, recipients have no reliable way to tell those forgeries from real messages, and the domain becomes a free launchpad for phishing, business email compromise (BEC), and brand impersonation. DMARC policies are the control that shuts that door, yet most organizations that publish one never move it past monitoring mode, where it blocks nothing at all.

This guide covers:

• How the three DMARC policies, p=none, p=quarantine, and p=reject, differ across Gmail, Microsoft 365, Yahoo, and Apple Mail in practice;
• How SPF and DKIM feed into DMARC authentication, and how identifier alignment ties both protocols to enforcement;
• A phased roadmap for progressing from monitoring to full enforcement without blocking legitimate mail;
• A complete reference for every DMARC record tag, plus how to read the aggregate reports that reveal which sources send mail using a domain.

A DMARC policy stuck at monitoring mode blocks nothing while cyberattackers keep spoofing the domain. Adaptive Security removes spoofed and AI-generated phishing before employees ever see it.

Explore Cloud Email Security

What Is a DMARC Policy?

A DMARC policy is an email authentication instruction that lets domain owners tell receiving mail servers how to handle messages that fail SPF or DKIM checks. DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, bridges the gap between authentication and enforcement. Without a published DMARC policy, SPF and DKIM can verify an email's origin but cannot tell the receiving server what to do when verification fails.

The policy lives in a public DNS TXT record and specifies one of three actions: monitor only (p=none), send to spam (p=quarantine), or block outright (p=reject). A domain with SPF and DKIM configured but no DMARC policy remains fully vulnerable to spoofing, because the receiving server has no instruction to act on authentication failures.

DMARC gives domain owners a mechanism to state, publicly and verifiably, exactly what should happen to any message that claims to be from their domain but fails authentication. That mechanism gives domain owners a way to act on authentication failures instead of merely observing them.

The distinction between having no DMARC record and having a record set to p=none is one of the most misunderstood points in email security, and it carries operational consequences. A domain with no DMARC record is invisible to the authentication ecosystem: receiving servers apply no DMARC-based policy at all, and the domain owner has zero visibility into who is sending email under its name.

A domain with a DMARC policy at p=none has entered the authentication framework, because the policy tells receiving servers to take no action against failing messages while enabling DMARC aggregate reporting (RUA). Those reports give domain owners forensic visibility into every source sending mail as their domain, authorized or not, and that reporting data is the foundation for moving toward enforcement.

The gap between monitoring and enforcement is wide. According to the EasyDMARC 2026 DMARC Adoption Report, global DMARC adoption reached 52.1 percent of the top 1.8 million domains, yet of the 937,931 domains with valid records, more than half remain stuck at p=none, providing no protection against domain spoofing. These organizations have installed the alarm system but left it in test mode.

Publishing a record at p=none satisfies an audit while blocking nothing cyberattackers send. Adaptive Security layers AI phishing and BEC detection on Google and Microsoft to catch what authentication misses.

Explore Cloud Email Security

The DMARC DNS Record: Where the Policy Lives

A DMARC policy is published as a DNS TXT record at a specific subdomain: _dmarc.example.com. When a receiving mail server processes an inbound message claiming to be from a domain, it performs a DNS query for that record, parses the policy tags, evaluates the message against the published preferences, and takes action accordingly.

The record itself is a semicolon-separated string of tag-value pairs. A basic DMARC record looks like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.

The v tag specifies the protocol version, and the p tag is the policy, the enforcement instruction that defines what receiving servers should do with messages that fail authentication. The rua tag specifies where aggregate DMARC reports should be sent, giving domain owners visibility into every server attempting to send email on their behalf.

Three policy values are available. p=none instructs receiving servers to take no action on authentication failures, so the domain is monitored but unprotected. p=quarantine directs receiving servers to deliver failing messages to the recipient's spam or junk folder rather than the inbox.

p=reject is the only policy that provides full protection, because receiving servers reject failing messages at the SMTP level and prevent them from reaching recipients in any form. Every day a domain remains at p=none, it can be spoofed without consequence.

Beyond the core policy tag, additional parameters refine DMARC behavior. The pct tag specifies the percentage of failing messages the policy applies to, enabling gradual enforcement rollouts, and the sp tag sets a separate policy for subdomains, which matters because cyberattackers frequently spoof subdomains that the primary domain owner may not actively monitor.

The adkim and aspf tags define alignment modes, strict or relaxed, determining how closely the authenticated domain must match the visible From domain. These parameters give domain owners granular control over their authentication posture, but they also introduce complexity that can lead to misconfiguration and silent protection gaps if not carefully managed.

What Problem DMARC Policies Solve

DMARC policies solve domain spoofing, the technique where a cybercriminal sends email that appears to originate from a target's domain. Without DMARC, anyone on the internet can send an email with that domain in the From field, and recipients have no automated way to determine whether the message is legitimate or fraudulent.

The scope of the problem is not theoretical. Business email compromise (BEC), where cyberattackers impersonate executives, vendors, or business partners to trick employees into wiring funds or sharing sensitive data, caused $2.77 billion in reported losses in 2024, according to the FBI's Internet Crime Complaint Center 2024 Internet Crime Report.

Domain spoofing is the foundational technique behind a large fraction of those cyberattacks. When a finance team member receives an invoice from what appears to be a trusted vendor's domain, or when an HR director receives a payroll change request that appears to come from the CEO, the domain in the From field is the primary trust signal they rely on, and DMARC policies remove the cyberattacker's ability to exploit that signal.

The three authentication protocols work together in a chain. SPF (Sender Policy Framework) verifies that the sending server is authorized to send mail for the domain, and DKIM (DomainKeys Identified Mail) provides a cryptographic signature that verifies the message was not altered in transit.

Neither SPF nor DKIM alone tells the receiving server what to do when verification fails, which is DMARC's role: it is the policy layer that converts authentication signals into action. Without DMARC, SPF and DKIM are evidence without a verdict.

The real-world impact of DMARC enforcement at scale is measurable. A country with a national DMARC mandate, such as the United States with its Binding Operational Directive 18-01 for federal agencies, saw successful phishing email delivery rates drop from 69 percent to 14 percent, while jurisdictions without such mandates saw delivery rates rise as high as 97 percent, according to the EasyDMARC 2025 DMARC Adoption Report. Email authentication measurably shrinks the number of ways a cyberattacker can exploit a domain.

A domain without DMARC enforcement becomes a weapon cyberattackers can turn against customers, partners, and employees. Every phishing email sent from a spoofed domain erodes trust in the brand and trains recipients to treat legitimate communications with suspicion.

Who Needs a DMARC Policy and Why

Every organization that owns a domain and sends email needs a DMARC policy. There are no exceptions based on size, industry, or email volume. Every domain needs one; the real variable is how fast it reaches full enforcement.

The regulatory landscape has made this explicit. Google, Yahoo, and Microsoft now require SPF, DKIM, and a published DMARC record for any domain sending more than 5,000 messages per day, with non-compliant mail rejected at the SMTP level as of late 2025. PCI DSS Requirement 5.4.1 mandates anti-phishing mechanisms for any organization handling cardholder data.

General PCI DSS non-compliance can trigger substantial monthly fines from card networks and acquiring banks, though these penalties are not assessed per individual requirement. The European Union's NIS2 Directive, covering banking, energy, healthcare, and digital infrastructure among other sectors, recognizes email authentication as a required cybersecurity control. Organizations without DMARC policies now face security risk alongside regulatory, financial, and operational consequences.

Adoption figures show that enforcement maturity varies sharply by company size, and the enterprise versus mid-market gap reveals where risk is concentrated. The EasyDMARC analysis found Fortune 500 companies have achieved 95 percent DMARC adoption with 62.7 percent at the strictest p=reject policy, while Inc. 5000 companies trail significantly, with 76.2 percent adopting DMARC but only 15.2 percent reaching p=reject.

More than half of those mid-market firms remain at p=none in monitoring-only mode. The organizations most actively targeted by ransomware and BEC cyberattackers are therefore the ones least protected by DMARC enforcement.

Industry verticals facing the highest impersonation risk should prioritize DMARC enforcement:

• Financial services organizations, where a single successful BEC cyberattack can trigger seven-figure losses and regulatory sanctions.
• Healthcare providers, where domain spoofing can be used to phish patient data and compromise protected health information.
• Technology companies, whose brand names are routinely impersonated in credential harvesting campaigns targeting their customers.
• Professional services firms, where cyberattacker access to a single spoofed partner email can compromise multiple client relationships simultaneously.
• Any organization that handles payment card data, which now faces DMARC as a PCI DSS compliance obligation instead of a discretionary security investment.

The path from no protection to full enforcement follows a defined sequence. A domain deploys at p=none with aggregate reporting to gain visibility into all email sources, configures SPF and DKIM for every legitimate sending service, and monitors reports for authentication failures and unauthorized senders. It then moves to p=quarantine once reports confirm all legitimate sources pass authentication, and finally to p=reject, the only policy that stops spoofed messages from reaching any inbox.

That enforcement gap is closing at the largest companies, proving full enforcement is achievable even for the most complex email environments. The question each organization must answer is how much longer it is willing to leave its domain available as a cyberattacker's tool.

Every unauthenticated message from a spoofed domain erodes the trust customers place in the brand. Adaptive Security removes AI-generated phishing and spoofed mail before it reaches employees.

Book a demo

How DMARC Policies Work: The Authentication Flow Step by Step

Every email that lands in an inbox runs a gauntlet of silent authentication checks before the recipient ever sees it. When DMARC policies are configured correctly, they decide in milliseconds whether a message is genuine, suspicious, or outright fraudulent. According to a 2026 DMARCguard analysis of 5.5 million domains, only 12.8 percent enforce DMARC policies that protect against spoofing, leaving the vast majority of organizations exposed to domain impersonation.

The process runs through five sequential stages: SPF validation of the envelope domain, DKIM signature verification, identifier alignment against the From header, DNS policy lookup, and the enforcement action that determines the message's fate.

Step 1: Email Arrives, SPF Check on the Envelope Domain

The moment a sending server opens an SMTP connection and transmits the MAIL FROM command, the receiving mail server has its first authentication vector. SPF (Sender Policy Framework) validates whether the connecting IP address is authorized to send mail on behalf of the domain specified in the envelope, the Return-Path address invisible to the end recipient.

The receiving MTA executes a DNS query for TXT records at the envelope domain. If an SPF record exists, a formatted string listing authorized IP ranges, hostnames, and mechanisms like include, a, mx, and the all qualifier, the server evaluates the connecting IP against that list. The result is one of several outcomes: Pass, Fail, SoftFail, Neutral, None, TempError, or PermError (a permanent DNS lookup error that receiving servers treat as an outright SPF failure).

An SPF Pass alone does not satisfy DMARC, because the authenticated domain must survive the alignment test in Step 3. Many legitimate emails pass SPF on the envelope domain but fail DMARC when the envelope domain differs from the header From domain, a scenario common with email service providers, forwarding services, and mailing lists.

Step 2: DKIM Signature Validation Against the Signing Domain

Parallel to the SPF check, the receiver validates any DKIM (DomainKeys Identified Mail) signatures present in the message headers. A DKIM signature is a cryptographic hash embedded in the DKIM-Signature header, containing a selector (s=), the signing domain (d=), the signed header fields, and the signature itself.

The receiver queries DNS for the public key at <selector>._domainkey.<signing-domain>. If the key exists and decrypts the hash successfully, the receiver confirms two things: the message body and specified headers have not been modified in transit, and the entity controlling the signing domain's DNS generated the signature.

DKIM has one structural advantage over SPF: it survives forwarding. Because the signature is attached to the message itself instead of the SMTP envelope, DKIM authentication persists even when intermediate relays rewrite the Return-Path, making it the more reliable authentication method for organizations whose mail passes through third-party senders. A message can carry multiple DKIM signatures from different domains, and only one must pass and align for DMARC to succeed.

Step 3: Identifier Alignment Verification, Matching the Authenticated Domain to the From Header

Authentication alone is not enough. A message could pass SPF with the envelope domain mailer.example.com and pass DKIM with the signing domain newsletter.example.org, yet the From header visible to the recipient reads ceo@yourbank.com. Without alignment, cyberattackers authenticate a domain they control while spoofing a domain they do not.

DMARC closes this gap by requiring that the authenticated identifier, the domain that passed SPF or the d= domain in a valid DKIM signature, aligns with the domain in the RFC 5322 From header. Alignment operates in two modes, set by the aspf and adkim tags in the DMARC record. Strict mode requires an exact domain match.

Relaxed mode requires only an organizational domain match, so any subdomain of yourbank.com aligns with yourbank.com in the From header. Relaxed alignment is the default and the far more common configuration, because transactional and marketing email often originates from subdomains.

DMARC passes if at least one mechanism, SPF or DKIM, both authenticates and aligns. This either-or requirement, passing through SPF or DKIM, ensures that legitimate multi-hop mail paths, which often break SPF, can still authenticate through DKIM.

Step 4: DMARC Policy Lookup in DNS and Policy Evaluation

With authentication and alignment results in hand, the receiver queries DNS for the DMARC record at _dmarc.<domain>, specifically the organizational domain extracted from the RFC 5322 From header. The query returns a TXT record containing semicolon-separated tags: v=DMARC1, p= (policy), sp= (subdomain policy), pct= (percentage of failing mail to apply policy to), rua= (aggregate report destination), ruf= (forensic report destination), and alignment-mode tags.

The receiver evaluates the combined SPF and DKIM results against this policy. If DMARC passes, the message proceeds to delivery regardless of policy setting. If DMARC fails, the receiver applies the p= value: a none policy instructs the receiver to deliver normally but send aggregate reports, a monitoring-only posture, while a quarantine or reject policy triggers the enforcement step.

The pct tag introduces a critical nuance, because a domain can deploy enforcement incrementally. Setting pct=25 with p=reject means the receiver rejects only 25 percent of failing messages, delivering the remaining 75 percent while still generating reports. This allows domain owners to validate their authentication configuration before full enforcement, which is essential for complex organizations where legitimate mail sources are often discovered through failed DMARC reports instead of audits.

Step 5: Action, Deliver, Quarantine, or Reject Based on the Published Policy

The final step is where policy becomes action. Three outcomes are possible, and how receivers implement each varies significantly.

Deliver (p=none): The message reaches the recipient's inbox normally. Aggregate reports flow to the addresses specified in rua=, giving domain owners visibility into who is sending mail on their behalf without disrupting any mail flow. This is the essential starting point for any DMARC deployment.

Quarantine (p=quarantine): The message is treated as suspicious. Most mailbox providers implement quarantine by delivering the message to the spam or junk folder. However, some receivers apply additional anti-spam filtering to quarantined messages, which may escalate the disposition to a silent block if the content triggers other heuristics. The DMARC specification leaves quarantine interpretation to the receiver, meaning behavior is not uniform across providers.

Reject (p=reject): The strongest protection is SMTP-level rejection with a 550 error code issued during the SMTP transaction itself. When the receiving MTA issues an SMTP 550 response immediately after the DATA command, the sending server receives a non-delivery notification and can alert its own administrator. The alternative, post-SMTP rejection, accepts the message at the transport layer but silently drops it or generates a bounce after the transaction completes. Silent drops are dangerous because neither the sender nor the intended recipient receives any notification. Major mailbox providers including Google and Microsoft implement true SMTP-level rejection for p=reject policies, but smaller receivers may use post-acceptance handling.

Understanding enforcement mechanics is one thing; verifying employees can spot the spoofed messages that still slip through is another. Adaptive Security runs realistic phishing simulations that reveal exactly where workforce readiness breaks down.

Take a self-guided tour

The Three DMARC Policy Options: p=none, p=quarantine, and p=reject

DMARC policies define what receiving mail servers should do with email that fails authentication against a domain. The three DMARC policy options form a gradient from zero protection to complete enforcement. The fundamental distinction is that p=none is a monitoring-only posture that delivers all email normally regardless of authentication failure, while p=quarantine and p=reject are enforcement policies that actively prevent fraudulent messages from reaching recipients' inboxes.

p=quarantine instructs receivers to treat failed mail as suspicious and route it to the spam folder, keeping it technically deliverable but out of the primary inbox. p=reject instructs receivers to block the message at the SMTP level with no delivery at all.

In practice, several major mailbox providers blur this distinction: Microsoft's consumer services reject both quarantine and reject-policy messages identically, while Google and Yahoo honor the difference by quarantining under p=quarantine and blocking only under p=reject. The real security divide falls between p=none and any form of enforcement, more so than between quarantine and reject, because domains sitting at p=none indefinitely practice security theater in place of real domain protection.

p=none: Monitoring-Only DMARC Policies

p=none is the starting-line policy in every DMARC deployment. It tells receiving mail servers to deliver all email normally, including messages that fail SPF and DKIM checks, and to take no protective action against unauthenticated mail. The only thing p=none changes from having no DMARC record at all is that compliant receivers begin sending aggregate reports (RUA) and forensic reports (RUF) back to the domain owner, providing visibility into every source sending mail under the domain.

Organizations use p=none during the discovery phase of a DMARC project. Without it, security teams have no systematic way to identify shadow IT sending services, unauthorized third-party email vendors, or outright spoofing campaigns using their domain.

The dmarcian guide to advancing DMARC policy recommends collecting at least four weeks of reporting data at p=none before considering any policy advancement. The goal is to build a complete inventory of legitimate sending sources and bring each one into SPF and DKIM alignment so that enforcement can begin without disrupting real business email.

The danger of p=none lies less in the policy itself and more in the complacency it creates. Many organizations publish a p=none record to satisfy a compliance checkbox or a platform requirement and then stop.

Google and Yahoo's 2024 sender requirements mandated a published DMARC record for bulk senders but did not require enforcement, producing a wave of p=none-only deployments that satisfy the letter of the requirement while leaving the domain fully exposed to spoofing. A domain at p=none is functionally indistinguishable from a domain with no DMARC at all from the perspective of a cyberattacker.

p=quarantine: Suspicious Treatment Under DMARC Policies

p=quarantine is the first enforcement policy and represents a genuine security milestone. The policy instructs receiving mail servers to accept messages that fail DMARC but to treat them as suspicious, typically by routing them to the recipient's spam or junk folder rather than the primary inbox. For consumer-facing mailboxes like Gmail and Yahoo, this usually means the message lands in the user's spam folder, while for enterprise environments like Microsoft 365 or Google Workspace, it may route the message into an administrator-managed quarantine system that the end user cannot access directly.

The critical nuance with p=quarantine is how anti-spam filtering layers interact with DMARC evaluation. As the dmarcian analysis of advancing DMARC policy explains, even without DMARC in place, email receivers apply their own proprietary anti-spam heuristics, so some fraudulent messages get blocked regardless.

Deploying p=quarantine asserts control over that decision instead of leaving it to the receiver's opaque algorithms. The difference is that domain owners can now see, through aggregate DMARC reports, exactly which messages are being quarantined and at what volume, and this feedback loop is essential for identifying authentication gaps in legitimate sending sources before advancing to p=reject.

p=quarantine has a fundamental weakness: the message is still delivered. A targeted spear-phishing email that lands in a spam folder can still be retrieved by a curious or careless recipient.

For high-value impersonation cyberattacks, such as spoofed CFO wire-transfer requests or fake vendor invoice submissions, reaching any inbox surface, even spam, creates unacceptable risk. Organizations typically use p=quarantine as a transitional state, holding at the policy for weeks or months while monitoring reports and resolving any unexpected delivery issues before advancing to the strictest policy.

p=reject: Full Enforcement DMARC Policies

p=reject is the definitive DMARC policy and the only state that provides meaningful domain protection. Receiving mail servers that honor the policy permanently reject messages that fail DMARC authentication at the SMTP level. The email is never accepted, never delivered, and never reaches any folder, spam or otherwise, and the sending server receives a hard bounce notification, typically a 5XX series SMTP error, which creates an auditable trail of the rejection event visible in DMARC aggregate reports.

The FBI, NSA, and U.S. Department of State jointly addressed this in a 2024 advisory on North Korean actors exploiting weak DMARC policies. The advisory states: "When an organization securely configures a DMARC policy, it helps ensure malicious actors, like Kimsuky, are unable to spoof the organization's legitimate email domain when sending spear phishing messages to a target." The advisory explicitly called out p=none as the policy the Kimsuky group was exploiting and recommended organizations move to either p=quarantine or p=reject, with p=reject providing the strongest defense.

At p=reject, domain spoofing becomes a non-starter for cyberattackers targeting any mailbox provider that honors DMARC. The message never reaches its intended victim, and the cyberattacker receives no signal about whether the target exists, opened anything, or would have been fooled, which eliminates reconnaissance value as well as the attack surface itself. For domains that send no email at all, such as parked domains, retired brands, and defensive registrations, p=reject should be deployed immediately with no transition period, because there are zero legitimate sending sources to protect.

How Quarantine and Reject DMARC Policies Differ Across Major Mailbox Providers

The DMARC specification defines what each policy should mean, but real-world implementation varies significantly by provider. Understanding these differences directly affects the risk calculus of staying at p=quarantine versus advancing to p=reject. The table below summarizes how the four largest mailbox providers handle each enforcement policy.

As announced in Microsoft's 2023 DMARC policy handling update, consumer-facing Microsoft mail servers reject all messages that fail DMARC when either enforcement policy is set. Google's November 2025 enforcement tightening now rejects non-compliant bulk email outright, though the policy distinction for authenticated-domain DMARC handling remains intact. Yahoo's enforcement has tightened in parallel with Google's requirements, and both providers have signaled that stronger DMARC requirements are likely in future updates.

The practical consequence is straightforward. For domains communicating heavily with Microsoft consumer addresses, p=quarantine is functionally equivalent to p=reject, since both result in outright rejection. For domains whose recipients are primarily on Gmail or Yahoo, p=quarantine leaves a residual risk window that p=reject closes entirely.

Why p=reject Matters: The Security Theater Problem

A missing DMARC policy, or one set to p=none, tells the receiving email server to take no security action on emails that fail DMARC checks and to allow those emails through to the recipient's inbox, as the FBI, NSA, and State Department warned in their joint advisory. That warning crystallizes the security theater problem: an organization that publishes a DMARC record at p=none has performed a compliance action that looks responsible on an audit checklist while doing nothing to stop the very cyberattacks DMARC was designed to prevent.

The distinction between quarantine and reject, while real, is a secondary concern compared to the chasm between p=none and any enforcement. The Valimail guidance on DMARC enforcement frames the biggest danger as a domain staying at p=none or sp=none for years on end, making speed-to-enforcement the single most important variable. A domain at p=quarantine today is far more secure than a domain that will reach p=reject after twelve months of deliberation, and infinitely more secure than a domain still at p=none.

For security leaders making the internal case, p=none is not a DMARC deployment; it is preparation for one, and they should frame it that way. Only p=quarantine and p=reject constitute actual domain protection, and the destination for every domain should be p=reject, with p=quarantine serving as a carefully managed on-ramp instead of a permanent parking lot. Every domain needs enforcement; the real question is how quickly the organization can complete the authentication groundwork that makes it possible.

Compliance-only records at p=none pass audits while cyberattackers spoof the domain freely. Adaptive Security detects and remediates spoofed phishing across the inbox, turning every caught attack into training for the employee it reached.

Explore Cloud Email Security

How SPF, DKIM, and DMARC Policies Work Together

SPF, DKIM, and DMARC form a layered defense because no single protocol solves the entire email impersonation problem. SPF verifies the sending server but breaks on forwarding, DKIM verifies message integrity but requires correct key management, and DMARC policies tie them together by requiring the authenticated domain to match what the recipient sees in the From header. The same DMARCguard scan of 5.5 million domains cited earlier also found that only 22.7 percent had a detectable DKIM record and 69.6 percent lacked any DMARC record, exposing how many organizations deploy one protocol and stop.

Without all three working in concert, and specifically without DMARC alignment configured correctly, even authenticated email can be trivially spoofed, because the receiving server has no policy instruction for what to do when authentication passes but the identity does not match.

SPF: Authorizing Sending Servers

Sender Policy Framework (SPF) is the first layer, and it answers a single question: is the IP address delivering this email authorized to send on behalf of the domain in the envelope? An SPF record is a TXT record published in DNS containing a list of approved sending IP addresses, ranges, and hostnames. When a receiving mail server sees an inbound message, it queries the domain in the Return-Path (also called the envelope-from or MAIL FROM) for an SPF record, then checks the connecting IP against that list, and a match yields an SPF pass.

SPF alone is fragile. It authenticates the Return-Path domain, not the From header domain that the recipient sees, a gap that becomes critical once DMARC enters the picture. SPF also dies on forwarding: when a message passes through an intermediate relay, the connecting IP changes and the original SPF check becomes irrelevant, which is why SPF was never designed to stand alone against domain spoofing.

The most common operational pitfall is the 10-DNS-lookup limit. RFC 7208 specifies that SPF evaluation must not require more than ten additional DNS lookups to complete, a constraint designed to prevent denial-of-service attacks against DNS infrastructure. Every include:, a:, mx:, ptr:, and exists: mechanism counts as a lookup, so when organizations chain multiple third-party services such as Google Workspace, Salesforce, Mailchimp, and Zendesk, each include: directive triggers its own sub-tree of lookups.

Crossing the ten-lookup threshold causes a PermError, which receiving servers treat as an SPF failure even when the sending IP is legitimate.

DKIM: Cryptographic Message Signing

DomainKeys Identified Mail (DKIM) addresses what SPF cannot, because it cryptographically binds a message to a domain in a way that survives forwarding. The sending server computes a hash of selected headers and the email body, then signs that hash with a private RSA key.

The signature, including the selector identifying which key was used, the signing domain (d=), and the hash, is appended as a DKIM-Signature header. The receiving server queries DNS for the public key at selector._domainkey.signingdomain.com, verifies the signature, and confirms the message was not altered in transit.

DKIM's cryptographic integrity makes it more resilient than SPF, but its security depends entirely on key strength and key hygiene. The NIST SP 800-131A Rev. 2 standard has moved firmly to 2048 bits as the minimum for RSA keys, and keys of 1024 bits are increasingly flagged or rejected by receiving servers. Organizations that set up DKIM years ago on 1024-bit keys and never revisited the configuration are now seeing silent authentication failures.

Key rotation is not optional. Industry best practice, as recommended by the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), is to rotate DKIM keys every six to twelve months with 2048-bit keys. Selectors are labels in the DKIM signature (the s= tag) that tell the receiving server which public key to fetch, and dated selectors such as jan2026 or july2026 let administrators publish a new key under a new selector, then cut over the signing infrastructure without breaking verification of in-flight messages signed with the old key.

After a transition window, the old key is removed from DNS. CNAME-based DKIM delegation, where the selector points to the email service provider's DNS instead of publishing the key directly, shifts the rotation burden to the provider. This eliminates the most common DKIM failure, a key that was rotated on the signing side but never updated in DNS.

DMARC Policies as the Enforcement Layer

DMARC policies are what make SPF and DKIM operationally useful for stopping domain spoofing. They do two things: require alignment between the authenticated domain and the visible From header, and publish a policy telling receiving servers what to do with messages that fail that alignment check. Without DMARC, SPF and DKIM authenticate infrastructure and message integrity but say nothing about whether the authenticated domain is actually the domain the recipient sees. Cyberattackers exploit that gap by signing with their own DKIM key or sending from their own SPF-authorized IP while putting a target's domain in the From header, so both protocols pass and the recipient never knows the difference.

Identifier alignment is the mechanism that closes this gap, and it is the single most misunderstood concept in email authentication. Alignment asks whether the domain verified by SPF or DKIM matches the domain the human sees in the From header. For SPF alignment, the domain in the Return-Path must match or be organizationally related to the From domain, and for DKIM alignment, the d= domain in the DKIM signature must match or be organizationally related to the From domain. DMARC passes if at least one protocol passes authentication and aligns; if both pass authentication but neither aligns, DMARC fails.

This is the scenario that confuses administrators every day. A company sends marketing email through a third-party platform that uses its own domain as the Return-Path so it can process bounces. SPF checks that platform's SPF record, finds the IP, and passes, but the domain checked is the platform's domain, not the company's.

The platform also signs the DKIM signature with its own d= domain, so DKIM verifies and passes, but again the signing domain is the platform's. Both protocols pass authentication, then DMARC checks alignment: does the platform's domain match the company's?

It does not, so DMARC fails. This pattern repeats across virtually every third-party email service until custom DKIM signing is configured so that d= matches the company's own domain.

Relaxed versus strict alignment determines how precise the domain matching must be, controlled by the aspf= and adkim= tags. Relaxed mode (r), the default, requires that the organizational domain match, so mail.yourcompany.com aligns with yourcompany.com. Strict mode (s) requires an exact match, so mail.yourcompany.com does not align with yourcompany.com. Most organizations should run relaxed alignment, because strict mode breaks legitimate email when subdomains are used for marketing, transactional, or support sending, a common pattern in enterprise email infrastructure. Moving to strict alignment without auditing every sending source almost always causes legitimate email to be rejected.

Troubleshooting alignment failures starts with DMARC aggregate reports. These XML reports, sent daily by receiving mail servers, show authentication results and alignment results side by side for every sending source, so when both SPF and DKIM show pass but DMARC shows fail, the reports reveal exactly which domain mismatch caused the failure.

The remediation is to configure at least one protocol to pass with alignment. Custom DKIM signing where d= matches the domain is the most reliable path because it survives forwarding, while custom Return-Path domains can fix SPF alignment but break more easily. The goal is not perfection across both protocols, since DMARC requires only one to pass with alignment, but having both configured gives redundancy when forwarding or relay scenarios break one.

The layered relationship becomes clear in practice. SPF provides a basic server authorization check that costs almost nothing to deploy but breaks easily, DKIM provides cryptographic integrity that survives forwarding but requires ongoing key management, and DMARC policies provide the enforcement bridge between them, but only when alignment is understood, configured, and continuously monitored across every sending source. Organizations that deploy DMARC without auditing alignment are running a reporting tool without functioning as a security control, and that gap leaves the door open for the exact impersonation cyberattacks these protocols were built to stop.

Misconfigured alignment lets spoofed mail through while blocking legitimate campaigns, and no record catches phishing that bypasses authentication. Adaptive Security adds AI detection that flags what SPF, DKIM, and DMARC cannot.

Book a demo

DMARC Record Tags Explained: sp=, pct=, rua=, ruf=, adkim=, aspf=, fo=, and More

DMARC record tags are the key-value pairs inside a DMARC DNS TXT record that instruct receiving mail servers how to authenticate and handle email claiming to originate from a domain. Each tag controls a distinct aspect of DMARC policies, from policy enforcement and reporting destinations to alignment strictness and subdomain treatment. A complete DMARC record strings these tags together with semicolons, and while the original RFC 7489 defined eleven tags, the 2026 update (RFC 9989) slimmed the list to eight by retiring three that saw negligible real-world adoption: pct, rf, and ri.

Despite Google and Yahoo's 2024 authentication mandates for bulk senders, the same DMARCguard scan of 5.5 million domains found only 30.4 percent had adopted DMARC at all, and just 12.8 percent enforced it with quarantine or reject policies. Understanding what each tag does, when to use it, and what happens if it is left out separates a DMARC record that actually protects a domain from one that only provides a false sense of security.

Required Tags: v= (Protocol Version) and p= (Policy)

Every DMARC record begins with v=DMARC1. This tag identifies the DNS TXT record as a DMARC policy instead of some other TXT record, and without it, receiving servers will not parse the record at all, so the DMARC configuration simply does not exist to the rest of the internet. Only one value is valid, and it must appear first in the record.

The p= tag defines what receivers should do with messages that fail DMARC authentication, and it accepts exactly three values. p=none is monitoring mode, where the receiver logs the failure and sends aggregate reports but delivers the message normally, and every domain should start here.

p=quarantine directs receivers to treat failing messages as suspicious, typically routing them to the spam folder, while p=reject instructs receivers to block the message outright and not deliver it to the intended recipient. Moving from p=none to p=reject is the goal, but skipping the monitoring phase risks blocking legitimate email from third-party services that have not yet been identified.

Together, v and p are the only two tags the DMARC specification declares strictly mandatory. Everything else is optional, though skipping the reporting tags means enforcing policy blind.

Reporting Tags: rua=, ruf=, and fo=

The rua= tag specifies where receiving organizations send DMARC aggregate reports. These are zipped XML documents that arrive daily, summarizing every message that passed or failed authentication from a domain, including source IP addresses, SPF and DKIM results, and the final DMARC disposition. A typical rua value uses the mailto URI scheme, rua=mailto:dmarc-reports@example.com, and multiple addresses are supported as a comma-separated list.

Among DMARC-enabled domains, the DMARCguard study found only 53.5 percent include a rua tag, meaning nearly half of organizations with DMARC deployed have no visibility into what their authentication setup is actually doing. Without aggregate reports, a domain cannot safely advance from p=none to enforcement.

The ruf= tag designates recipients for forensic reports, which are detailed per-message failure samples that can include full headers and sometimes message bodies. These reports expose sensitive information, which is why most major mailbox providers including Gmail and Microsoft do not send them at all. Include ruf only if the organization operates a dedicated abuse mailbox with strict access controls and has a specific forensic investigation use case.

The fo= tag controls the conditions under which forensic reports are generated and only matters when ruf is also present. fo=0, the default, generates a forensic report only when both SPF and DKIM fail alignment, meaning no authentication mechanism passed. fo=1 generates a report whenever either SPF or DKIM fails, which produces far more data and is appropriate during initial deployment when diagnosing why specific messages fall through authentication gaps.

Two additional modes exist: fo=d sends a report on any DKIM signature validation failure regardless of alignment, and fo=s does the same for SPF. Set fo=1 during the first weeks of DMARC deployment to surface every configuration issue, then dial back to fo=0 once email streams are clean.

Policy Refinement Tags: sp=, adkim=, and aspf=

The sp= tag defines the DMARC policy for all subdomains of the organizational domain. If sp is omitted, subdomains automatically inherit whatever policy p= specifies, and this default works for most organizations, but two scenarios justify setting sp explicitly. The first is when a stricter policy is needed for subdomains that should never send email, so a domain like example.com might publish p=reject; sp=reject to block spoofing across the entire namespace.

The second is when subdomains are managed by different teams or third-party services and the organizational DMARC record should apply a relaxed policy while those subdomains handle their own authentication independently. Valid sp values mirror p: none, quarantine, or reject.

The pct= tag historically specified the percentage of failing messages to which the DMARC policy applied, so pct=25 meant only 25 percent of failures triggered the configured policy action. It was designed for gradual enforcement rollouts but saw inconsistent support across mailbox providers, and RFC 9989 formally removed pct from the specification, along with rf and ri.

Its intended use case is now served by the t=y testing flag, a cleaner binary signal that tells receivers the domain owner is still evaluating their DMARC deployment and asks for lenient handling of failures. Unlike pct, t=y does not attempt to control a percentage; it simply declares testing status and lets receivers decide how to respond.

The adkim= tag sets DKIM alignment mode. Relaxed mode (r), the default, passes alignment if the domain in the DKIM d= tag shares the same organizational domain as the address in the RFC 5322 From header, so d=example.com aligns with from@newsletter.example.com. Strict mode (s) demands an exact match, so d=example.com only aligns with from@example.com.

Strict mode blocks subdomain mismatches and is appropriate for domains where all legitimate email flows through a single, tightly controlled mail infrastructure. Most organizations should leave adkim at relaxed, because setting it to strict without confirming every sending service signs with the exact organizational domain will cause legitimate mail to fail.

The aspf= tag works identically for SPF alignment. In relaxed mode, the SMTP envelope Mail From domain and the header From domain need only share the same organizational domain, while in strict mode they must match exactly. The default is relaxed for the same reason: third-party email services often send from a domain's subdomain while the Return-Path uses their infrastructure, and strict alignment would break authentication for those legitimate messages.

How Subdomain DMARC Policies Override the Organizational Domain

A subdomain can publish its own DMARC record that overrides the organizational domain's policy, and this override takes priority. The mechanism is DNS tree walking, formalized in RFC 9989. When a receiving server processes an email from marketing.example.com, it walks the DNS tree in a fixed order:

• First, it looks for a DMARC record at _dmarc.marketing.example.com; if that record exists, the server applies it and stops walking, and the organizational domain record is never consulted.
• If no record exists at the subdomain level, the server moves one level up to _dmarc.example.com; if found, that record governs.
• If the server reaches the organizational domain and still finds no DMARC record, no DMARC policy applies.

This means a marketing team using a third-party email platform can publish v=DMARC1; p=none; rua=mailto:marketing-dmarc@example.com on their subdomain for monitoring while the parent domain enforces p=reject for everything else. The tree-walking approach replaces the older Public Suffix List-based method, which was brittle and sometimes failed for domains on private suffixes or newly created TLDs. The new RFC makes DMARC policy discovery deterministic regardless of domain structure, which means each tag carries unambiguous weight across every receiver that evaluates the domain.

One missing tag can leave a subdomain wide open while the primary domain looks protected. Adaptive Security catches impersonation attacks that slip past authentication and feeds each into employee risk scoring.

Take a self-guided tour

DMARC Aggregate Reports (RUA) vs Forensic Reports (RUF)

DMARC policies produce two distinct report types that together form the monitoring backbone of any email authentication program. Aggregate reports (RUA) deliver a daily XML summary of all email traffic claiming a domain, including which IPs are sending, authentication pass and fail rates, and volume trends. Forensic reports (RUF) provide per-message failure samples with full email headers and sometimes body content, exposing the exact spoofing technique a cyberattacker used. Both serve legitimate purposes, but the same forensic detail that makes RUF valuable for incident investigation also makes it a privacy liability most organizations choose to forgo.

What RUA Aggregate Reports Contain and Why They Matter

Aggregate reports are the workhorse of DMARC monitoring. Delivered once every 24 hours by participating recipient mail servers, each RUA report is an XML document compiling authentication results for every email that claimed to originate from a domain during that period. The data includes the sending IP address, the domain used in the RFC5321.MailFrom envelope, SPF and DKIM authentication outcomes, the DMARC disposition applied, and total message count per sending source.

This structure makes RUA reports the only scalable way to answer the question every domain owner must ask: which sources are sending email as this domain, and are they authorized? Without aggregate reports, there is no systematic visibility into whether third-party email services, marketing platforms, CRM tools, and support ticketing systems are configured correctly.

A single day of RUA data can surface an unauthorized sending source before it damages deliverability or enables a successful domain spoofing cyberattack. The XML format is machine-readable by design, and parsing it at scale requires a dedicated DMARC report analyzer instead of manual review.

What RUF Forensic Reports Contain and the Privacy Cost

Forensic reports operate on an entirely different logic. Where RUA reports summarize everything in aggregate, a RUF report fires in near-real-time when a single message fails DMARC evaluation, delivering a redacted copy of that specific email. The contents typically include full message headers, the subject line, the From and To addresses, SPF and DKIM failure details, and, depending on the receiving server's redaction policy, portions of the message body or URLs embedded within it.

This granularity is powerful for diagnosing why a legitimate campaign failed authentication or for capturing evidence of an active spoofing attempt. It also creates a structural privacy problem.

RFC 9991, the IETF's DMARC failure reporting specification, explicitly warns that forensic reports raise significant privacy concerns because they can expose personally identifiable information, internal email routing paths, and confidential message content to the report recipient. Under GDPR and CCPA, this metadata constitutes personal data requiring protection.

The practical consequence is stark. Most major email receivers refuse to generate RUF reports, and the specification itself notes that many large-scale providers limit or entirely disable failure report generation in favor of aggregate reports. Forensic reports were designed as a diagnostic tool, but most privacy-conscious enterprises can no longer obtain them at all.

How to Read and Act on DMARC Reports

A practical DMARC reporting workflow starts with RUA data and only reaches for forensic detail when an investigation demands it. Begin by ingesting aggregate reports into a report analyzer, either a commercial platform or an open-source parser, that converts raw XML into sortable tables grouped by sending IP and authentication result. The first signal to watch for is any IP address sending more than a trivial volume of email that fails both SPF and DKIM, because that IP is either a misconfigured legitimate sender or an unauthorized source, and either way it requires immediate attention.

Next, categorize every sending source into one of three buckets: authorized and passing, authorized but failing, or unauthorized. This triage process is what moves a domain from a p=none monitoring policy toward p=quarantine or p=reject enforcement without disrupting legitimate email flow. The reporting cadence reinforces this workflow, because daily RUA batches produce trend data over weeks and months, while the near-real-time nature of RUF, where available, is best reserved for investigating a specific phishing campaign or authentication outage.

When choosing a report analyzer, prioritize tools that provide historical trend visualization, automated anomaly detection, and the ability to handle XML at the volume produced by domains sending millions of messages per month. Getting reporting right is what transforms DMARC from a passive record in DNS into an active enforcement layer that blocks domain spoofing before it reaches an inbox.

Aggregate reports reveal which sources spoof a domain, but reading XML at scale is where most teams stall. Adaptive Security surfaces attack trends and the most-targeted employees in one reporting view.

Take a self-guided tour

How DMARC Policies Affect Email Deliverability

DMARC policies at enforcement, p=quarantine or p=reject, directly raise inbox placement because receiving mail servers assign more trust to authenticated domains. According to PowerDMARC's analysis of DMARC policy, properly implemented DMARC policies improve deliverability by 10 to 15 percent, as authenticated domains bypass reputation-based filtering heuristics that catch unauthenticated or partially authenticated senders.

The same enforcement that protects a domain from spoofing can silently destroy deliverability when SPF and DKIM configurations are incomplete. A p=reject policy instructs every receiving server to drop unauthenticated mail at the SMTP level, so if a transactional email platform or CRM was never added to the SPF record, those messages disappear without a bounce or a warning, often unnoticed until customers start calling.

The Deliverability Boost From DMARC Enforcement

Mailbox providers treat authenticated email differently. When a domain publishes a DMARC policy with enforcement, receiving servers recognize that the domain owner has invested in email authentication infrastructure and is actively protecting the domain from abuse. This signal translates into preferential inbox placement.

The mechanism is straightforward. DMARC builds on SPF and DKIM to close the alignment gap that lets cyberattackers spoof a domain even when basic authentication passes. Without DMARC enforcement, a spammer can pass SPF from their own infrastructure while displaying a target's domain in the From header, and the recipient sees a trusted brand on a malicious message.

When enforcement is set to p=quarantine or p=reject, receiving servers verify that the domain authenticated by SPF or DKIM matches the domain the recipient actually sees, and mail that fails this check never reaches the inbox. Every legitimate message that does pass carries the full trust weight of a domain with an active enforcement posture.

The Risks of Incorrect DMARC Configuration

The same enforcement that protects deliverability can destroy it when configuration is incomplete. A p=reject policy is unforgiving, because it instructs every receiving mail server on the internet to reject any message that fails DMARC authentication. If password reset emails are routed through a third-party service that was never added to the SPF record, those messages are dropped, and if a marketing automation platform sends with its own domain in the DKIM signature rather than the organizational domain, alignment fails and the campaign never reaches subscribers.

This is not a theoretical risk. Organizations that rush to p=reject without auditing every legitimate sending source, including shadow IT SaaS tools that marketing, sales, or HR teams adopted without IT involvement, routinely discover the damage through customer complaints rather than monitoring dashboards.

The most dangerous misconfigurations affect transactional email: password resets, multi-factor authentication codes, order confirmations, and legal notices. These messages generate no marketing analytics, no open tracking, and no click data, so their silent failure can persist for days or weeks before anyone detects the problem.

Rushing to p=reject can silently drop password resets and order confirmations for weeks before anyone notices. Adaptive Security adds AI detection that flags the impersonation attempts a misconfigured record lets through.

Explore Cloud Email Security

Google and Yahoo Sender Requirements: A New Baseline

On February 1, 2024, Google and Yahoo began enforcing a joint mandate requiring all bulk senders, defined as domains sending 5,000 or more messages per day to consumer inboxes, to publish a DMARC policy with at least p=none. The mandate triggered the largest single-year shift in email authentication adoption in DMARC history, with 2.5 million domains newly implementing email authentication in the first 60 days of 2024, according to data Google shared at the October 2024 M3AAWG meeting. By year-end, Gmail users received 265 billion fewer unauthenticated emails, a 65 percent reduction.

The mandate established p=none as the floor instead of the ceiling. Microsoft matched the requirements in May 2025 with SMTP-level rejections for non-compliant bulk senders, and Gmail escalated to permanent rejections in November 2025.

Many organizations still sit at p=none, where they meet the minimum requirement and avoid outright rejection but gain none of the trust signaling that p=quarantine or p=reject provide. The deliverability advantage now belongs to the minority that have progressed to enforcement.

DMARC Policies, BIMI, and the Branded Inbox

BIMI (Brand Indicators for Message Identification) is the standard that displays an organization's verified logo next to its email in supporting mailboxes. It is a powerful deliverability and brand-trust tool, but it carries a hard technical requirement: the domain must publish a DMARC policy at p=quarantine or p=reject, because p=none is not sufficient. The BIMI specification requires enforcement because the logo is an assertion of authenticity, and a domain that does not actively prevent spoofing cannot credibly claim that mail bearing its brand is genuine.

Implementing BIMI involves several concrete steps beyond the enforcement prerequisite. The logo must be supplied in SVG Tiny Portable/Secure (SVG Tiny PS) format, a restricted profile of SVG designed for security.

For the logo to display in Gmail and Apple Mail, most implementations also require a Verified Mark Certificate (VMC), a paid certificate that confirms the organization owns a registered trademark for the logo. Provider support continues to expand, with Gmail, Apple Mail, Yahoo, and Fastmail among those that render BIMI logos for qualifying senders.

Domains that progress to enforcement unlock BIMI as a secondary deliverability accelerant. The branded inbox placement draws higher open rates and reduces the likelihood recipients will mark messages as spam, giving one more business reason to complete the journey to p=reject.

How DMARC Policies Affect Transactional, Marketing, and Cold Outreach Email

Different email types sit on different sending infrastructure, and DMARC policies affect each distinctly. Transactional email, including password resets, order confirmations, and invoice notifications, typically flows through dedicated ESPs with tightly controlled IP pools and consistent authentication, which makes these the safest candidates for p=reject because the sending infrastructure is well-defined and rarely changes.

Marketing email runs through broader platforms, often with multiple sending domains, dynamic IP pools, and frequent vendor changes, so every new integration is a potential SPF or DKIM alignment failure. Marketing domains benefit most from a phased progression: p=none for monitoring, p=quarantine at low percentage, then gradual escalation once aggregate reports confirm alignment across all senders.

Cold email outreach and sales engagement platforms operate in the highest-risk DMARC zone. These tools often rely on third-party sending infrastructure, use tracking pixels that flag spam filters, and send to recipients who never opted in, so publishing p=reject on a domain used for cold outreach can accelerate reputation damage if the platform's sending practices already generate spam complaints.

Many organizations isolate cold outreach to a separate subdomain with its own DMARC policy, protecting the primary domain's deliverability while maintaining authentication on outbound sales activity. That isolation strategy becomes harder to sustain as the number of email-sending SaaS tools inside the average organization continues to climb.

Common DMARC Policy Configuration Errors and DMARC Best Practices

Most DMARC failures are self-inflicted. Teams skip the monitoring phase, rush to enforcement, forget subdomains exist, and treat configuration as a one-time project, and the result is legitimate email silently discarded and an attack surface left open for anyone who finds it, with no gain in actual security. Sound DMARC policies follow a disciplined set of DMARC best practices that prevent each of these failure modes.

The phased progression is the foundation: start with p=none and comprehensive aggregate reporting, advance to quarantine only after every legitimate sender passes authentication, and move to p=reject once quarantine produces zero false positives. For non-sending domains, publish p=reject immediately with a null MX record and an SPF record that authorizes no senders, and that attack surface closes in minutes.

1. Move to p=reject Gradually With Adequate Monitoring

Jumping from no DMARC policy directly to p=reject causes more self-inflicted email delivery failure than any other mistake. When rejection is enforced, any email that fails SPF or DKIM alignment is silently discarded, so if an organization uses a marketing automation platform, a CRM that sends on its behalf, or a support ticketing system it forgot to authorize, those emails stop arriving the moment enforcement goes live.

The safe path follows three stages. Start with p=none for at least 30 to 60 days, collecting aggregate reports to build a complete inventory of every service sending email from the domain. Move to p=quarantine only after every legitimate sender passes authentication, and monitor for another 30 days to catch edge cases.

Shift to p=reject once quarantine produces no false positives. Skipping these stages has caused organizations to lose transactional emails, password resets, and customer notifications, sometimes for weeks before anyone noticed.

The SPF 10-DNS-lookup limit complicates this progression. The SPF specification caps DNS lookups at 10 per evaluation, and exceeding that limit returns a PermError, which most mail servers treat as authentication failure.

According to a Valimail analysis of the SPF 10-lookup limit, organizations commonly hit this ceiling after adding just five or six third-party services once nested includes are counted. Each include: in an SPF record can trigger additional lookups within that provider's own configuration, and the total escalates quickly, so before enforcing any DMARC policy, verify the SPF lookup count does not exceed 10.

2. Always Include rua= to Receive Aggregate Reports

Deploying DMARC without the rua= tag is the equivalent of installing a security camera and never reviewing the footage. Aggregate reports are XML files sent by receiving mail servers that reveal exactly which sources are sending email from a domain, whether those messages passed or failed authentication, and which specific mechanisms failed. Without rua=, a domain owner is flying blind.

This reporting gap becomes especially damaging when email forwarding enters the picture. Forwarding breaks SPF authentication because the forwarding server, not the authorized sender, becomes the originating IP address that receiving servers evaluate, so a newsletter forwarded from a colleague's inbox to a personal Gmail account will fail SPF because Gmail's forwarding server is not in the SPF record.

The Authenticated Received Chain (ARC) protocol addresses this by preserving the original authentication results across trusted intermediaries, allowing the final recipient to verify that the message passed authentication at the first hop even though the forwarding hop broke SPF. ARC adoption is growing among major providers including Google and Microsoft but remains incomplete across the ecosystem, and only rua= reports reveal the true scope of forwarding-related failures.

Configure rua= with a mailbox address capable of receiving and processing XML attachments at scale. Most organizations use a dedicated DMARC analysis tool instead of a shared inbox, since aggregate report volume quickly overwhelms manual review.

3. Protect Subdomains With an Explicit sp= Policy

Cyberattackers exploit a fundamental asymmetry in DMARC: when a record is published on the organizational domain but subdomains are left unaddressed, spoofed emails from invoice.example.com or portal.example.com bypass the policy entirely. The sp= tag exists specifically because subdomains inherit no protection by default.

Set sp=reject on the root domain's DMARC record once it is confirmed that no legitimate subdomains send email. If marketing or transactional subdomains do send mail, create dedicated DMARC records for each one with policies appropriate to their email volume.

Non-sending domains, including parked domains and expired brands, demand even stricter treatment: publish p=reject, configure a null MX record that signals no mail server accepts email for the domain, and apply the null SPF record described earlier to authorize no senders whatsoever. These domains represent zero-cost attack surfaces that cyberattackers actively scan for, and closing them takes minutes.

4. Treat DMARC Policies as Ongoing Maintenance, Rather Than a One-Time Project

DMARC is not a configuration to set once and forget. Third-party services change their sending infrastructure, new departments adopt email platforms without informing IT, SPF records drift past the 10-lookup limit as tools accumulate, and DKIM keys expire or rotate. Each of these changes can silently break authentication and, under p=reject, cause delivery failures.

Schedule a quarterly review of aggregate reports to confirm that no unauthorized services have begun sending email and that all legitimate senders continue passing authentication. Monitor the SPF lookup count after every new service addition, rotate DKIM keys on a regular cadence, and validate that new keys propagate before retiring old ones. As an organization's email security posture matures, the review cycle tightens from quarterly to monthly, and organizations that treat DMARC as a living configuration instead of a static DNS record avoid the painful scramble of discovering broken email delivery through customer complaints.

Even a well-maintained record cannot see the lookalike-domain phishing and compromised-vendor mail that passes authentication cleanly. Adaptive Security detects those AI-generated attacks and remediates them across every inbox they reach.

Book a demo

Business and Compliance Benefits of DMARC Policy Enforcement

DMARC policy enforcement at p=reject is the difference between monitoring impersonation cyberattacks and stopping them outright.

Moving from p=none to p=reject turns a passive monitoring tool into an active defense that stops cyberattackers from using a domain to phish customers, partners, and employees. Every day a domain sits at p=none, it remains spoofable, and cyberattackers know the difference.

How DMARC Policy Enforcement Supports Regulatory Compliance

Regulatory pressure has transformed DMARC from a best practice into a compliance obligation across multiple frameworks. PCI DSS v4.0.1, with enforcement effective March 31, 2025, identifies DMARC, SPF, and DKIM as anti-phishing controls under Requirement 5.4.1, which mandates that organizations handling cardholder data implement processes and automated mechanisms to detect and protect personnel against phishing. Auditors increasingly expect p=reject as evidence that those mechanisms are actively blocking cyber threats instead of merely logging them.

HIPAA's proposed 2025 Security Rule update strengthens technical safeguard requirements for electronic protected health information, mandating measures that prevent unauthorized access to ePHI. A cyberattacker who spoofs a hospital's domain to phish patients is blocked at the receiving server once that domain reaches p=reject, directly supporting the rule's goal of reducing unauthorized access to patient data.

For organizations operating in the EU, GDPR Article 32 requires controllers and processors to implement technical measures appropriate to the risk, and email impersonation that leads to data compromise falls squarely within that scope. The NIST Cybersecurity Framework's Protect function (PR.AA) addresses identity management and access control, with NIST SP 800-177 Rev. 1 providing authoritative technical guidance on email authentication deployment.

Government mandates create the highest floor. CISA's Binding Operational Directive 18-01 requires all U.S. federal civilian agencies to implement DMARC at p=reject on second-level domains, the UK's National Cyber Security Centre mandates DMARC for government domains, and the FFIEC handbook for financial institutions identifies email authentication as a control relevant to safeguarding customer information.

Brand Protection: What p=reject DMARC Policies Actually Prevent

When a domain reaches p=reject enforcement, receiving mail servers discard any message that fails DMARC authentication rather than delivering it to the inbox or spam folder. The practical effect is immediate: a cyberattacker spoofing a company domain to send a fake invoice to a customer, a credential-harvesting link to an employee, or a fraudulent wire transfer request to a partner sees those messages silently dropped before the recipient ever sees them.

This matters financially because domain spoofing is not a theoretical cyberattack. The Red Sift analysis found that 83.9 percent of all domains globally have no DMARC record at all, meaning the vast majority of organizations are structurally exposed to impersonation.

When a customer receives a phishing email that appears to come from a brand, the costs compound across fraud losses, support ticket volume, brand reputation erosion, and, in regulated industries, regulatory notification requirements if personal data is compromised. A domain at p=reject prevents that entire chain of events from starting.

Domain spoofing that reaches a customer erodes brand trust and triggers fraud losses no refund recovers. Adaptive Security stops spoofed phishing at the inbox and turns each detected cyberattack into targeted employee training.

Explore Cloud Email Security

The Measurable Value of DMARC Policy Enforcement

The business case for DMARC policy enforcement rests on three quantifiable outcomes. The first is reduced phishing incident volume, because a domain at p=reject eliminates the entire category of cyberattacks that rely on spoofing that domain, which remains one of the most common phishing vectors.

The second is improved email deliverability. The Google, Yahoo, and Microsoft bulk-sender requirements that took full effect across 2024 and 2025 mean domains without proper SPF, DKIM, and DMARC now face delivery throttling or outright rejection for legitimate marketing and transactional mail, so DMARC enforcement protects revenue-generating email flows.

The third and most consequential outcome is avoided breach cost. According to the IBM Cost of a Data Breach Report 2025, the average global breach cost fell to $4.44 million, the first year-over-year decline in the report's history, and the same report identified phishing as the most common initial attack vector. A single prevented breach, whether a BEC wire fraud attempt or a credential-harvesting campaign, offsets years of DMARC implementation investment.

Full enforcement is demonstrably achievable at scale, as the U.S. federal government's CISA BOD 18-01 mandate has proven across civilian agencies. For organizations in low-enforcement sectors, moving to p=reject creates an asymmetric advantage: cyberattackers target the domains that remain spoofable before they bother with one that is not.

Where a domain sits on the enforcement curve depends heavily on its sector, and the industry-by-industry picture reveals where the value of moving to p=reject is highest.

Even the largest enterprises fall short, as the Fortune 500 enforcement rate cited earlier leaves more than a third of DMARC-publishing domains without full p=reject coverage.

The Future of DMARC Policies: DMARCbis (RFC 9989) and What's Changing

The DMARC standard received its first full update in over a decade when the Internet Engineering Task Force published DMARCbis as RFC 9989 in May 2026. The update moves the protocol from an Informational specification to a formal Proposed Standard. This is not a radical rewrite, because existing DMARC records continue to work and the version string remains v=DMARC1, but the update introduces meaningful changes that tighten enforcement, close impersonation gaps, and replace mechanisms that never worked as intended.

What DMARCbis Changes and Why Now

DMARCbis is the collective name for three new RFCs: 9989 (core protocol), 9990 (aggregate reporting), and 9991 (failure reporting). Together they obsolete the original RFC 7489 published in 2015. The revision addresses structural weaknesses that a decade of real-world DMARC deployment exposed, none more consequential than the protocol's handling of indirect mail flows and subdomain policy enforcement.

RFC 7489 left ambiguity around how receivers should treat email that traversed mailing lists or forwarders, scenarios where SPF breaks and DKIM signatures frequently fail. It also relied on the Public Suffix List (PSL), a community-maintained resource, to determine organizational domain boundaries, creating inconsistencies across implementations. The pct tag, designed for gradual enforcement rollout, was implemented so unevenly across mailbox providers that the vast majority of domains ignored it entirely, and DMARCbis sweeps these accumulated edge cases into a single coherent specification with clearer operational guidance.

Key Changes: t=y, np=, and Indirect Mail Flow Requirements

Three changes stand out for organizations managing DMARC policies today. The first is that the pct tag is removed and replaced by the t (testing) tag, a binary switch that is dramatically simpler to reason about.

Setting t=y tells receivers to apply one policy level below what is declared, so a p=reject record with t=y is treated as p=quarantine, and p=quarantine with t=y is treated as p=none, while the default t=n applies the declared policy at full strength. This eliminates the flawed percentage-based logic and gives domain owners a clean staging mechanism.

The new np= tag closes a subdomain-spoofing gap that the old sp= tag never addressed. The sp= tag governs existing subdomains that have DNS records, while np= applies to subdomains that do not exist at all, such as a fabricated accounting.example.com or payroll.example.com address invented by a cyberattacker.

When np=reject is set, any mail claiming to originate from a non-existent subdomain is rejected by participating receivers, and for most domains this is a cost-free security improvement, because a subdomain that does not exist sends no legitimate mail. The evaluation order follows np= first, falling back to sp=, then to the main p= policy if neither is present.

The most operationally significant change concerns indirect mail flows. DMARCbis now requires that mail receivers must not reject incoming messages solely on the basis of a p=reject policy; in the absence of additional knowledge about the sending domain's traffic patterns, receivers must treat failing mail as if the policy were p=quarantine. This provision exists because strict enforcement can break legitimate mail that passes through mailing lists or forwarders, so a domain publishing p=reject can no longer assume universal enforcement in all delivery contexts.

DMARCbis also introduces updated aggregate report structures through RFC 9990. New fields include the t and np tags, a discovery method flag showing whether the domain was resolved via PSL or DNS Tree Walk, and stricter formatting requirements that improve consistency across mailbox providers.

What This Means for Organizations Managing DMARC Policies Today

DMARCbis is backward-compatible by design, so no organization needs to change a working DMARC record immediately, and records starting with v=DMARC1 remain valid. That said, two additions are worth acting on now. Adding np=reject to an existing record, changing v=DMARC1; p=reject; to v=DMARC1; p=reject; np=reject;, is a one-field change that closes an impersonation vector without affecting any legitimate mail flow.

Adopting t=y for domains still in monitoring mode provides a cleaner path to enforcement than the percentage-based pct approach ever did, and organizations can adopt it as they rotate through their next DMARC configuration review. The shift from the Public Suffix List to DNS Tree Walk for organizational domain discovery will matter primarily to organizations managing large subdomain estates, while single-domain operators will not notice the difference.

For everyone else, DMARCbis formalizes what the community already practiced and gives security teams a firmer standards-track footing when building the case for email authentication investment. That investment becomes harder to defer as email-based impersonation grows more sophisticated, and the authentication layer that DMARC policies provide is the foundation every subsequent defense depends on.

Standards evolve, but cyberattackers move faster than any RFC revision cycle can close every gap. Adaptive Security keeps pace with AI-generated phishing and deepfake impersonation that authentication standards were never designed to catch.

Take a self-guided tour

How DMARC Policies Reinforce Security Awareness Programs

DMARC policies shrink the attack surface that training alone must cover. When spoofed email never reaches an employee's inbox, that employee never has to decide whether it is real. DMARC stops domain spoofing, but it does nothing against lookalike-domain cyberattacks or compromised-account takeovers, so cybersecurity awareness training remains the last line of defense for the cyber threats that get through. The two layers only work in combination.

DMARC Policies as a Technical Control in a Layered Anti-Phishing Strategy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) prevents cyberattackers from sending email that appears to come from an organization's own domain. When configured with an enforcement policy of quarantine or reject, it instructs receiving mail servers to block or isolate messages that fail SPF or DKIM authentication checks. The practical effect is immediate, because employees stop seeing phishing emails that impersonate the CEO, the finance department, or the IT helpdesk from their own domain.

This matters because spoofed-domain cyberattacks are among the most psychologically effective phishing tactics. An email that looks like it came from a real internal address bypasses the suspicion that generic phishing triggers, so by removing this entire category of cyber threat at the infrastructure layer, DMARC reduces the total volume of malicious email employees encounter and the number of decisions they have to get right every day. According to Verizon's 2026 Data Breach Investigations Report, 62 percent of confirmed incidents involve a human element, which is precisely why lowering the volume of decisions employees face materially reduces organizational risk.

How DMARC Policy Data Informs Cybersecurity Awareness Training Priorities

DMARC aggregate reports reveal which parties are attempting to impersonate a domain and which departments are being targeted. These XML-based reports show sending IP addresses, message volumes, and authentication pass and fail rates for every source claiming to send from the domain, and security teams that analyze this data can identify impersonation patterns: which executives' names are being spoofed, whether finance or HR faces the heaviest cyberattack volume, and whether specific campaigns target new hires or senior leadership.

This intelligence directly shapes phishing simulation strategy. If DMARC reports show that cyberattackers are impersonating the CFO in vendor payment requests, the cybersecurity awareness training team can build role-specific phishing simulations that train the accounting department to recognize exactly that scenario. The same reports surface which legitimate third-party services send on the domain's behalf, enabling precise SPF and DKIM configuration that reduces false positives and keeps training scenarios focused on real-world attack patterns rather than hypothetical ones.

Why Technical Controls and Human Training Are Complementary Rather Than Alternatives

DMARC stops domain spoofing, but it cannot stop a cyberattacker who registers a lookalike domain or one who compromises a legitimate third-party account and sends phishing from a trusted address. These cyberattacks pass authentication checks because they technically are authenticated, so only a trained employee who pauses to examine the sender's full domain, questions an unusual payment request, or reports the message through a phishing alert button can stop them.

The complementary relationship runs both ways. When employees report fewer spoofed-domain emails because DMARC already blocks them, security analysts spend less time triaging the same noisy category of alerts and more time investigating the sophisticated cyber threats that bypass technical controls. Phishing report quality rises as the signal-to-noise ratio improves, and the security team's investigative bandwidth shifts from volume management to threat hunting.

The two layers function as a filter cascade. DMARC and other technical controls block the highest-volume, lowest-effort cyberattacks, while phishing simulations and cybersecurity awareness training prepare employees for the targeted, high-effort cyberattacks that survive. Neither layer alone is sufficient, but together they reduce the probability of a successful breach across every attack surface that email creates, and the filter is only as strong as the human judgment behind it.

How Adaptive Security Strengthens Anti-Phishing Defense Beyond DMARC Policies

DMARC policies at p=reject close the exact-domain spoofing vector, but the highest-impact cyberattacks now arrive from lookalike domains, compromised vendor accounts, and AI-generated deepfake campaigns that pass authentication cleanly. Adaptive Security addresses that residual risk directly. Its Cloud Email Security connects to Google Workspace or Microsoft 365 through a read-only API with no MX record changes, then uses layered AI detection, combining behavioral signals, intent analysis, and LLM reasoning, to catch the phishing and business email compromise that native filters and authentication records miss, quarantining each cyber threat across every affected inbox automatically.

The outcome is a workforce that stops absorbing the cyberattacks the technical layer cannot block. Every cyber threat Adaptive Security detects feeds directly into the same platform organizations use for phishing simulations, cybersecurity awareness training, and employee risk scoring, so a spoofed message that slips through becomes the specific lesson assigned to the employee it targeted. Adaptive Security also extends protection beyond the inbox with AI Governance that surfaces shadow AI and enforces acceptable-use policy, and Compliance Training that maps directly to the PCI DSS, HIPAA, and NIS2 obligations DMARC enforcement supports, giving security teams one system rather than a stack of disconnected tools.

That consolidation is what turns email authentication from a standalone DNS control into part of a complete human security program. DMARC policies handle the infrastructure, while Adaptive Security handles the people and the AI-era cyberattacks aimed at them, closing the gap that spoofing protection alone leaves wide open. The result is measurable readiness against the cyber threats that reach employees regardless of how well a domain is authenticated.

Reaching p=reject still leaves employees exposed to lookalike-domain phishing, compromised vendor accounts, and AI-generated deepfakes. Adaptive Security combines email security, phishing simulations, and awareness training in one platform.

Take a self-guided tour

Frequently Asked Questions About DMARC Policies

Is a DMARC Policy Required for Compliance With Google and Yahoo's 2024 Sender Requirements?

Yes. Starting February 2024, Google and Yahoo require any organization sending more than 5,000 emails per day to publish a DMARC policy with at least p=none, alongside properly configured SPF and DKIM. The p=none policy satisfies the compliance checkbox by establishing a DMARC record and enabling reporting, but it does not instruct receiving servers to take any action against unauthenticated messages, so organizations that stop at p=none remain fully exposed to domain spoofing. The mandate also requires senders to maintain valid forward and reverse DNS, use a TLS connection for transmitting email, and include a one-click unsubscribe mechanism in marketing messages. Senders below the threshold still benefit from DMARC authentication voluntarily through improved deliverability and domain reputation.

What Percentage of Organizations Have Actually Reached DMARC Enforcement With p=quarantine or p=reject?

Enforcement remains the exception rather than the rule, though the exact percentage depends heavily on which domains are sampled. As the EasyDMARC 2026 DMARC Adoption Report cited earlier found, more than half of all domains with a valid DMARC record remain at p=none, which provides no protection against spoofing. Broader scans that include all internet domains rather than only those with a DMARC record show even lower enforcement, because most domains have no record at all. The gap is widest among the internet's highest-traffic domains, where operational complexity and multiple third-party sending platforms slow the transition to enforcement. The practical takeaway is that publishing a record is now common, but reaching p=reject remains rare across every population measured.

How Long Should a DMARC Policy Stay at p=none Before Moving to Quarantine or Reject?

Most organizations should stay at p=none for a minimum of 30 days to collect enough DMARC aggregate reports to identify all legitimate sending sources, according to PowerDMARC's deployment guidance. In practice, the timeline varies by email infrastructure complexity. Small businesses with a handful of sending services typically progress within 4 to 8 weeks, mid-market organizations with CRM platforms, marketing automation, and transactional email services often need 8 to 16 weeks, and enterprises managing large domain portfolios, multiple business units, and complex third-party sender relationships may require 3 to 12 months. The key decision gate is data confidence more than calendar time, because a domain is ready to advance when every legitimate sending source appears in reports with passing SPF or DKIM authentication and no unexplained failures remain.

Can a DMARC Policy Set to p=reject Accidentally Block Legitimate Business Email?

Yes, and this is the most common reason organizations hesitate to move beyond p=none. A p=reject policy instructs receiving mail servers to reject any message that fails DMARC authentication, so if the SPF or DKIM configuration is incomplete, legitimate email from authorized third-party services will be blocked. The most frequent culprit is email forwarding, because when a recipient forwards a message, the forwarding server is not listed in the SPF record, which causes SPF alignment to break. Other common failure points include forgotten marketing platforms, CRM relays, ticketing systems, and transactional email providers never added to authentication records. Mitigation requires thorough monitoring at p=none, comprehensive discovery of all sending services, and gradual enforcement using the pct= tag before moving to full p=reject.

What Happens if an Organization Does Not Publish a DMARC Policy at All?

Without a published DMARC policy, receiving mail servers have no instructions from the domain about how to handle unauthenticated messages. Cyberattackers can send email that appears to come from the domain with no automated defense to stop it, making the domain a free target for exact-domain spoofing used in phishing campaigns, business email compromise, and brand impersonation. The organization also forfeits visibility into which sources send email under its name, because DMARC reports reveal unauthorized senders and authentication gaps that remain invisible without a record. Major mailbox providers including Google and Microsoft increasingly treat domains without DMARC as higher-risk, degrading deliverability. For domains that never send email, publishing p=reject with a null SPF record is the recommended minimum, and even with full DMARC enforcement, employees remain exposed to lookalike-domain phishing and social engineering tactics no authentication protocol can stop.

Authentication answers who can spoof a domain, but not whether employees can spot phishing that authenticates cleanly and reaches them anyway. Adaptive Security builds that readiness with realistic, multi-channel phishing simulations.

Take a self-guided tour