DMARC records, explained

Q: Someone is spoofing my email address. Will DMARC stop it?

DMARC with p=reject will cause compliant receiving servers to refuse spoofed emails, protecting your recipients. However, not every server is fully DMARC-compliant, and DMARC doesn't stop display name spoofing (where the visible name matches yours but the actual email address doesn't).

Even if you've set up SPF and DKIM, there's one more piece that ties everything together: DMARC. It tells receiving email servers what to do when an email fails authentication, and gives you reports so you can see if anyone is spoofing your domain. This guide explains DMARC in plain English.

What DMARC stands for

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It builds on SPF and DKIM by telling receiving servers what to do when those checks fail.

How DMARC works

A receiving server gets an email claiming to be from @yourbusiness.com.

SPF and DKIM checks are performed (see SPF records and DKIM records).

The results are checked for alignment. DMARC asks whether an SPF or DKIM pass actually belongs to the domain in the From address.

If at least one aligns, the email passes DMARC and is delivered normally. It does not need both to pass. One is enough.

If neither aligns, the email fails DMARC, and the receiving server looks up your DMARC record to find out what policy to apply.

The policy is applied: monitor, quarantine, or reject.

Reports may be sent to the address specified in your DMARC record, summarizing authentication activity.

SPF and DKIM are two separate checks on the same email: one on the sending server, one on the signature. DMARC is not a third check: it is the policy that tells receiving servers what to do with emails that fail SPF or DKIM.

Read this as text

An email arrives claiming to be from your domain. The receiving mail server runs two checks on it. SPF checks the envelope: is this mail server on the approved list? DKIM checks the letter: was this email signed by the claimed domain, and is the signature still intact?

If both checks pass, the email has been authenticated and there is nothing for your DMARC policy to act on. Authentication on its own is not a promise of the inbox: spam filters also weigh things like your message content.

If either check fails, your DMARC policy tells the receiving server what to do. A policy of none delivers the email anyway and sends reports to you as the domain owner. Quarantine puts it in the spam or junk folder. Reject blocks it entirely, so it never reaches the recipient.

The three DMARC policies

Policy	What it means	When to use it
`p=none`	Monitor only: take no action on failing email	Starting out; learning what's being sent
`p=quarantine`	Send failing email to spam/junk	Moderate protection; not confident all sources are covered
`p=reject`	Refuse to deliver failing email	Full protection; confident all legitimate senders are covered

What a DMARC record looks like

A DMARC record is a TXT record added to your DNS at the name _dmarc:

_dmarc.yourbusiness.com

A simple monitoring DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com

A stricter record that quarantines failing email:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourbusiness.com

Breaking down the parts

Part	What it means
`v=DMARC1`	Declares this is a DMARC record
`p=none/quarantine/reject`	The policy to apply
`rua=mailto:email@domain`	Send aggregate reports to this address
`ruf=mailto:email@domain`	Send per-message failure reports to this address
`sp=`	Policy for subdomains (if different from the main policy)
`np=`	Policy for subdomains that don't exist

Don't copy a pct tag from an old guide

Older DMARC guides include a pct tag for applying the policy to only a percentage of failing mail. The 2026 revision of the DMARC standard removed it and lists it as historic, so leave it out of new records.

A recommended starting approach

Start with a monitoring-only policy to understand what's being sent from your domain before tightening the policy:

Start with p=none and set up a rua email address to receive aggregate reports.

Review reports over a few weeks. The reports arrive as XML, which is hard to read on its own, but they show you what services are sending email from your domain. A DMARC monitoring service turns them into plain summaries; Postmark runs a free one that emails you a digest.

Make sure all legitimate senders (your email provider, newsletter tool, CRM) are covered by SPF and have DKIM enabled.

Move to p=quarantine once confident, then p=reject for maximum protection.

Don't jump straight to reject

Moving directly to p=reject without verifying all your sending sources can cause legitimate emails to be refused. Take the time to monitor first.

DMARC and DMARC alignment

DMARC also requires alignment: the domain in the email's "From" header must align with the domain that passed SPF or DKIM. Aligned means either identical to that domain (strict alignment) or sharing the same organizational domain as it (relaxed alignment). This is what prevents attackers from using their own perfectly valid mail server to send email that looks like yours.

Common questions

Do I need DMARC if I already have SPF and DKIM?

SPF and DKIM are authentication mechanisms but they don't on their own enforce what happens when they fail. DMARC is what turns authentication into enforcement and gives you visibility through reports. Some providers also require it outright: Google's rule for email sent to personal Gmail addresses is that anyone sending more than 5,000 messages a day must have SPF, DKIM and DMARC in place.

Who sends the DMARC reports?

Receiving mail servers (like Gmail and Outlook) send reports back to the address you specify in the rua field. These are aggregate reports showing authentication results across all email sent from your domain over a period. The standard asks receivers to send them at least once every 24 hours, but not every receiver sends them at all.

Someone is spoofing my email address. Will DMARC stop it?

DMARC with p=reject will cause compliant receiving servers to refuse spoofed emails, protecting your recipients. However, not every server is fully DMARC-compliant, and DMARC doesn't stop display name spoofing (where the visible name matches yours but the actual email address doesn't).

Can I have DMARC without DKIM?

Yes, but you're then relying solely on SPF for authentication. DMARC with both SPF and DKIM is significantly more robust. We recommend implementing all three.