DMARC (Domain-based Message Authentication, Reporting & Conformance) helps protect your domain from spoofing and phishing, and it can improve your email deliverability by proving to mailbox providers that your mail is legitimate.

Learning Objective

By the end of this tutorial, you’ll know how to publish a DMARC DNS record, choose an appropriate policy (quarantine or reject), and handle DMARC reports in a way that strengthens your sender reputation over time.

Why This Matters

DMARC reduces the chance that attackers can impersonate your domain, which protects your brand and your recipients. It also helps mailbox providers (Gmail, Outlook, Yahoo, Apple Mail, AOL, and others) trust your domain, often improving inbox placement when SPF and DKIM are set up correctly.

Prerequisites (Recommended)

You already have SPF and DKIM configured for the domain you send from.
You can access your domain’s DNS settings (GoDaddy, Cloudflare, Namecheap, IONOS, etc.).
You can wait for DNS changes to propagate (commonly a few hours; sometimes up to 48 hours depending on DNS/TTL).

Core Lesson: Step-by-Step Workflow

Phase 1: Choose the right DMARC policy (core recommendation)

Always set DMARC to at least p=quarantine — never p=none.
Many people publish p=none just to “have DMARC,” but a “do nothing” policy is often treated by anti-spam systems the same as having no DMARC policy at all.
Understand what quarantine vs. reject actually does.
- Quarantine = tells the receiving server to keep the message out of the inbox (typically spam/junk) and apply additional scrutiny.
- Reject = tells the receiving server to refuse the message during delivery (it’s sent back, and the sender decides what to do next).
In both cases, the email does not reach the lead’s inbox, so on paper there is no difference in score impact.
Use p=reject only if you have someone handling DMARC reporting (a postmaster) and the right tooling.
When you publish DMARC, you also define an email address for incoming DMARC reports (via rua=). With enforcement (especially p=reject), you can receive a high volume of reports. These reports are typically complex (XML inside archive files) and difficult to use without a postmaster tool/dashboard. If you don’t want to manage DMARC reports, use p=quarantine instead of p=reject.

Phase 2: Publish your DMARC record in DNS

Go to your DNS hosting provider.
Open the DNS management area for the domain you send emails from.
Create a new DNS record.
- Type: TXT
- Name / Host: _dmarc
- TTL: 3600 (1 hour), unless your host requires a different value.
Add your DMARC record value.
Use this safe enforcement example and replace the email address with one you control:
```
v=DMARC1; p=quarantine; rua=mailto:[email protected]
```
This tells providers to send aggregate (summary) reports to the address in rua.
Save the record and wait for DNS propagation.
Validate your setup using a DMARC record checker (for example: MXToolbox, dmarcian, or EasyDMARC).

Phase 3: Increase enforcement safely (if/when you’re ready)

Review reports until you’re confident your legitimate mail sources are aligned.
DMARC enforcement only works well when your real sending services consistently pass SPF/DKIM and align properly.
Move from quarantine to reject only when report handling is in place.
If you have a postmaster and a DMARC reporting tool to handle the volume and complexity of reports, you can move to p=reject for maximum protection. If not, stay on p=quarantine.

Practical Application / Real-Life Example

Here’s a practical rollout you can follow to reduce risk while improving protection:

Week 1–2: Publish p=quarantine and confirm all legitimate senders (Google Workspace/Microsoft 365, your CRM, lemlist-related sending infrastructure, support tools, etc.) authenticate properly.
Week 3: Keep p=quarantine and (optionally) add a partial rollout using pct=50 while you monitor results.
Week 4+: Increase to pct=100. Move to p=rejectonly if you have a postmaster process and tooling to manage DMARC reports.

Example DMARC Records

Example	Description
`v=DMARC1; p=quarantine; rua=mailto:[email protected]`	Minimum recommended policy. Keeps failing mail out of the inbox while you monitor reports.
`v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=50`	Quarantine with partial rollout (helps reduce risk if you’re unsure all senders are aligned).
`v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100`	Maximum enforcement. Use only if you have a postmaster process/tooling to handle DMARC reports.

Troubleshooting & Pitfalls

Issue: You published DMARC, but validation tools can’t find the record.

Root cause: DNS propagation delay, wrong host/name, or record created on the wrong domain.
Fix: Confirm the record name is exactly _dmarc for the correct domain, then wait and re-check using a DMARC checker.

Issue: DMARC reports show legitimate emails failing.

Root cause: SPF or DKIM not configured correctly for a sending service, or identifier alignment isn’t correct.
Fix: Identify the sending source in the report (IP/service), then ensure that service is included in SPF and/or signing with DKIM for your domain.

Issue: You moved to p=reject and some real emails stop being delivered.

Root cause: Not all legitimate senders were authenticated/aligned before enforcing.
Fix: Temporarily revert to p=quarantine (optionally with pct=) while you correct SPF/DKIM for failing sources, then re-enforce gradually.

Issue: You’re overwhelmed by XML reports.

Root cause: DMARC aggregate reports are typically sent as XML (often inside archive files) and can be noisy at scale.
Fix: Use a report parser/dashboard tool (for example: dmarcian, Postmark DMARC, or EasyDMARC). If you don’t have a postmaster process, prefer p=quarantine over p=reject.

DMARC Policy Options (Quick Reference)

Policy	What It Does	When to Use
p=quarantine	Keeps failing mail out of the inbox (commonly spam/junk) and allows additional scrutiny.	Default recommendation for most domains (minimum enforcement).
p=reject	Refuses failing mail during delivery (strongest enforcement).	Only when you have a postmaster process and tooling to manage DMARC report volume/complexity.
p=none	Requests no enforcement action; reporting only.	Not recommended. Many anti-spam systems treat this similarly to having no DMARC policy because it effectively says “do nothing.”

Tip: Set p=quarantine as your baseline. Only move to p=reject if you’re prepared to manage DMARC reports (postmaster + tooling).

DMARC Tags Explained

Tag	Description
v=	Version (`DMARC1`).
p=	Policy (none, quarantine, or reject).
rua=	Aggregate report recipient (where periodic XML reports are sent).
ruf=	Forensic report recipient (for detailed individual failures).
pct=	Percentage of emails to which the policy applies. Default: 100.
aspf= / adkim=	Alignment mode for SPF/DKIM (strict or relaxed).
sp=	Policy for subdomains.
fo= / rf= / ri=	Reporting options, format, and frequency.

Knowledge Check

Did you publish DMARC with at least p=quarantine (not p=none)?
Do you know where your rua= reports are being delivered, and can you read them using a DMARC dashboard?
Before moving to p=reject, do you have a postmaster process (and tooling) to handle the volume and complexity of DMARC reports?
Have you confirmed that every tool/service you use to send email is covered by SPF and/or DKIM and aligned for DMARC?