Simple DMARC examples: how to start with a p=none policy

When you first dive into the world of email deliverability and security, you quickly encounter a trio of acronyms: SPF, DKIM, and DMARC. While all are important, DMARC (Domain-based Message Authentication, Reporting, and Conformance) acts as the policy layer that tells the world how to handle emails claiming to be from your domain. It’s your way of protecting your brand’s reputation from phishing and spoofing attacks.

At its core, DMARC leverages the results of SPF and DKIM checks to verify if an email is authentic. But it goes a step further by giving you, the domain owner, control. You can tell receiving mail servers what to do with messages that fail these checks. This is handled by a DMARC "policy," which can range from doing nothing at all to outright rejecting the email.

For anyone just starting out, the single most important piece of advice is to begin with the most permissive policy: p=none. This is often referred to as a "monitor-only" policy. It’s a completely safe way to dip your toes into the DMARC waters, allowing you to gather data without any risk of your legitimate emails being accidentally blocked or sent to spam.

So, what exactly does a p=none policy do? In short, nothing that impacts your email delivery. When a receiving server sees a DMARC record with p=none, it is instructed not to take any specific action against messages that fail DMARC authentication. The email will be delivered to the recipient's inbox or spam folder based on the server's own filtering rules, just as it would if you had no DMARC record at all.

This might sound counterintuitive. If it doesn’t do anything, what’s the point? The magic of the p=none policy lies in its reporting capability. By including a rua tag in your DMARC record, you ask mailbox providers to send you daily aggregate reports. These reports are a goldmine of information.

These reports detail all the activity for your domain, including which servers and services are sending email on your behalf and whether those emails are passing or failing SPF and DKIM checks. This gives you the visibility needed to understand your email ecosystem. You'll see your legitimate mail streams, but you may also uncover unauthorized services or malicious actors trying to impersonate your domain. Starting with a "none" policy to monitor your email sources is the critical first step toward securing them.

Creating your first DMARC record is surprisingly straightforward. It's just a TXT record that you add to your domain's DNS settings. The record needs to be placed at the specific hostname _dmarc.yourdomain.com, replacing yourdomain.com with your actual domain.

Here is the most basic, yet fully functional, DMARC record you can use to get started. It sets the policy to none and tells receivers where to send the aggregate reports. This is the perfect starting point for virtually any domain.

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

Let's break down what each part of that record means:

• v=DMARC1: This tag is mandatory and identifies the record as a DMARC record. The version is always DMARC1.
• p=none: This sets the policy to "none," or monitor mode, as we've discussed. It tells receivers not to take any specific action on failing emails.
• rua=mailto:dmarc-reports@yourdomain.com: This is the reporting instruction. It tells receivers to send their aggregate XML reports to the specified email address. You should replace this with an actual email address you control.

While the basic record works perfectly, you can add a few other tags to get more specific, even with a p=none policy. These tags provide more granular control and reporting options as you become more comfortable with DMARC.

Two other common tags you might see are pct and ruf.

• pct=100: The pct or "percentage" tag tells receivers what percentage of failing messages to apply the policy to. With p=none, it doesn't have a practical effect on delivery, but it's good practice to include it. A value of 100 means the policy applies to 100% of emails. This becomes very important when you later move to quarantine or reject.
• ruf=mailto:forensic-reports@yourdomain.com: The ruf tag is used to request forensic, or failure, reports. These are real-time reports sent for individual email failures and can contain snippets of the email content. Due to their volume and potential privacy implications, not all receivers send them, and many administrators choose to omit this tag initially.

A slightly more advanced, but still very common, p=none record might look like this. It specifies the percentage and includes an address for the more detailed forensic reports.

v=DMARC1; p=none; pct=100; rua=mailto:agg-reports@yourdomain.com; ruf=mailto:fail-reports@yourdomain.com;

Publishing your p=none DMARC record is a fantastic first step, but the real work begins when the reports start arriving. These reports are typically sent daily in a compressed XML format, which is not very human-readable. You can use a DMARC analysis tool or service to parse these files into digestible charts and tables.

The goal of this phase is simple: identify every single service that sends email for your domain. This includes everything from your primary mail provider like Google Workspace or Microsoft 365, to your marketing platform, your CRM, your helpdesk software, and any custom applications that send transactional emails.

As you review your reports, you will build a list of all your sending sources. For each legitimate source, you must ensure it is correctly configured to send DMARC-aligned email. This means making sure its messages pass SPF and/or DKIM for your domain. Once all your known, legitimate traffic is passing DMARC, you can begin the process of moving to a stricter policy like p=quarantine to start protecting your domain.

In conclusion, implementing a DMARC policy of p=none is the safest and most effective way to begin your email authentication journey. It provides invaluable insight into your email sending landscape without any risk of disrupting legitimate mail flow. By starting with this simple monitoring policy, you lay the groundwork for a more secure email program, building the confidence and data needed to eventually move to a full enforcement policy that actively blocks fraudulent email.

The benefits of implementing DMARC

Matthew Whittaker

6 Jul 2025

Discover the essential benefits of implementing DMARC for your email. This article explains how DMARC enhances your security by preventing domain spoofing and phishing, boosts deliverability by improving your sender reputation, and provides invaluable visibility into your email ecosystem. Learn why DMARC is a non-negotiable tool for protecting your brand and ensuring your messages reach the inbox.

A practical guide to finding a DMARC professional

Michael Ko

9 Jul 2025

Learn how to find, vet, and hire a DMARC professional to secure your email and improve deliverability. This guide covers what to look for in an expert, where to find them, and the key questions to ask to ensure you're protecting your brand from phishing and spoofing.

Why your emails are getting a 'DMARC verification failed' error

Michael Ko

10 Jul 2025

Getting a 'DMARC verification failed' error? This post breaks down what it means, the common causes like alignment issues with SPF and DKIM, and how to fix it. Learn how to diagnose problems using DMARC reports and a step-by-step approach to secure your domain without blocking legitimate emails.

How to fix 'DMARC policy not enabled' warnings

Matthew Whittaker

11 Jul 2025

Seeing a 'DMARC policy not enabled' warning can be confusing. This message doesn't mean something is broken, but rather that your DMARC policy is set to a monitoring-only mode (p=none) and not yet enforcing protection. This guide explains what the warning means, why starting with p=none is a critical first step, and how to methodically analyze your email sources to safely transition to an enforcement policy like p=quarantine or p=reject, ultimately securing your domain and improving deliverability.

A simple guide to DMARC, SPF, and DKIM

Matthew Whittaker

11 Jul 2025

Ever felt lost in the alphabet soup of email security? This guide breaks down DMARC, SPF, and DKIM into simple concepts. We'll explain how SPF creates a guest list for your emails, DKIM adds a tamper-proof seal, and DMARC acts as the security chief, telling mail servers how to handle unverified messages, ensuring your emails are trusted and secure.

How to switch DMARC providers without interrupting email delivery

Michael Ko

11 Jul 2025

Switching DMARC providers can seem daunting, but it's a manageable process that can unlock better analytics and control over your email security. This guide provides a step-by-step walkthrough, covering everything from pre-migration auditing to post-migration verification, ensuring you can make the switch without disrupting email delivery or losing valuable DMARC data.