DMARC Record: How to Set Up DMARC Step by Step (p=none → quarantine → reject)

A DMARC record is one line of text in DNS, but it decides what happens to mail that claims to come from your domain and fails authentication. Set it up carelessly and you either protect nothing or block your own invoices. This guide goes through every tag, gives ready-made examples and a rollout plan from p=none to p=reject.

If SPF, DKIM and alignment are new to you, start with SPF, DKIM and DMARC explained — DMARC builds on both.

Where the DMARC record lives

DMARC is a TXT record on the _dmarc subdomain of the domain in your From address:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

There must be only one DMARC record per name. If a receiver finds two, it ignores DMARC for that domain. A subdomain without its own record inherits the record of the organizational domain (example.com).

DMARC tags explained

Relaxed vs strict alignment. Relaxed means the domains only need to share the organizational domain: a DKIM signature with d=news.example.com aligns with From example.com. Strict requires an exact match. Relaxed is the right choice for almost everyone.

Example DMARC records

Monitoring only — the safe starting point:

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

Quarantine for a quarter of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Full protection, subdomains included:

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

A domain that never sends mail (paired with v=spf1 -all):

v=DMARC1; p=reject; sp=reject

You can paste any of these into the DMARC checker after publishing to confirm the syntax and see how each tag is interpreted.

How to set up DMARC step by step

1. Make sure SPF and DKIM work first. Check them with the SPF checker and DKIM checker. DMARC without them only collects reports of failures.
2. Choose a report address. Aggregate reports are XML files, often dozens a day for an active domain. Use a dedicated mailbox or a DMARC report service rather than your personal inbox.
3. Publish p=none with rua in your DNS provider's panel: host _dmarc, type TXT.
4. Collect reports for 2–4 weeks so that weekly and monthly senders (invoices, payroll, newsletters) show up.
5. Fix every legitimate source that fails: enable DKIM with your domain in that service or add it to SPF with an aligned Return-Path.
6. Move to p=quarantine, optionally with pct=25, then 50 and 100, watching the reports after each step.
7. Move to p=reject once quarantine runs clean for a few weeks.

Reading aggregate reports

Each report covers one receiver and one period, usually a day. Inside you will find rows like this, simplified:

How to read it:

• Both aligned — your main mail server, all good.
• SPF passes but is not aligned, DKIM fails — a typical third-party service sending with its own Return-Path and without your DKIM key. Find out what the IP belongs to and enable DKIM for your domain there. Under p=reject this mail would be blocked.
• Everything fails from an unknown IP — either a forgotten system or someone spoofing you. Spoofing is what DMARC is for; just make sure it is not your own forgotten server first.

Besides the rows, every report has a header: the name of the organization that sent it (Google, Yahoo, Microsoft and others), the date range it covers, and the policy it found in your DNS at the time. That last part is a useful sanity check — if the report shows p=none a week after you published quarantine, the receiver is still seeing an old or duplicate record. Reports are sent as compressed attachments (zip or gzip), one per receiver per day, so an active domain quickly collects hundreds of files.

Raw XML is hard to read at volume, which is why most teams use a parsing service. Even without one, opening a few reports by hand during the first week is enough to spot unknown senders.

Subdomain policy

The sp tag sets the policy for subdomains that have no DMARC record of their own. Two typical setups:

• p=reject; sp=reject — everything locked down once you are confident.
• p=reject; sp=none — the main domain is protected, subdomains are still being tested. Do not leave it like this for long: attackers happily spoof billing.example.com.

A subdomain that sends its own mail, such as news.example.com, can have its own _dmarc.news.example.com record, which overrides sp.

Sending reports to another domain

If the rua address is on a different domain — typically a report-analysis service — that domain must agree to receive your reports. Otherwise receivers skip the address. Authorization is a TXT record on the receiving side:

example.com._report._dmarc.reports-provider.net.  TXT  "v=DMARC1"

Report services usually publish it for you, or a wildcard version covering all customers. The DMARC checker verifies this record for every external address in your rua and ruf.

Common DMARC record mistakes

• Wrong host name. The record belongs at _dmarc, not on the domain itself. If your DNS panel appends the domain automatically, enter only _dmarc, otherwise you get _dmarc.example.com.example.com.
• v=DMARC1 not first or misspelled, for example v=DMARC 1 with a space. Receivers treat the record as missing.
• Missing mailto: in rua. The value must be a URI: rua=mailto:[email protected], not just the address.
• Two DMARC records left behind after switching report services. Keep exactly one and put several addresses in rua, separated by commas.
• Policy tightened but nobody reads reports. A p=reject record with a rua mailbox that is full or unread means you will not notice when a new service starts failing.

After every change, give DNS time to update (usually minutes to a few hours, depending on the record's TTL) and check the result with the DMARC checker. The first aggregate reports normally arrive within a day or two, because most receivers send them once a day.

Things that break under p=reject

• Mailing lists that add footers or subject tags break DKIM, and the list server's IP breaks SPF. Many lists now rewrite the From address to avoid this; ARC helps receivers trust forwarded mail.
• Simple forwarding breaks SPF but keeps DKIM if the message is not modified — another reason to make DKIM your primary aligned check.
• Website forms that send "from" the visitor's address or from your domain via the hosting server's own mail. Send through an authenticated service with your domain instead.

Before a domain change of this scale, also check that your MX records are correct with the MX lookup: reports come back by email, and they need somewhere to land.