What Is DMARC? A Plain-English Guide

If you've ever received an email that looked like it came from a legitimate company — your bank, a supplier, even your own domain — but turned out to be a phishing attempt, you've encountered the problem that DMARC is designed to solve.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It's a DNS record that tells the world's email servers what to do with email that claims to be from your domain but can't be verified as genuine.

Without it, anyone can send an email that appears to come from your address. With it, those emails get quarantined or rejected before they reach anyone's inbox.

What problem does DMARC solve?

Email was designed in a simpler time. The original protocol (SMTP) has no built-in way to verify that an email actually came from who it claims to be from. This makes spoofing — sending email that falsely claims to be from a given domain — trivially easy.

Spoofing is the basis of most phishing attacks. A criminal doesn't need to compromise your email system. They just need to send an email with your domain in the From: header. Without DMARC, many receiving mail servers will simply deliver it.

DMARC doesn't stop criminals from trying. It tells receiving mail servers to refuse their attempts.

How DMARC works

DMARC builds on two existing authentication mechanisms: SPF and DKIM.

SPF (Sender Policy Framework) is a DNS record that lists the IP addresses authorised to send email for your domain. If an email arrives from an IP address that isn't on your list, SPF fails.

DKIM (DomainKeys Identified Mail) is a cryptographic signature added to outgoing email by your mail server. The receiving server checks the signature against a public key in your DNS. If the signature is valid, the email hasn't been tampered with and came from a server authorised to sign for your domain.

DMARC adds a layer on top of both: it specifies what should happen when an email fails either (or both) of these checks.

The three DMARC policies

A DMARC record contains a policy (p=) that tells receiving servers what to do with email that fails authentication:

p=none

Do nothing. The email is delivered normally regardless of authentication result. Reports are still generated (if you've configured a reporting address), but no action is taken. This is useful for monitoring before you enforce a policy — but it provides zero spoofing protection.

p=quarantine

Email that fails authentication goes to the spam or junk folder. It's not rejected outright, but it's not delivered to the inbox either. This is a sensible intermediate step when moving from none to full enforcement.

p=reject

Email that fails authentication is rejected entirely. It never reaches the recipient's inbox, junk folder, or anywhere else. This is the goal — the only policy that provides genuine spoofing protection.

What a DMARC record looks like

A DMARC record is a TXT record in DNS at _dmarc.yourdomain.com.

Minimal example:

v=DMARC1; p=reject;

Recommended setup with reporting:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100;

• v=DMARC1 — Required. Identifies this as a DMARC record.
• p=quarantine — Policy for email that fails authentication.
• rua= — Address to receive aggregate reports (summaries of authentication results).
• pct=100 — Apply the policy to 100% of email.

How to implement DMARC: a step-by-step approach

Implementing DMARC incorrectly can break your legitimate email. The recommended approach is gradual:

Step 1: Start with p=none and a reporting address

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;

This starts generating reports without affecting email delivery. Run this for 2–4 weeks and review the aggregate reports to understand what's sending email from your domain.

Step 2: Fix SPF and DKIM

Review the aggregate reports. Identify any legitimate sending sources that aren't covered by your SPF record or aren't signing with DKIM. Add them before moving to an enforced policy.

Step 3: Move to p=quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=10;

Start with pct=10 to apply the policy to only 10% of traffic. Monitor for false positives. Gradually increase to 100.

Step 4: Move to p=reject

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100;

Full enforcement. Spoofed email claiming to be from your domain will be rejected before it reaches any inbox.

Common DMARC mistakes

Leaving DMARC at p=none indefinitely

p=none is a monitoring policy, not a protection policy. Your domain can still be spoofed. Move to p=reject as the goal.

Not configuring a reporting address

Without rua=, you get no visibility into what's authenticating and what's failing. You're flying blind.

Breaking DMARC alignment

DMARC requires the domain in the From: header to align with the domain that passes SPF or DKIM. If you're sending from a subdomain but your DMARC is on the root domain, check that aspf=r (relaxed alignment) is set.

Multiple DMARC records

Like SPF, only one DMARC record is permitted. Multiple records cause a PermError and DMARC evaluation fails entirely.