DMARC explained step by step: from p=none to p=reject

DMARC tells the rest of the internet what to do with mail that claims to come from your domain but cannot prove it. Set up well, it stops people from sending fake invoices in your name. Set up in a hurry, it can send your own newsletters and invoices to spam.

This guide walks through DMARC in the order you should roll it out: start by watching, read what the reports tell you, fix your senders, then tighten the policy one step at a time.

What DMARC checks

DMARC sits on top of two records you probably already have:

• SPF lists the servers allowed to send mail for your domain.
• DKIM adds a signature to each message that the receiver can verify against a public key in your DNS.

If you have not set these up yet, start with the records your email needs (SPF, MX and DMARC) and how to enable and set a DKIM record.

DMARC adds one important rule: alignment. A message passes DMARC only if SPF or DKIM passes and the domain that passed matches the domain in the visible From address. A message from a marketing tool that passes SPF for the tool’s own domain, but shows your domain in From, does not pass DMARC for you.

When a message fails, the receiving server looks up your DMARC policy and applies it. It also sends you a report about what it saw.

The DMARC record

DMARC is a TXT record published at _dmarc under your domain. For example.com, the host name is _dmarc.example.com. In most DNS panels you type just _dmarc as the host.

A starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Step 1: publish p=none and collect reports

Start with p=none. It tells receivers to deliver mail as they normally would, but to send you reports. Nothing changes for your recipients, so there is no risk.

Point rua at a mailbox you actually read, or at a dedicated address such as dmarc@. Reports arrive as compressed XML attachments, often one a day from each large receiver, so a separate mailbox keeps them out of anyone’s inbox.

If the report address is on a different domain from the one the record is for, that other domain has to agree to receive them. It does this with a TXT record like example.com._report._dmarc.reports-domain.com set to v=DMARC1. Reports sent to an address on the same domain need nothing extra.

Leave p=none in place for at least a few weeks. You want to see a full cycle of your normal mail, including monthly invoices and anything else that only goes out now and then.

Step 2: read the aggregate reports

An aggregate report is a summary, not a copy of your mail. For each sending IP address it lists how many messages that source sent using your domain, and what happened to them. The parts that matter:

• source_ip: the server that sent the mail.
• count: how many messages came from it.
• disposition: what the receiver did (none, quarantine or reject).
• dkim and spf under policy_evaluated: whether each check passed with alignment.
• header_from: the domain in the From address.
• auth_results: the raw SPF and DKIM results, including which domain actually passed.

Raw XML is hard to read at volume. A DMARC report viewer or parser turns it into a list of senders, which is what you need.

Sort every sender into one of three groups

1. Yours and passing. Your email host, with DKIM and SPF aligned. Nothing to do.
2. Yours and failing. Your website, CRM, invoicing tool, help desk or newsletter platform sending as your domain without aligned SPF or DKIM. Fix these before you tighten the policy.
3. Not yours. Servers you do not recognize sending as your domain. This is the spoofing DMARC exists to stop.

How to fix a failing sender

• Turn on DKIM signing with your own domain in that service. This is the most reliable fix, because a DKIM signature survives forwarding.
• Add the service to your SPF record with the include it documents, as long as you stay within SPF’s limit of 10 DNS lookups.
• Or stop the tool from sending as your domain: send website mail through your own mailbox over SMTP instead. Our guide shows how to set up SMTP in WordPress.

Step 3: move to p=quarantine, gradually

When the only failing mail in your reports is mail you do not recognize, move to quarantine. Receivers then put failing mail in spam instead of the inbox.

You can ease in with pct:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

Watch the reports and your own inbox for complaints from customers or colleagues. If nothing legitimate is caught, raise pct to 50, then 100.

Step 4: move to p=reject

With quarantine at 100% and clean reports, switch to reject:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Receivers now refuse failing mail outright, so a fake invoice in your name never reaches anyone. Keep rua in place. When a new tool starts sending as your domain, the reports are how you find out before your customers do.

Common mistakes

• Two DMARC records. A domain must have exactly one TXT record at _dmarc. With two, receivers treat it as if you have none.
• Publishing at the wrong host. The record goes at _dmarc.example.com, not at the root of the domain.
• Jumping straight to reject. Your own website or invoicing tool may be failing without you knowing. Collect reports first.
• Forgetting subdomains. If you send from a subdomain such as mail.example.com, check it appears in your reports. Use sp if subdomains need a different policy.
• Relying on SPF alone. SPF breaks when mail is forwarded, because the forwarding server is not in your SPF record. Aligned DKIM keeps forwarded mail passing.
• Going over the SPF lookup limit. Every include adds lookups. Past 10, SPF returns an error and stops passing for all of your mail. Remove services you no longer use.
• Typos in the record. Tags are separated by semicolons, and v=DMARC1 must come first. Check the record with a DMARC lookup tool after you publish it.
• Setting it and forgetting it. A policy of p=none with nobody reading the reports protects nothing.

If mail is already landing in spam, DMARC is one of several things to check. Our guide on why emails go to spam, including blacklists covers the rest.

Records set and checked for you

With Unlimited business email hosting from CloudWish, we show you the MX, SPF, DKIM and DMARC records for your domain and check them before you go live, so you start from a clean baseline and can tighten your policy with confidence.

See Unlimited business email features