What is DMARC and Why Should You Care?

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email security protocol that lets domain owners tell receiving mail servers what to do when someone sends an email that fails authentication checks.

Think of it this way: anyone can write any "From" address on an email, just like anyone can write any return address on a physical letter. Without DMARC, there's no reliable way for the recipient to verify that the email actually came from who it claims. DMARC fixes this.

DMARC builds on two existing protocols — SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) — and adds a critical missing piece: a policy that tells receiving servers what to do when emails fail these checks.

Why DMARC matters

Without DMARC, attackers can send emails that appear to come from your domain. This is called email spoofing, and it's used in:

• Phishing attacks — tricking your customers or employees into revealing passwords, credit card numbers, or other sensitive information
• Business Email Compromise (BEC) — impersonating executives to authorize fraudulent wire transfers
• Brand damage — spam sent "from" your domain erodes trust and can get your legitimate emails blocked
• Deliverability issues — without DMARC, mailbox providers have less confidence in your emails, which can affect inbox placement

DMARC is no longer optional. Major email providers like Google and Yahoo now require DMARC for bulk senders. If you send marketing emails, transactional emails, or any significant volume, you need DMARC.

How DMARC works

When a receiving mail server gets an email claiming to be from your domain, here's what happens:

1. SPF check — The server checks if the sending IP is authorized to send for your domain (via your SPF DNS record)
2. DKIM check — The server verifies the cryptographic signature on the email matches a public key in your DNS
3. DMARC alignment — The server checks that the domain in the "From" header matches the domain that passed SPF or DKIM. This alignment step is what makes DMARC powerful — SPF and DKIM alone can pass on a different domain than the visible "From" address
4. Policy enforcement — Based on your DMARC policy, the server takes action: deliver, quarantine, or reject the message

The key insight is that DMARC requires alignment. Even if SPF passes, the domain must match the "From" header domain. This closes the loophole that made SPF and DKIM alone insufficient.

The three DMARC policies

Your DMARC record includes a policy (p=) that tells receiving servers what to do with emails that fail DMARC:

p=none — Monitor only

Do nothing with failing emails, but send reports. This is the starting policy — it lets you see who's sending email as your domain without affecting delivery. Important: this provides zero protection against spoofing. It's a monitoring step, not a security measure.

p=quarantine — Send to spam

Emails that fail DMARC should be treated with suspicion. Most receiving servers will move these to the spam/junk folder. This is a good intermediate step once you've confirmed your legitimate emails pass DMARC.

p=reject — Block completely

Emails that fail DMARC should be rejected outright — they never reach the inbox or spam folder. This is the strongest protection and the goal you should work toward. With p=reject, no one can successfully spoof your domain.

Setting up DMARC step by step

DMARC is configured via a DNS TXT record at _dmarc.yourdomain.com. Here's how to set it up:

Step 1: Make sure SPF and DKIM are configured

DMARC depends on SPF and DKIM. Before adding DMARC, verify both are set up correctly. You can use our SPF Checker and DKIM Checker tools.

Step 2: Start with p=none

Add this DNS TXT record:

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The rua tag specifies where aggregate reports should be sent. These XML reports show who's sending email using your domain and whether they pass or fail authentication.

Step 3: Monitor reports for 2-4 weeks

Review the DMARC reports to identify all legitimate email sources (marketing platforms, CRM systems, transactional email services). Make sure they all pass SPF and/or DKIM with proper alignment.

Step 4: Move to p=quarantine

Once you're confident all legitimate sources pass, upgrade your policy:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=25

The pct=25 tag applies the policy to only 25% of failing emails at first. Gradually increase to 100% as you gain confidence.

Step 5: Move to p=reject

The final step — full protection:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Understanding DMARC reports

DMARC generates two types of reports:

Aggregate reports (rua)

XML files sent daily by receiving mail servers. They contain statistics about emails from your domain: how many passed/failed, which IPs sent them, and which authentication checks failed. These are the reports you'll use most — they show the big picture.

Forensic reports (ruf)

Detailed reports about individual messages that fail DMARC. These contain more information but are less commonly sent by receiving servers due to privacy concerns. Not all providers send forensic reports.

Raw DMARC reports are XML files that are difficult to read manually. Tools like Sendvery parse these reports automatically and give you visual dashboards showing your authentication rates and any issues.

Common DMARC mistakes

Staying on p=none indefinitely

Many organizations set up DMARC with p=none and never progress. This provides visibility but zero protection. Attackers can still spoof your domain without consequence. Set a deadline to move to p=quarantine and then p=reject.

Jumping straight to p=reject

Going directly to p=reject without monitoring can block your own legitimate emails. Always start with p=none, review reports, fix authentication issues, then gradually tighten the policy.

Forgetting third-party senders

Your marketing platform, CRM, helpdesk, and other services send email on your behalf. Each needs proper SPF and/or DKIM configuration. Review your DMARC reports carefully to identify all senders before tightening your policy.

Not setting up a subdomain policy

DMARC's sp= tag controls the policy for subdomains. Without it, subdomains inherit the main domain's policy. If you don't send email from subdomains, set sp=reject to prevent subdomain spoofing.

Next steps

1. Check your current DMARC setup with our free tool
2. Read our SPF guide to make sure your SPF record is correct
3. Read our email authentication overview to understand how SPF, DKIM, and DMARC work together