What is DMARC? A Plain-English Guide to Email Authentication

Learn what DMARC is, why it matters for your email security, and how it works with SPF and DKIM to protect your domain from spoofing.

If you've been told you need DMARC for your domain, you're not alone. DMARC has become essential for anyone sending business email, but the technical jargon can make it feel more complicated than it needs to be.

Here's what you actually need to know.

DMARC in Plain English

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. That's a mouthful, so let's break it down simply: DMARC is a rule you publish in your domain's DNS that tells email providers what to do when someone tries to send email pretending to be you.

Think of it like a security policy for your email. Without DMARC, anyone can send emails that look like they come from your domain. With DMARC, you get to decide whether those fake emails get delivered, quarantined, or rejected entirely.

Why DMARC Matters

Email spoofing is surprisingly easy. Spammers and phishers regularly send emails that appear to come from legitimate business domains. This causes real problems:

For your recipients: They might fall for phishing emails that look like they came from your company. This damages trust and can lead to fraud.

For your deliverability: If spammers abuse your domain, email providers may start treating all email from your domain as suspicious. Your legitimate emails end up in spam folders.

For your brand: When people receive spam "from" your domain, they blame you, not the spammer.

DMARC solves this by letting you take control. You tell email providers exactly how to handle emails that fail authentication, and you get reports showing who's trying to send email as your domain.

How DMARC Builds on SPF and DKIM

DMARC doesn't work alone. It builds on two other email authentication standards: SPF and DKIM.

SPF (Sender Policy Framework) is a list of servers authorized to send email for your domain. When an email arrives, the receiving server checks if it came from an authorized server. You can check your SPF record to make sure it's configured correctly.

DKIM (DomainKeys Identified Mail) adds a digital signature to your emails. The receiving server can verify this signature to confirm the email wasn't tampered with in transit. You can test your DKIM setup to verify it's working.

DMARC ties these together. It checks whether an email passes SPF or DKIM and whether the results align with the domain in the "From" address. If alignment fails, DMARC tells the receiving server what to do about it.

Without SPF and DKIM in place, DMARC can't do its job. All three work together to authenticate your email.

What a DMARC Record Looks Like

A DMARC record is a TXT record in your DNS. Here's a typical example:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Let's decode that:

  • v=DMARC1 - This identifies the record as DMARC (required)
  • p=reject - This is the policy, telling receivers to reject emails that fail authentication
  • rua=mailto:dmarc@example.com - This is where you want to receive aggregate reports

The record lives at a specific location in your DNS: _dmarc.yourdomain.com. When an email provider receives an email claiming to be from your domain, they look up this record to find your policy.

If you don't have a DMARC record yet, you can create one with DMARC Creator.

The Three DMARC Policies

The p= tag in your DMARC record sets your policy. There are three options:

p=none - Monitor mode. Emails that fail authentication are delivered normally, but you receive reports about them. This is the starting point for most domains.

p=quarantine - Suspicious emails get sent to spam or junk folders. This is a middle-ground approach that protects recipients while you fine-tune your setup.

p=reject - Emails that fail authentication are blocked entirely. This is the strongest protection but requires confidence that your legitimate email is properly authenticated.

Most organizations start with p=none to collect data, then gradually move to p=quarantine and eventually p=reject once they're confident their email infrastructure is properly configured.

Start with monitoring

Don't jump straight to p=reject. Start with p=none, review your reports for a few weeks, fix any issues, then gradually increase enforcement.

Subdomain Policies

DMARC also lets you set a separate policy for subdomains using the sp= tag. If you don't specify one, subdomains inherit the main policy.

This matters if you use subdomains for different purposes. For example, you might want strict enforcement on your main domain but different rules for marketing.example.com or support.example.com.

Getting Started with DMARC

Setting up DMARC involves three steps:

  1. Verify SPF and DKIM - Make sure both are configured and working. Check your SPF record and DKIM keys.

  2. Publish a DMARC record - Start with a monitoring policy (p=none) and a reporting address. Use DMARC Creator if you need help building the record.

  3. Monitor and adjust - Review your DMARC reports to identify any legitimate email that's failing authentication. Fix issues, then increase enforcement.

The process takes time. Rushing to enforcement without proper monitoring can block your own legitimate email.

Monitor Your DMARC Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

Never miss a DMARC issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring