DMARC Policy Guide: From None to Reject in 4 Steps

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that ties SPF and DKIM together and tells receiving servers what to do when a message fails authentication. Without DMARC, a mailbox provider might silently pass, quarantine, or reject unauthenticated email based on its own internal rules. With DMARC, you explicitly define the handling policy for your domain.

This guide walks through the entire DMARC implementation process, from publishing your first monitoring-only record to reaching full enforcement with a reject policy.

Why DMARC Matters#

Email spoofing remains one of the most common attack vectors. An attacker can forge the "From" header of an email to make it appear as though the message came from your domain. Without DMARC, receiving servers have no reliable way to know your intent for handling such messages.

DMARC solves three problems:

• Phishing prevention: It stops attackers from sending emails that look like they came from your domain.
• Brand protection: It prevents your domain from being used in scam campaigns that damage your reputation.
• Visibility: DMARC reports show you exactly who is sending email using your domain, including legitimate services you may have forgotten about and unauthorized senders you did not know existed.

Major mailbox providers including Google, Microsoft, and Yahoo now require DMARC for bulk senders. As of 2024, Google requires domains sending more than 5,000 emails per day to Gmail addresses to have a DMARC policy published.

How DMARC Works with SPF and DKIM#

DMARC does not perform its own authentication checks. Instead, it evaluates the results of SPF and DKIM and applies an additional requirement called alignment.

The Alignment Requirement#

For DMARC to pass, at least one of the following must be true:

1. SPF passes AND the SPF-authenticated domain aligns with the "From" header domain. SPF checks the envelope sender (Return-Path). DMARC requires that this domain matches (or is a subdomain of) the domain in the visible "From" header.

2. DKIM passes AND the DKIM-signed domain (d= tag) aligns with the "From" header domain. The domain in the DKIM signature must match (or be a subdomain of) the "From" header domain.

Alignment can be either strict (exact domain match) or relaxed (subdomains are allowed). Relaxed alignment is the default and works for most configurations.

Why Alignment Matters#

Without alignment, an attacker could set up SPF and DKIM for attacker.com, send a message with From: ceo@yourcompany.com, and the email would pass SPF and DKIM checks (for attacker.com), but the recipient sees your domain. DMARC alignment closes this gap by requiring that the authenticated domain matches what the user sees.

DMARC Record Syntax#

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here is a complete example:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;

Tag Reference#

Tag	Required	Description	Values
v	Yes	Protocol version	Always DMARC1
p	Yes	Policy for the domain	none, quarantine, reject
rua	No*	Aggregate report recipients	mailto: URI
ruf	No	Forensic report recipients	mailto: URI
pct	No	Percentage of messages to apply policy to	1-100 (default: 100)
aspf	No	SPF alignment mode	r (relaxed, default) or s (strict)
adkim	No	DKIM alignment mode	r (relaxed, default) or s (strict)
sp	No	Subdomain policy	none, quarantine, reject
fo	No	Failure reporting options	0, 1, d, s

*While rua is technically optional, you should always include it. Without aggregate reports, you are publishing a policy blind with no way to see what is happening.

Policy Values Explained#

• none: Monitor only. Messages that fail DMARC are delivered normally. You receive reports showing authentication results, but no action is taken. This is the starting point.
• quarantine: Messages that fail DMARC are treated as suspicious. Typically they are placed in the recipient's spam or junk folder.
• reject: Messages that fail DMARC are rejected outright. The receiving server returns an error and the message is not delivered.

Failure Reporting Options (fo tag)#

• 0 (default): Generate a report only if both SPF and DKIM fail alignment.
• 1: Generate a report if either SPF or DKIM fails alignment. This is more useful for debugging and is the recommended setting.
• d: Generate a report if DKIM fails, regardless of alignment.
• s: Generate a report if SPF fails, regardless of alignment.

The 4-Step Progression to Full Enforcement#

Jumping straight to p=reject without preparation is dangerous. You might block legitimate email from services you forgot you were using. The safe approach is a gradual progression.

Step 1: Deploy with p=none (Monitor)#

Start with a monitoring-only policy to collect data without affecting mail delivery.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

What to do during this phase:

• Publish the record and wait at least 2 to 4 weeks to collect sufficient report data.
• Review aggregate reports to identify all legitimate sources of email for your domain. This includes your primary mail server, marketing platforms (Mailchimp, SendGrid, HubSpot), transactional email services, CRM systems, ticketing systems, and any SaaS tools that send email on your behalf.
• For each legitimate source, ensure SPF is configured (include the service's sending IPs in your SPF record) and DKIM is set up (publish the service's DKIM public key in your DNS).
• Investigate any sources you do not recognize. These could be either forgotten legitimate services or unauthorized senders.

Duration: 2 to 4 weeks minimum. Longer if you have a complex sending infrastructure.

Step 2: Move to p=quarantine at 25% (Soft Enforcement)#

Once you are confident that all legitimate sources pass DMARC, begin enforcement on a small percentage of traffic.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

This tells receiving servers to quarantine (typically send to spam) 25% of messages that fail DMARC. The other 75% are treated as if the policy were none.

What to do during this phase:

• Monitor reports closely for any increase in DMARC failures from legitimate sources.
• If you discover a new legitimate sender that was missing SPF or DKIM, fix the configuration before proceeding.
• Watch for reports of legitimate email landing in spam folders.
• If everything looks clean after 1 to 2 weeks, move to the next step.

Duration: 1 to 2 weeks.

Step 3: Increase to p=quarantine at 100% (Full Quarantine)#

Remove the percentage limit so the quarantine policy applies to all failing messages.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Or simply omit the pct tag, since 100 is the default:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

What to do during this phase:

• Continue monitoring reports.
• Verify that no legitimate email is being quarantined.
• Communicate with your team to check if anyone reports missing emails.
• After 2 to 4 weeks with no issues, you are ready for the final step.

Duration: 2 to 4 weeks.

Step 4: Enforce p=reject (Full Protection)#

This is the final state. Messages that fail DMARC are rejected entirely.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

At this point, anyone attempting to send email from your domain without proper authentication will have their messages rejected. Your domain is fully protected against spoofing.

Ongoing maintenance:

• Continue reviewing aggregate reports at least monthly.
• When you add a new email-sending service, configure SPF and DKIM for it before sending.
• Rotate DKIM keys periodically and verify that new keys pass DMARC.
• Consider adding ruf for forensic reports if your mailbox supports the volume.

Reading DMARC Reports#

Aggregate Reports (rua)#

Aggregate reports are XML files sent daily by receiving servers. They contain:

• The reporting server's organization name.
• The date range covered.
• Your published DMARC policy.
• For each source IP that sent email using your domain: the number of messages, SPF/DKIM/DMARC results, and alignment outcomes.

A simplified excerpt from an aggregate report looks like this:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Raw XML is difficult to read at scale. Most organizations use a DMARC report analysis service or tool to parse and visualize the data. Services like Postmark's free DMARC monitoring, dmarcian, or EasyDMARC can help.

Forensic Reports (ruf)#

Forensic reports contain details about individual messages that failed DMARC, including message headers and sometimes partial content. They are useful for investigating specific spoofing incidents but generate high volumes and may contain sensitive information. Many receivers no longer send forensic reports due to privacy concerns.

Common DMARC Pitfalls#

1. Publishing p=reject Without Monitoring First#

This is the most dangerous mistake. If any legitimate email service is not properly configured with SPF and DKIM, those messages will be rejected. Always start with p=none and review reports.

2. Forgetting About Third-Party Senders#

The most common cause of DMARC failures from legitimate sources is forgetting about a SaaS tool that sends email using your domain. Common culprits include:

• Marketing automation platforms
• Customer support ticketing systems
• CRM platforms that send email on your behalf
• Invoice and accounting software
• HR and recruiting tools
• Calendar and scheduling tools

Audit every service connected to your domain before moving past p=none.

3. SPF Record Exceeding 10 DNS Lookups#

SPF has a hard limit of 10 DNS lookup mechanisms (include, a, mx, redirect, exists). If your SPF record exceeds this limit, SPF evaluation returns a "permerror," which means SPF effectively fails for all messages. Since DMARC requires either SPF or DKIM to pass with alignment, an SPF permerror puts more pressure on DKIM.

If you have many sending services, consider flattening your SPF record or using a subdomain strategy where different services send from different subdomains.

4. Not Using rua#

Without aggregate reports, you have no visibility into how your domain's email is being authenticated. Always include a rua tag, even with p=none.

5. Subdomains Without sp= Tag#

By default, if you do not set the sp tag, subdomains inherit the parent domain's policy. If you use subdomains for different purposes (e.g., marketing.yourdomain.com), consider setting an explicit subdomain policy or publishing separate DMARC records for each subdomain.

6. Ignoring DMARC After Reaching Reject#

DMARC is not a "set it and forget it" configuration. New sending services get added, keys expire, SPF records get modified. Continue reviewing aggregate reports monthly to catch regressions.

Checking Your DMARC Configuration#

You can check your current DMARC record by querying DNS:

dig TXT _dmarc.yourdomain.com

For a comprehensive check that evaluates your DMARC alongside SPF, DKIM, MX records, and blacklist status, use Nova Uptime's free Email Health Checker. The tool gives you a score out of 100, a letter grade (A through F), and specific recommendations for improving your DMARC policy.

The tool evaluates your DMARC policy strictness as part of the scoring. A p=reject policy with aggregate reporting earns the highest score, while p=none or a missing DMARC record results in significant point deductions. This gives you a clear picture of where your domain stands and what steps to take next.

DMARC Implementation Timeline#

Here is a realistic timeline for a full DMARC deployment:

Week	Action	DMARC Record
1	Publish monitoring record, set up report processing	p=none; rua=mailto:...
2-4	Review reports, fix SPF/DKIM for all legitimate senders	p=none; rua=mailto:...
5-6	Soft enforcement at 25%	p=quarantine; pct=25; rua=mailto:...
7-8	Full quarantine	p=quarantine; rua=mailto:...
9-12	Full enforcement	p=reject; rua=mailto:...
Ongoing	Monthly report review, maintain configurations	p=reject; rua=mailto:...

For organizations with simple email infrastructure (one primary mail service, one or two marketing tools), this can be compressed to 4 to 6 weeks. For enterprises with dozens of sending services, allow 3 to 6 months.

Key Takeaways#

• DMARC builds on SPF and DKIM by adding policy enforcement and alignment requirements.
• Always start with p=none and aggregate reporting. Never jump straight to p=reject.
• Use the pct tag to gradually increase enforcement.
• Review aggregate reports to identify all legitimate email sources before enforcing.
• Reaching p=reject is the goal, but it requires preparation.
• Continue monitoring after deployment. DMARC requires ongoing maintenance.
• Use Nova Uptime's Email Health Checker to verify your DMARC configuration and get a full email authentication assessment.

A properly implemented DMARC policy is one of the strongest protections you can deploy for your domain. It prevents spoofing, builds trust with mailbox providers, and gives you clear visibility into who is sending email on your behalf.

Frequently Asked Questions#

What is a DMARC check?#

A DMARC check verifies whether your domain has a valid DMARC DNS record and evaluates its policy settings. It confirms that your DMARC record syntax is correct, your policy (none/quarantine/reject) is properly configured, and your reporting addresses are functional. Run a free DMARC check to see your current configuration.

Is free DMARC monitoring possible?#

Yes. Nova Uptime includes DMARC monitoring as part of its email health checker. It checks your DMARC record alongside SPF, DKIM, and blacklist status on a configurable schedule and alerts you when something changes. The free plan covers up to 5 domains.

How long does it take to reach p=reject?#

For most organizations, the progression from p=none to p=reject takes 2-4 months. The timeline depends on how many legitimate email sources you need to identify and authenticate. Rushing to reject without reviewing DMARC reports risks blocking your own legitimate email.

What happens if I set DMARC to reject without SPF and DKIM?#

Your emails will be rejected by receiving servers. DMARC enforcement requires at least one of SPF or DKIM to pass AND align with your From domain. Set up SPF and DKIM first, then progress DMARC from none to reject gradually.

Related Reading#

• SPF, DKIM & DMARC: Complete Guide — How all three protocols work together
• DMARC Test & Configuration Guide — Advanced DMARC policy configuration
• Email Blacklist Check & Removal Guide — What to do when authentication issues lead to blacklisting
• Email Deliverability Checklist — 15 steps to improve inbox placement
• Free Email Health Checker — Check DMARC, SPF, DKIM, and blacklists in one scan