Guides

What is DMARC

Last updated 2026-08-18

Your domain can appear in the From line of mail you did not send. DMARC, Domain-based Message Authentication, Reporting and Conformance, is the DNS record that tells mailbox providers what to do with that mail.

Should you start at p=none? Yes. You publish a TXT record at _dmarc that sets a policy for mail claiming to be from you, and you start at none so receivers report without refusing anything. Receivers refuse forged mail only at reject.

Do these four steps in this order, and do not skip ahead to reject.

1. Publish a none policy with a reporting address so receivers start sending daily files.
2. Read those reports for a few weeks and write down every source that used your domain.
3. Fix the senders that are yours, or stop them sending as you.
4. Move to quarantine once the list is clean, then change one word to reject.

The full ramp, with the numbers I use to decide when each step is safe, lives in the DMARC setup guide. This page gives the shape of the work, and the setup guide keeps the thresholds.

Start at none, then reject

Publish this record at _dmarc.example.com and change nothing else until the reports have named your senders.

The none policy is watch-only, so receivers deliver the mail as they would without a record. The rua tag asks every honouring receiver to send you a daily file about mail that used your domain. The DMARC checker reads the live record back and flags the tags that leave a gap.

The record is a policy

DMARC is a policy, not a filter on your own mail server. You publish one TXT record at _dmarc, and receivers read it before they decide what to do with a message that claims to be yours.

The policy lives in the p tag, which takes one of three values. none delivers the mail and sends you reports, quarantine puts failing mail in the spam folder, and reject refuses failing mail at the SMTP door.

None of those tags change how you send; they change how Google and Microsoft treat mail that uses your domain and fails both checks.

A record without a rua tag still sets a policy, but it asks nobody for reports. You then guess who sends as you, and you guess wrong.

Publish exactly one string, starting with the version tag, because two records at that name means receivers ignore both. If your DNS panel already appends the domain, the name you type is just _dmarc.

Receivers run two checks

Receivers run two checks on every inbound message.

SPF is a public list of servers allowed to send as your domain, and the connecting IP is either on that list or it is not. The SPF checker shows you the list and the lookup count. Stay under 10 lookups. An eleventh lookup makes the whole record fail, which is why the lookup guide exists.

DKIM is a signature on the message, and a passing signature proves the mail left a server that holds a key you published in DNS. The DKIM checker confirms that the selector you published resolves.

DMARC passes when at least one of those two checks passes, and the passing check matches the domain in the From line. When both fail, the receiver applies your p tag.

SPF and DKIM test the message, and DMARC is the instruction about a failure. The reports are how you learn who failed, and whether they are yours.

One passing check is enough. A forwarded message often fails SPF and still passes DMARC, because the DKIM signature survived the hop. That is why DKIM matters more than a perfect SPF record on a domain you care about.

Alignment matches the From domain

A raw pass on the wrong domain does not count. An invoicing vendor can pass SPF for its own bounce address and sign as vendor.net, while the From line shows your domain. Alignment is the rule that the authenticated domain must match the From domain. Without it, a sender authenticates as themselves and displays as you. The alignment guide is the worked version of this paragraph.

Reject stops exact-domain spoofing

Forged mail that uses your exact domain gets refused at reject. A fake invoice from your domain never reaches a Gmail or Outlook inbox, because receivers that honour reject drop it at the door and bounce the sender. Lookalike domains and a display name that only looks like you are a different problem. DMARC does not touch those. A stolen mailbox that sends real signed mail also passes, because the checks are real.

Bulk-sender rules want a published record

Your own real mail stops getting blocked by the bulk-sender rules at the big providers once a record exists. Google returns 550-5.7.26 when a sender has no working checks, and Microsoft returns 550 5.7.515 for the same class of failure; both look for a published DMARC record. A record at none satisfies that half. The spoofing half needs reject.

Those two outcomes are why the work is worth finishing. A record at none keeps your invoices out of the bulk-sender bounce, but it leaves the forged invoice in your customer's inbox.

Both outcomes show up in the same place: the pass rate in your reports. A number that drops is your own mail starting to fail, and a number you can hold above 98% is a domain ready to enforce. Our Monday digest opens on that number so a bad week is the first thing you read.

List every sender before you enforce

Publishing the record is one DNS change, and reaching reject is a few weeks of learning who sends mail as you.

The usual list is longer than people think, and it names your mailbox provider, a marketing platform, a sender for invoices and password resets, a helpdesk, payroll, and a tool nobody remembers buying. The reports name every one of them, and we turn that into a list you can read in a minute.

Jump to reject before you fix that list and the forgotten tool's mail vanishes. The person who never received it does not open a ticket. You find out weeks later, from a customer, or from payroll.

That is why the order is none, then fix, then quarantine, then reject. Quarantine puts failing mail in spam, where a person can still find it. After a stretch of clean reports you change one word in the record.

I start every live domain at none, even though a domain that has never sent mail can go straight to reject. Yours has sent mail. Start at none.

For each failing source, one of four things is true.

1. It is a service you use, and you turn on domain authentication.
2. It is a service you use that cannot sign as you, and you change supplier or route it through your own server.
3. It is forwarding, and DKIM already saved it.
4. It is not yours, and that is the reason you are doing this.

The setup guide has the numbers I wait for before each move. This page is the shape: watch, identify, fix, then enforce.

Subdomains inherit the parent policy

Your policy applies to subdomains unless you say otherwise. A marketing platform on news.example.com gets caught by reject on the parent, so sort that before you move the parent, or give the subdomain its own record.

Reports arrive as XML

The reports arrive as XML. One file arrives per provider per day, and a large receiver sends a few kilobytes covering a 24 hour window with filenames built from timestamps. Some of them do not parse cleanly.

You can read them by hand, and the report guide walks through a real file, field by field. After about ten files you know the four patterns: your real mail, a vendor that is not signed with your domain, forwarding, and spoofing.

Doing that every morning is a different job from learning the format. Dozens of files a week land from receivers you have never heard of, and a payroll sender that runs once a month is invisible until that day. A source that shows up in one file and not the next has usually not gone away. You are building a table with one row per sending source: who it is, whether it passed, whether it is yours.

That table is the whole ramp. Without it you cannot move the policy, and with it the move is one word in DNS.

The cost of the hand method is time and attention. Each file takes a few minutes once you know the format, and dozens of files fill an afternoon before tomorrow's files land, so most people start the folder and stop opening it. The domain sits at none.

We read the reports so you can move the policy

That stall is what we built DomainCanary for. You point the rua tag at us, and we take the XML from every provider that sends it, parse the malformed files too, and keep at least 12 months of source-level detail behind it.

One mail arrives on Monday. It opens with your pass rate against last week, it lists every new sending source with a pass or fail verdict per IP, and it ends on the one change worth acting on. It is the table you would have built by hand, kept current for you. There is a dashboard for the week you want to click through the sources, and the Monday mail arrives whether you open a tab or not.

Your first domain is free. No card, and the free plan carries the digest and the 12 months of history. Pro is $19 a month for 10 domains and Team is $49 a month for 15. Both watch between Mondays: a sender that starts failing gets you an alert that day, at most one a day per domain. Paid plans fold every domain into one Monday mail, and a clean week skips your inbox. You pay per domain, so a heavy sending month costs what a quiet one does. The pricing page has the rest.

Publish the record this week. Point the reports at something that reads them, then give it a month. A domain at none has a record and no protection against spoofing. A domain at reject has both. The distance between them is a list of who sends mail as you.