Table of Contents
Last Updated
Do not index
IntroductionHow DMARC WorksThe Three DMARC Policiesp=none (Monitor Mode)p=quarantine (Spam Filtering)p=reject (Full Enforcement)How DMARC Affects Email DeliverabilitySetting Up DMARC: Step by StepOther Things You Need to Know About DMARC Policy
Introduction
A DMARC policy is a DNS record that tells receiving mail servers what to do when an email claiming to come from your domain fails SPF and DKIM authentication. There are three settings: p=none, which monitors without acting; p=quarantine, which routes failing emails to spam; and p=reject, which blocks them outright. Since 2024, Gmail and Yahoo require at least p=none for any domain sending more than 5,000 messages per day, and domains without DMARC face rejection entirely.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It was defined under RFC 7489 and built on work that PayPal pioneered with Yahoo Mail and Gmail in 2007, when they collaborated on a system to identify and block spoofed emails impersonating PayPal's domain. That collaboration proved so effective at reducing fraudulent email that it became the foundation for the DMARC standard published by the IETF in 2015.
Understanding what each DMARC policy does, when to use it, and how to transition between them is critical for both email security and deliverability. A misconfigured policy can block your own legitimate emails. No policy at all leaves your domain wide open for anyone to impersonate.
How DMARC Works
When an email arrives at a receiving server, the server runs two authentication checks before evaluating DMARC. First, it checks SPF to verify whether the sending server's IP address is authorized to send on behalf of the claimed domain. Second, it checks DKIM to verify the cryptographic signature attached to the email hasn't been tampered with in transit.
DMARC adds a third layer: alignment. It checks whether the domain in the visible "From" header matches the domains used in the SPF and DKIM checks. An email can technically pass SPF and DKIM but still fail DMARC if the authenticated domains don't align with the From address. This alignment requirement is what prevents attackers from spoofing your domain while authenticating through their own infrastructure.
If the email passes DMARC (meaning at least one of SPF or DKIM passes with proper alignment), it proceeds through normal delivery. If it fails, the receiving server checks your DMARC policy to decide what to do next.
DMARC also generates reports. Aggregate reports (sent to the address specified in your rua tag) provide a daily summary of authentication results across all emails sent from your domain. Forensic reports (ruf tag) provide details on individual failures. These reports are essential for understanding who's sending email on behalf of your domain, and whether legitimate services are passing or failing authentication.
The Three DMARC Policies
.png?table=block&id=34016483-6d68-8049-8999-f5949c782dd5&cache=v2)
p=none (Monitor Mode)
This is the starting point for every DMARC implementation. A policy of p=none tells receiving servers to take no action on emails that fail authentication. Every message, whether it passes or fails, gets delivered normally.
The purpose of p=none is purely observational. It collects DMARC aggregate reports so you can see every IP address and service sending email using your domain. This visibility is critical because most organizations don't realize how many services send email on their behalf until they look at the data. Marketing platforms, CRM systems, helpdesk tools, transactional email services, legacy applications; they all show up in the reports.
What p=none does not do is protect your domain. According to research cited by Sendmarc, only 19.6% of worldwide email domains with published DMARC policies are fully protected with p=reject. The rest are sitting at p=none or p=quarantine, and p=none provides zero defense against domain spoofing. Attackers can freely impersonate your domain, and every forged email reaches recipients unimpeded.
NoSpamProxy's analysis goes further, arguing that p=none is actually worse than having no DMARC record at all in some scenarios. Certain email gateways that follow RFCs strictly will not reject emails from domains with p=none, even when SPF and DKIM fail, because the domain owner has explicitly instructed servers to take no action. Without any DMARC record, those same gateways might apply their own filtering logic and catch the spoofed email independently.
Use p=none for two to four weeks while you audit your aggregate reports. Identify every legitimate sending source. Fix any SPF or DKIM issues. Then move to enforcement.
p=quarantine (Spam Filtering)
A policy of p=quarantine tells receiving servers to treat emails that fail DMARC with increased suspicion. In practice, this means the emails get routed to the spam or junk folder rather than the inbox.
Quarantine is the middle step between monitoring and full enforcement. It protects recipients from most spoofing attempts while giving you a buffer to catch any legitimate services that are still failing authentication. If an internal system you forgot about is sending email without proper DKIM, those messages land in spam instead of being blocked entirely, giving you time to fix the configuration before moving to reject.
The Verizon Data Breach Investigations Report has consistently identified phishing as a leading cause of data breaches, and most phishing attacks start with a spoofed email domain. Moving from p=none to p=quarantine significantly reduces the effectiveness of these attacks because spoofed emails no longer reach the inbox where they'd be most dangerous.
One important detail from dmarcian's research: the impact of quarantine on legitimate but non-compliant email is not immediately obvious. Because quarantined messages are still delivered (just to spam), the source of those emails may not realize they're being filtered. The sender sees no bounce notification. Open rates silently drop, and nobody on the sending side understands why.
DMARC includes a "pct" tag that lets you roll out quarantine gradually. Setting pct=10 applies the quarantine policy to only 10% of failing emails. You can increase this over weeks as you confirm that legitimate email isn't being affected. Once you reach pct=100 with no issues, you're ready for reject.
p=reject (Full Enforcement)
A policy of p=reject tells receiving servers to refuse delivery of any email that fails DMARC authentication. The email never reaches any folder. It's blocked at the SMTP level before the recipient ever sees it.
This is the strongest protection against domain spoofing. An attacker who sends a phishing email using your domain as the From address will have that email rejected by every provider that checks DMARC. Your customers, partners, and employees never see the spoofed message.
According to dmarc.org, the system was originally developed from the 2007 PayPal and Yahoo collaboration, which led to a significant decrease in suspected fraudulent email purporting to be from PayPal. That same principle applies to every domain at p=reject: if the email doesn't pass authentication, it doesn't get through.
The risk of p=reject is that it also blocks legitimate emails that fail authentication. If a third-party service sends email on your behalf without proper SPF and DKIM configuration, those emails get rejected along with the spoofed ones. This is why the progression from p=none to p=quarantine to p=reject matters. Each step gives you the visibility and confidence to ensure that legitimate email is fully authenticated before you enforce the strictest policy.
How DMARC Affects Email Deliverability
DMARC's impact on deliverability goes beyond security. Gmail, Microsoft, and Yahoo all use DMARC compliance as a positive signal for inbox placement. Domains with p=reject and clean authentication records consistently achieve better deliverability than unauthenticated domains.
Since 2024, Google and Yahoo require DMARC for bulk senders sending more than 5,000 emails per day. Domains without DMARC face increased filtering and potential rejection. Microsoft has signaled similar requirements for Outlook and Exchange Online. In 2026, running a domain without DMARC isn't just a security risk; it's a deliverability liability.
DMARC is also a prerequisite for BIMI (Brand Indicators for Message Identification). Displaying your brand logo next to emails in Gmail and Apple Mail requires DMARC at enforcement level (quarantine or reject). You can't unlock BIMI's branding benefits without first getting your DMARC to enforcement.
Mailwarm's infrastructure health check audits your SPF, DKIM, and DMARC configuration, showing you exactly what's passing, what's failing, and what needs to be fixed before you can move to enforcement. Combined with continuous warmup that builds positive engagement signals, it ensures that tightening your DMARC policy improves rather than harms your inbox placement.
Setting Up DMARC: Step by Step
.png?table=block&id=34016483-6d68-80b3-95c7-fcd4ecbfef30&cache=v2)
Publishing a DMARC record takes about five minutes. Getting to enforcement safely takes two to six weeks of monitoring.
Create a TXT record in your domain's DNS at _dmarc.yourdomain.com. The initial record should look like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. This publishes DMARC in monitoring mode and sends aggregate reports to the specified email address. You can use a free DMARC report parser to make sense of the XML data, or use tools like MXToolbox's DMARC analyzer, MailX DMARC monitoring service, or Google's Postmaster Tools alongside your reports.
Monitor for two to four weeks. Review the aggregate reports to identify every service sending email from your domain. Fix any SPF or DKIM failures on legitimate services.
Move to quarantine with a percentage: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com
Increase the percentage over several weeks until you reach pct=100 with no issues.
Move to reject: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
Continue monitoring aggregate reports after enforcement. New services get added, configurations change, and DMARC needs ongoing attention to remain effective.
Other Things You Need to Know About DMARC Policy
What happens if I have no DMARC record at all?
Without DMARC, receiving servers have no instructions for handling emails that fail SPF or DKIM. They rely entirely on their own filtering logic, which varies by provider. Gmail and Yahoo now require DMARC for bulk senders, so domains without it face increased filtering or rejection of their email.
Can I use different DMARC policies for subdomains?
Yes. The "sp" tag sets the policy for subdomains. You can enforce p=reject on your main domain while keeping sp=quarantine on subdomains, or vice versa. This is useful when subdomains are managed by different teams or services.
How often are DMARC aggregate reports sent?
Most providers send aggregate reports daily. Gmail, Outlook, and Yahoo all generate reports on a 24 hour cycle. The volume of reports depends on how many providers receive email from your domain.
Does DMARC work without SPF and DKIM?
DMARC requires at least one of SPF or DKIM to be deployed. It evaluates authentication based on their results. Without either, there's nothing for DMARC to evaluate, and the record serves no purpose.
What's the difference between strict and relaxed alignment?
Strict alignment (adkim=s or aspf=s) requires an exact domain match between the From header and the authenticated domain. Relaxed alignment (adkim=r or aspf=r) allows subdomain matching. Relaxed is the default and is appropriate for most implementations. Strict alignment is more secure but can cause failures when sending from subdomains.
Will moving to p=reject break my email?
Only if legitimate services sending on your behalf haven't been properly authenticated. This is why the monitoring phase (p=none) exists. Use it to identify every sending source and fix authentication before enforcing. Skipping the monitoring phase and going straight to reject is the most common cause of self-inflicted deliverability damage.