DMARC for Small Business: p=none Setup

Somebody told you to “set up DMARC.” Maybe Gmail started bouncing your invoices, maybe a customer’s IT person asked, maybe a scanner flagged your domain. So you search, and the first page you find ends on p=reject and a warning that you could lose real mail. You close the tab. Or you copy the strict version, and a week later the accountant says your quotes never arrive.

There’s a smaller first step, and it can’t block anything.

Short answer: publish one DNS record that says p=none and gives a place to send reports. In the DMARC spec, none means the domain owner “offers no expression of preference” (RFC 9989, checked November 7, 2026). Receivers don’t treat your mail any differently. What you get is reports telling you who is sending mail as you, and that list is the thing you can’t get any other way.

Rather have someone look at the record before you publish it? Send me the domain and tell me what sends your mail. I’ll tell you what I’d change.

The record

It’s a TXT record. The host (the “name”) is _dmarc, and the value looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

p is the policy. rua is where aggregate reports go; the spec describes it as the addresses to which aggregate feedback reports are to be sent (RFC 9989, checked November 7, 2026). Postmark’s guide starts from almost the same line and says the only value you have to change is that email address (Postmark, checked November 7, 2026).

Before you publish it, check that SPF and DKIM already exist for whatever sends your mail. DMARC passes when either one passes and lines up with your From domain. If you’re not sure, the spam post walks through checking both in five minutes.

The mistake that makes it look like it’s working

Here’s the part nobody mentions. You publish the record, nothing breaks, and then no reports arrive. Not in a week, not in a month. You assume reports are slow.

I found this on one of my own domains. The rua address was a mailbox on a different domain I own. The record looked right. The domain had never produced a single report.

The cause is a rule in the DMARC reporting spec. When your rua address is on a different organizational domain than the record, the sender of the report has to check that the receiving domain agreed to it. It looks up a TXT record at a name built like this: your domain, then ._report._dmarc., then the domain of the report address. If it finds a record containing v=DMARC1, the address is confirmed. If it doesn’t, “the URI MUST be ignored” (RFC 9990, section 4, checked November 7, 2026). Ignored means ignored. In my case nothing told me, and nothing in the record looked wrong.

So if your records are:

Monitored domain: yourdomain.com
Report mailbox: [email protected]

then the extra record goes in the DNS of mailhost.example, the domain that receives the reports, not the one you’re monitoring:

Name:  yourdomain.com._report._dmarc.mailhost.example
Type:  TXT
Value: v=DMARC1;

(The spec’s own example is the same shape: example.com._report._dmarc.thirdparty.example.net with the value v=DMARC1;.)

Three things trip people:

Wrong side. It belongs at the receiver’s DNS, and that may be a company that runs your reporting, not you. If you use a reporting service, ask them whether this record is needed and who publishes it.
A personal Gmail address as rua. As I read the rule, the authorization record would have to be published in gmail.com’s DNS, which you don’t control. Use a mailbox on your own domain, or a service built for this.
A wildcard if you run several domains. The spec allows a record at *._report._dmarc.mailhost.example containing v=DMARC1; to say you’ll take reports for any domain. It also notes the report consumer can remove it if the volume gets to be too much (RFC 9990, checked November 7, 2026).

Check it from a terminal:

dig TXT yourdomain.com._report._dmarc.mailhost.example +short

You should get "v=DMARC1;" back. I checked mine against the domain’s own nameservers and against a public resolver, because DNS caching can make a fix look done when it isn’t.

What the reports are, and what to do with them

Reports arrive as XML files, emailed to the address in your record. They list each sending source, how many messages it sent, and whether SPF and DKIM passed (Postmark, checked November 7, 2026). Nobody wants to read raw XML. Run them through a reporting tool, or ask someone who reads them every day. Postmark’s guide shows what a readable version looks like: a list of senders you’ve authorized, a list of “other sources” that passed neither check, and forwarded mail that fails SPF because the forwarder rewrote it.

The goal of the first few weeks is a single list: every service that sends mail as your domain. The ones you expected are easy. The value is in the ones you forgot about. The old CRM that still emails quotes. The invoicing tool. The contact form on a site nobody has touched in two years.

Each of those either passes or it doesn’t. For the ones that don’t, you fix SPF or turn on DKIM signing, then watch the next batch of reports. Postmark says to monitor “a few months at least” before moving off p=none (Postmark, checked November 7, 2026). Its guide also describes ramping up with the pct tag (quarantine 25%, then 50%, then all), which is how the older DMARC spec worked. Don’t plan around that. The 2026 spec removes pct, because operational experience showed it “was usually not accurately applied” at any value other than 0 or 100 (RFC 9989, Appendix A.6, checked November 8, 2026). Its t tag is only a yes-or-no testing flag, so there is no percentage to ramp with now. The gate is the reports: move to quarantine when every sender you recognise passes. The order after p=none is the same one in the spam post, including the RFC’s warning about mailing lists and why a small business can stop at quarantine.

What `p=none` does not do

It doesn’t stop anyone from spoofing your domain. It’s the monitoring step, and I’d rather say that plainly than sell it as protection. The spec’s definitions put it at one end: none is no preference, quarantine is “suspicious”, and reject is a clear sign the use of the domain isn’t valid (RFC 9989). Real protection starts at the other two. You get there by reading the reports first, not by guessing.

Why it matters to the business

You get the list of everything that sends as you while a mistake is still harmless. The invoice that goes to a customer’s spam folder is the one that gets paid late. Staff stop being told “your email didn’t come through” and stop sending a second one to be safe. And when you do tighten the policy, you tighten it knowing what you’re blocking.

When it stops being a DIY job

You don’t control the DNS. It’s at a registrar a former employee set up, or an agency that’s gone quiet.
Reports show senders you don’t recognize and you can’t tell which are yours.
DKIM has to be turned on in your mail provider’s admin console, and the person who has that access isn’t available or isn’t you.
You published p=none, nothing arrives, and the record above isn’t the reason.
You’re about to go to quarantine or reject on a domain people send everyday mail from.

The last one deserves a second look. A mistake in DMARC doesn’t fail loudly. Mail just stops showing up.

Questions people ask

Does p=none hurt my deliverability? Not by itself. Google and Yahoo’s bulk-sender rules accept a policy of none as the minimum, covered with sources in the spam post. Having no record at all is the worse look.

Do I need DKIM as well as SPF? DMARC needs either one to pass and line up. Postmark recommends having both, because forwarding breaks SPF and DKIM survives it (Postmark, checked November 7, 2026).

How often will reports come? I don’t have a figure I’d trust. Receivers send them on their own schedule, so give it a few days before you decide something is wrong, and then check the authorization record above before you check anything else.

Where I come in

Email authentication is one of the things I check in a website audit, along with who owns your domain and DNS. If you’ve published a record and the reports never came, or you’ve got an unknown sender and a customer waiting on an invoice, email me the domain at [email protected]. I’ll look at the records and tell you what I’d change, and whether it’s a ten-minute fix. If mail is going missing from a compromised site, that’s a rescue.