Last updated: July 2026

In short: The p= (Policy) tag is the core required parameter in a DMARC record. It tells receiving mail servers what enforcement action to take against messages that fail SPF and DKIM authentication.

When deploying Domain-based Message Authentication, Reporting, and Conformance (DMARC), the p= tag defines your policy enforcement level. This setting applies across your entire domain and dictates whether unauthenticated emails are monitored, filtered, or blocked entirely.

The p= tag specification

According to RFC 7489, the p= tag is mandatory for policy records and automatically covers both the primary domain and all subdomains unless explicitly overridden by an sp= tag: p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag.

The protocol defines three distinct policy modes:

1. Monitoring mode (p=none)

A record configured with p=none requests no interference with mail delivery:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Under RFC 7489, this mode means: “none: The Domain Owner requests no specific action be taken regarding delivery of messages.”

In this state, receiving servers deliver messages normally even if they fail both SPF and DKIM alignment. The primary purpose of p=none is visibility: when paired with a reporting address (rua=), mailbox providers send daily XML reports detailing all servers sending on behalf of your domain. This allows you to identify legitimate third-party senders and fix authentication issues without risking email rejection.

2. Quarantine mode (p=quarantine)

Once you have verified all legitimate sending sources, the next step is p=quarantine:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

In this enforcement mode, unauthenticated messages are treated with suspicion rather than delivered to the inbox. According to RFC 7489: “quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious".”

In practice, receiving mail servers typically route failing emails directly to the recipient’s spam or junk folder.

3. Strict enforcement (p=reject)

The ultimate goal of every DMARC deployment is full protection under p=reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

According to RFC 7489, this policy instructs receivers to outright block unauthenticated mail during the initial connection: “reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction.”

Enforcing p=reject shuts the door on exact-domain spoofing and phishing attacks. If an unauthorized server attempts to send email using your domain name, receiving servers terminate the SMTP transaction immediately and bounce the message.

A safe DMARC deployment follows a phased approach:

  1. Publish p=none for at least two to four weeks and analyze aggregate reports to discover all legitimate sending tools.
  2. Advance to p=quarantine to catch edge-case misconfigurations while ensuring messages remain accessible in spam folders if needed.
  3. Enforce p=reject once authentication checks consistently pass across all legitimate streams.

Verifying your configuration

To check which policy mode your domain currently enforces and verify that your syntax complies with RFC specifications, test your domain using the free MXAudit scanner.

For more detailed technical concepts and provider-specific configuration guides, explore the DMARC hub and setup guides like IONOS DMARC setup.

Further reading