Start with p=none: audit your email before you enforce
Before you block a single message, publish p=none and collect a few weeks of DMARC reports. Here is what p=none does, and what the first reports tell you.
The safe first step in any DMARC rollout is p=none. It changes nothing about how your mail is delivered. All it does is switch on reporting so you can see who is sending email as your domain, and whether that mail passes the checks. You gather that data first, then you tighten your policy. Never the other way around.
What p=none actually does
DMARC (Domain-based Message Authentication, Reporting and Conformance) lets you publish a policy that tells receiving mail servers what to do with messages that claim to be from your domain but fail authentication. The policy lives in a DNS record, DNS being the public address book for your domain.
The policy is set with a p= tag, and it has three possible values:
p=none: change nothing, just send reports. Monitoring only.p=quarantine: treat failing mail as suspicious, usually routing it to spam.p=reject: refuse failing mail outright, so it never reaches the inbox.
Here is the important part, and the reason people can start without fear. p=none does not stop, delay, or divert any message. A receiver that gets a message failing your checks under p=none delivers it exactly as it would have with no DMARC record at all. Your newsletters, your invoices, your booking confirmations: all of them keep flowing. The only new behavior is that receivers start emailing you summaries of what they saw. You cannot break delivery with p=none, which is precisely why it is the place to begin.
Turn on aggregate reporting
Publishing a policy with nowhere to send reports is a wasted step. You turn on aggregate reporting with the rua= tag, which names an address where receivers post their daily summaries. A starter record looks like this:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
Read left to right, that says: this is a DMARC version 1 record (v=DMARC1), take no action on failing mail (p=none), and send aggregate reports to reports@yourdomain.com (rua=mailto:...). You publish it as a TXT record at _dmarc.yourdomain.com.
Aggregate reports, sometimes called RUA reports after the tag, are XML files. Each one summarizes the mail one receiver saw from your domain over a period, usually a day: which sending servers, how many messages, and whether each passed SPF, passed DKIM, and lined up with your visible From address. They contain no message content and no private information, just counts and results.
Give it two to four weeks
Collect at least two weeks of reports before you touch the policy, and four is better if your business sends on a monthly cycle, say payroll or end-of-month invoicing. The goal is to catch every legitimate system that sends on your behalf, and some of them only fire occasionally. A rollout that skips this step is the most common way people block their own mail later.
While the reports come in, resist the urge to change anything. You are building a picture, and the picture is not complete until the slow-moving senders have shown up.
What to look for in the first reports
Three questions matter, and every aggregate report speaks to them.
Who is sending as you
The first job is an inventory. List every source that appears sending mail with your domain in the From line. You are looking for the ones you expected: your mail provider, your marketing platform, your invoicing tool, your helpdesk. You are also looking for the ones you forgot, and there are almost always a few. An old CRM, a form on the website, a payment provider that sends receipts for you. If a source is sending as you and you do not recognize it, that is either a system to authorize or, occasionally, a spoofer to be aware of.
Which sources pass SPF and DKIM
SPF (Sender Policy Framework) is a list of servers allowed to send for your domain, and DKIM (DomainKeys Identified Mail) is a cryptographic signature that proves a message came from you and was not altered. For each source, the report shows whether it passed each check. A legitimate sender that fails both is one you have not set up correctly yet, and it needs fixing before you can safely enforce.
Which sources are aligned
Passing a check is not the whole story. The domain that passed SPF or DKIM has to match the domain your reader sees in the From line. This match is called alignment, and it is the piece that stops a scammer who authenticates their own domain from riding on yours. A source can pass SPF for some unrelated domain and still fail DMARC because it is not aligned with you. We cover this in more depth in how to align SPF and DKIM, and it is usually where the real work of a rollout sits.
Reading the picture
After a couple of weeks you should be able to say, for every stream of mail leaving your business: this is the source, it passes DKIM, it is aligned, it is fine. Where you cannot say that, you have a task: authorize the sender, fix its SPF or DKIM setup, or confirm it is not yours. Work through them one at a time. The point of the audit is to reach a state where the only mail failing your checks is mail you do not send, which is to say, forgeries.
Doing this by eye across raw XML from dozens of receivers gets painful fast, and that is a real barrier rather than a minor annoyance. If you want to see your current record and what it is doing before you start, the free DMARC checker analyzes your live setup and explains it in plain language.
Then, and only then, tighten
Once the reports are clean, meaning every legitimate source is authenticated and aligned, you are ready to move up. The next step is p=quarantine and eventually p=reject, done gradually and while still watching the reports, which is the subject of moving from quarantine to reject. The whole staged journey, start to finish, is laid out in the path to p=reject.
p=none is not the destination. A domain sitting on p=none forever sees the spoofing and does nothing to stop it. But it is the right first move, because it lets you enforce later with confidence instead of guesswork.