What is DMARC

Anyone with a mail server can type your domain into the From line of a message you never sent, and nothing in the mail protocol checks it. DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record you publish to fix that. In it, you tell receivers, the mail servers at Gmail, Outlook and the rest, what to do with mail that claims to be from you and can't prove it. They also send you reports on who's sending as your domain.

Does publishing DMARC stop email spoofing straight away? No. The record you publish first, p=none, blocks nothing. With it, receivers start sending you reports. You use the reports to reach p=reject safely, and p=reject is the setting that blocks forged mail.

How DMARC works

Receivers already run two checks on incoming mail. SPF checks whether the server that connected is on the list your domain publishes in DNS. DKIM checks a signature on the message against a public key in your DNS. Both work, but 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 adds a rule on top. A message passes DMARC when at least one of those two checks passes and the domain that passed is the one in the From line. That match is called alignment, and it's the only idea in DMARC you have to actually understand. An invoicing vendor can pass SPF for its own return address and sign as vendor.net while the From line shows your company. Without alignment that counts as authenticated. With it, it fails, and your DMARC policy says what happens next. The alignment guide walks through a real header.

The DMARC record

You publish it as a TXT record at _dmarc. followed by your domain. Most domains should start with this record:

v=DMARC1 marks it as a DMARC record. The p= tag sets the policy, and rua= sets where the reports go.

Publish exactly one record at that name. Two records there make receivers ignore both. Leave out rua= and you still have a policy, but nobody sends you reports, so you're guessing which services send as you. The free DMARC checker reads your live record and flags the tags that leave a gap.

Starting at p=none

Start at p=none. Most domains send mail from more places than anyone remembers: the mailbox provider, a marketing platform, an invoicing tool, a helpdesk, payroll. Some of those fail SPF or DKIM today through nobody's fault. Publish p=reject now and receivers refuse their mail. The bounce goes to the sending platform, not to you, and the customer who never got the invoice doesn't open a ticket. You find out weeks later.

1. Publish p=none with a rua= address. Reports start within a day or two.
2. Read the reports for a few weeks and list every source that sends as your domain.
3. Fix the senders that are yours. Stop the ones that shouldn't be sending as you.
4. Move to p=quarantine. After a stretch of clean reports, change it to p=reject.

At quarantine, failing mail goes to spam, where a person can still find it. I move the policy when the pass rate holds above 98% for two weeks running. If a domain has never sent mail, there are no forgotten senders, and it can go straight to reject. The DMARC setup guide has the numbers I wait for at each step.

Your policy covers your subdomains too, unless you say otherwise. A marketing platform sending from news.example.com falls under the parent's reject. Sort it out before you move the parent, or give the subdomains their own policy with the sp= tag.

What p=reject stops

At reject, a forged invoice sent from your exact domain never reaches a Gmail or Outlook inbox. Receivers that honor the policy refuse it during delivery, and the forger gets the bounce.

Some fake mail still gets through. 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 isn't yours. Someone who has broken into a real mailbox at your company sends real, signed mail that passes every check. DMARC authenticates the domain. It can't check who's using the mailbox.

Even at none, a DMARC record helps with Google and Microsoft. Google bounces unauthenticated bulk mail with 550-5.7.26 and Microsoft returns 550 5.7.515 for the same class of failure, and both check for a published DMARC record. With a record at none and SPF or DKIM passing on your own mail, your invoices don't get that bounce.

The aggregate reports

Each step above depends on the reports. Each participating receiver sends one file a day, a few kilobytes of XML covering a 24 hour window, and some of them don't parse cleanly. You can read them by hand. The aggregate report guide goes through a real one field by field. After about ten files, you'll recognize the common patterns: your own mail, a vendor that isn't signed with your domain, forwarding and spoofing.

Doing that every morning is harder. Dozens of files a week arrive from receivers you've never heard of, and a payroll sender that runs once a month doesn't appear until the day it runs. You're building a table with one row per sending source: who it is, whether it passes and whether it's yours. With that table, you can move to reject safely. Most people read files for a week, stop opening the folder, and the domain stays at none.

With DomainCanary

We built DomainCanary for this part. You point the rua= tag at us, and we parse the XML from every receiver, malformed files included. We keep daily totals for each source for the life of the account. Every Monday, we send you one email. It starts with your pass rate against last week, lists new sending sources with a pass or fail for each IP, and ends with the one change worth acting on. On the Starter plan ($19 a month for 3 domains) and up, we also mail you the day a new source fails or a known sender stops passing, at most once a day per domain. On the Business plan ($49 for 10), every domain goes into the same Monday email. The pricing page has the rest. Your first domain is free, with no card.