DMARC

Introduction

Email Security provides DMARC Management as an add-on to help manage DMARC and SPF.

DMARC Management helps organizations make sure all legitimate senders are allowed so that you can confidently apply a restrictive policy tag in your organization's DMARC DNS record.

The organization's DMARC DNS record - specifically the p tag - states what should be done with emails that fail authentication checks.

Three possible values to the p tag in the DMARC record:

none - recipients should report failures, but should also deliver emails allegedly from the domain even if they fail authentication.
quarantine - recipients should quarantine emails that fail authentication. They would usually be marked as spam.
reject - recipients should not even accept the email and never deliver it to their end users.

Since this is usually a difficult task, most organizations do not have a DMARC policy (p) tag at all or assign the value none to it.

Benefits

DMARC Management helps you safely transition to a restrictive DMARC policy. It includes:

Visibility to all the services sending emails on behalf of your domains and subdomains
Search all DMARC failed emails sent on the organization's behalf
Actionable DMARC record change recommendations.

DMARC Enforcement Policy Guidance

Choosing a DMARC Enforcement Policy
Reviewing Domains That Already Use p=reject
Recommended DMARC Enforcement Policies

Choosing a DMARC Enforcement Policy

According to the latest DMARC specification, RFC 9989, organizations should select a DMARC enforcement policy based on how a domain is used and the potential operational impact of failed DMARC validation. p=reject is no longer the recommended default final state for every domain. Instead, apply the policy that best matches the domain's mail flow, user behavior, and authentication maturity.

For domains used by human mailbox users or general-purpose email, p=quarantine is generally the recommended enforcement target. This approach provides meaningful protection against spoofing and reduces the risk of disrupting legitimate indirect mail flows, such as mailing lists, forwarders, aliases, and some third-party delivery paths.
For transactional, outbound-only, or tightly controlled sending domains, p=reject can still be appropriate, after validating that all legitimate senders pass DMARC with aligned DKIM, SPF, or both.

As a best practice, organizations should separate human mailbox domains from transactional sending subdomains so that each domain can use the most appropriate DMARC policy.

Reviewing Domains That Already Use `p=reject`

For domains that are already configured with p=reject, an automatic rollback is not recommended. Instead, organizations should review the DMARC aggregate reports, user complaints, mailing-list usage, and third-party sending paths:

If the domain is used by human users and there is evidence of legitimate mail disruption, move the domain back to p=quarantine.
If the domain is tightly controlled, and the authentication results are clean, keep the domain at p=reject.

Recommended DMARC Enforcement Policies


Domain Type	Recommended End State	Rationale
Human mailbox / general-purpose domain	Usually `p=quarantine`	Reduces the risk of disrupting legitimate indirect mail flows, such as mailing lists, forwarders, aliases, and third-party delivery paths.
Transactional / outbound-only subdomain	Often `p=reject`	Lower risk of user-driven indirect mail flows. Stronger anti-spoofing enforcement is reasonable after all legitimate senders authenticate correctly.
Non-sending domain or unused subdomain space	`p=reject`, often with `sp=reject` / `np=reject` where appropriate	These domains should not be used in the From header, so failed DMARC is a strong indicator of abuse.
Mixed-use apex domain	Prefer `p=quarantine` at the apex, with stricter policies on dedicated sending subdomains	Avoids applying one aggressive policy to mail streams with different risk profiles and operational requirements.

Prerequisites

Periodically, email receivers send aggregated reports containing information on all emails they received from your domain, the IP address from which they received the emails, and the authentication results (SPF and DKIM) for each IP address. These reports are sent to the email addresses (RUA mailbox) defined in your domain's DNS DMARC record with the rua tag.

Sample DMARC record content:

Email Security needs to get the aggregated DMARC RUA reports. To do that, you must configure the rua tag of your DMARC record:

Note:

The internal mailbox must be part of the scanned (protected) mailboxes.
Email Security supports both IPv4 and IPv6 for DMARC exploration.


Present RUA value	Change to
An internal mailbox	Email Security reads the value from the DNS record and monitors the internal mailbox.
A hosted mailbox	If you wish to use a hosted mailbox, you must add a Check Point hosted mailbox to your rua tag. For more information, see RUA Mailbox Hosted by Check Point.