Understanding DMARC: A Complete Guide

February 3, 20268 min read

If someone sends an email pretending to be from your domain (a phishing attack, a scam, a fake invoice), the recipient has no easy way to tell it's not really from you. DMARC is the protocol that fixes this. It lets you tell email providers exactly what to do when someone fails to prove they're authorized to send email on your behalf.

But DMARC isn't just a security tool for IT teams. It directly protects your business reputation, your customer relationships, and your email deliverability. If you've ever wondered why some of your emails end up in spam, DMARC is likely part of the answer.

What DMARC actually does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. In practice, it does three things:

It checks whether incoming emails pass SPF and DKIM authentication, two older protocols that verify the sender's identity.
It tells receiving mail servers what to do if authentication fails: nothing (monitor only), quarantine (send to spam), or reject (block entirely).
It sends you reports about every email that claims to come from your domain: who sent it, whether it passed authentication, and what the receiving server did with it.

Why your business needs DMARC

Without DMARC, anyone can send email that looks like it comes from your domain. This is not a theoretical risk. It happens constantly. Attackers send phishing emails impersonating real companies to steal credentials, redirect payments, or distribute malware.

When a customer receives a phishing email "from" your domain, they don't blame the attacker. They blame you. Your brand takes the hit, even though you had nothing to do with it.

DMARC also improves legitimate email delivery. Email providers like Google and Microsoft give preferential treatment to domains with strong DMARC policies. If you're not using DMARC, your real emails are more likely to land in spam.

The three DMARC policies

DMARC has three policy levels, and choosing the right one matters:

p=none: monitor only. Emails that fail authentication are still delivered, but you receive reports about them. This is the starting point.
p=quarantine: emails that fail authentication are sent to the recipient's spam folder. A good middle ground while you verify your setup.
p=reject: emails that fail authentication are blocked entirely. This is the strongest protection, but requires careful preparation.

Most organizations should start with p=none and monitor their DMARC reports for at least 2-4 weeks before moving to quarantine or reject. Jumping straight to reject can block legitimate email from services you've forgotten about.

How to implement DMARC

Implementing DMARC is a DNS change: you publish a TXT record at _dmarc.yourdomain.com. A basic record looks like this:

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

This tells email providers to send you aggregate reports (rua) while delivering all mail normally (p=none). The reports show you exactly who is sending email as your domain and whether they pass authentication.

The challenge is not publishing the record. It's reading the reports and acting on them. DMARC reports are XML files that can be difficult to parse manually. This is where tools like MailShield come in: we process your reports automatically and show you who's sending email on your behalf, whether they're authorized, and what you need to fix.

Common DMARC mistakes

We see the same mistakes across hundreds of domains:

Jumping to p=reject before monitoring: this blocks legitimate email from third-party services (marketing platforms, CRMs, ticketing systems) that send on your behalf.
Not setting up report processing: publishing a DMARC record without reading the reports means you're flying blind. The reports are the whole point.
Forgetting about subdomains: DMARC applies to subdomains too. If you don't set a subdomain policy (sp=), attackers can still spoof mail from sub.yourdomain.com.
Ignoring alignment: DMARC requires that the domain in the From header aligns with the domain authenticated by SPF or DKIM. Many third-party senders break alignment by default.

Next steps

If you don't have a DMARC record yet, start today with p=none and a reporting address. If you already have DMARC but haven't looked at your reports, now is the time.

MailShield can scan your domain in under a minute, show you your current DMARC status, and start processing your reports automatically. You'll see exactly who's sending email as your domain, and whether they should be.