Guides

What is DMARC

Last updated 2026-08-26

Anyone with a mail server can put your domain in the From line of an email you never sent. DMARC, short for Domain-based Message Authentication, Reporting and Conformance, is the DNS record built for exactly that problem. It tells mailbox providers like Gmail and Outlook what to do with mail that claims to be from you and cannot prove it.

How does DMARC stop email spoofing? At its strictest setting, p=reject, mailbox providers refuse mail that uses your exact domain and fails authentication, so a forged invoice never reaches the inbox. But jump straight to p=reject while your own senders are misconfigured, and providers refuse your real mail too. That is why a new record starts at p=none, and this guide covers the ground between the two.

The From line proves nothing on its own

Email is older than the web, and the servers that relay it never checked who was sending. The From line is just text the sender fills in, like the subject line. A spammer can type your domain there as easily as you can, and for decades receivers (the mail servers at Gmail, Outlook and every other mailbox provider) had no way to tell the difference.

Two checks came later to close that hole. SPF is a public list of the servers allowed to send a domain's mail, so a receiver can check whether the connecting server is on it. DKIM lets a sending server put a signature on each message, which the receiver checks against a key in the domain's DNS. A signature that verifies proves the message came from a holder of the domain's key and was not altered along the way. Both checks work, and both share a gap: neither one has to involve the domain in the From line. A message can pass SPF and DKIM for some domain the recipient never sees, while the From line shows yours.

DMARC closes the gap. It ties both checks to the From domain, the one a person reads in their mail client, and it lets you tell receivers what to do when a message fails. It also gives you something neither check could: reports from the receivers themselves about who is sending mail as your domain.

The record is one line of DNS

You publish DMARC as a TXT record, a line of plain text anyone can look up, at a fixed name: _dmarc followed by your domain. This is the record most domains start with.

The record has three tags. v=DMARC1 names the protocol, and the other two do the work: p sets your policy, the instruction receivers follow when mail fails the checks, and rua asks for reports.

Tag	What receivers do
p=none	Deliver failing mail anyway, exactly as if there were no record.
p=quarantine	Put failing mail in the spam folder.
p=reject	Refuse failing mail outright.
rua=	Send reports to this address: usually one XML file per receiver per day, listing every source that sent mail as your domain.

Publish exactly one record at that name, because two records there make receivers ignore both. A record without a rua tag still sets a policy, but it asks nobody for these reports, so you are left guessing which services send as you. If you are curious what your domain publishes right now, our free DMARC checker reads the live record back and flags the tags that leave a gap.

Receivers check the mail, then follow your policy

When a message using your domain arrives at Gmail, the receiver runs both checks. SPF checks whether the connecting server is on your published list. DKIM checks the signature on the message against the key in your DNS. DMARC passes when at least one of the two passes and the passing check matches the domain in the From line. Otherwise the message fails DMARC, and the receiver looks up your record and does what the p tag says.

One passing check is enough by design. A forwarded message usually fails SPF, because the forwarding server is not on your list. The DKIM signature travels inside the message though, so it survives most forwarding and the mail still clears DMARC. That is why a working DKIM signature matters more than a perfect SPF record on a domain you care about. Our free SPF checker shows your list and its lookup count, which is capped at 10 (the lookup guide explains that ceiling), and our DKIM checker confirms the key you published resolves.

Alignment ties the checks to your From domain

Alignment is the rule behind the phrase "matches the domain in the From line", and it is why a raw pass for the wrong domain does not count. SPF, for example, checks the hidden return address on the envelope, not the From line a person reads. An invoicing vendor can pass SPF for its own return address and sign as vendor.net while the From line shows your domain. Without alignment, that mail would count as authenticated. Alignment says the domain that passed has to be yours, so a sender cannot authenticate as themselves and display as you. The alignment guide works through a real header.

Start at p=none, finish at p=reject

So which policy do you publish? Start at none, even though none blocks nothing, because of the senders you have forgotten. Most domains send mail from more places than anyone remembers: the mailbox provider, a marketing platform, an invoicing tool, a helpdesk, payroll, and something nobody remembers buying. A few of those are failing the checks today through nobody's fault, and a policy of reject would make receivers refuse their mail. The bounce goes to the sending platform, not to you, and the person who never received a message does not open a support ticket. You find out weeks later, from a customer or from payroll.

So the work runs in this order.

1. Publish a none policy with a rua address, so receivers start sending you reports.
2. Read the reports for a few weeks and list every source that sends as your domain.
3. Fix the senders that are yours, or stop them sending as you.
4. Move to quarantine, and after a stretch of clean reports change one word to reject.

Quarantine is the halfway house: failing mail lands in spam, where a person can still dig it out, instead of vanishing. A domain that has never sent mail is the one exception to the ramp, because it has no forgotten senders and can go straight to reject. Yours has sent mail, so start at none. The setup guide has the numbers I wait for before each move.

Subdomains inherit the parent policy

Your policy covers your subdomains unless you say otherwise, so a marketing platform on news.example.com falls under reject on the parent. Sort that out before you move the parent, or carve the subdomain out with its own record (the sp tag in the parent record sets a separate policy for every subdomain at once).

Reject stops exact-domain spoofing

At reject, a forged invoice sent from your exact domain never reaches a Gmail or Outlook inbox. Receivers that honour the policy refuse it at the SMTP door, and the sender gets the bounce. That shuts down the most convincing kind of phishing mail there is, the kind where the address is right.

Know the edges too. A lookalike domain passes its own DMARC, and yours never comes into it. A display name that reads as your CEO over a random mailbox address is untouched, because the From domain is not yours. And a criminal inside a real mailbox at your company sends real, signed mail that passes every check. DMARC authenticates the domain. It cannot vouch for the person.

Bulk-sender rules want a published record

Publishing has a second payoff: your own mail stops tripping the bulk-sender rules at the big providers. Google bounces unauthenticated bulk mail with 550-5.7.26, Microsoft returns 550 5.7.515 for the same class of failure, and both check for a published DMARC record. A record at none, with SPF or DKIM passing on your mail, keeps your own invoices out of the bulk-sender bounce. Stopping the forged ones needs reject.

You watch both in the same place: the pass rate in your reports. A number that drops is your own mail starting to fail, and a number that holds above 98% for two weeks running is what I wait for before enforcing.

The reports arrive as XML

Everything above turns on the reports. Each participating receiver sends one file a day, a few kilobytes of XML covering a 24 hour window, and some of the files do not parse cleanly. You can read them by hand, and the report guide walks through a real one 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. 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 the day it runs. What you are building is a table with one row per sending source: who it is, whether it passes, and whether it is yours. That table is the whole ramp, because without it you cannot move the policy safely, and with it the move is one word in DNS. Most people read files for a week, then stop opening the folder, and 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 parse the XML from every receiver that sends it, malformed files included, and keep at least 12 months of source-level detail. One mail arrives on Monday. It opens on your pass rate against last week, lists new sending sources with a pass or fail verdict per IP, and ends on the one change worth acting on. It is the table you would have built by hand, kept current for you, and the dashboard holds the detail for the week you want to click through the senders yourself.

On Pro and Team we watch between Mondays too: we mail you the day a new source fails or a known sender stops passing, at most once a day per domain, and we fold every domain into the same Monday mail. Pro is $19 a month for 5 domains and Team is $79 a month for 25, and you can tell us to skip the digest on a clean week. Your first domain is free, with no card, and the free plan carries the digest and the 12 months of history. The pricing page has the rest.

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

DomainCanary is a DMARC monitoring service that turns your domain's aggregate reports into one weekly email.