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 (none/quarantine/reject), and read DMARC reports to strengthen 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 a safe starting policy

Start with monitoring mode.
If you’re enabling DMARC for the first time, begin with p=none. This collects reports without blocking mail, so you can confirm all legitimate senders pass authentication before enforcing stricter rules.

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 simple monitoring example and replace the email address with one you control:
```
v=DMARC1; p=none; 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: Move from monitoring to enforcement (when ready)

Review reports until you’re confident your legitimate mail sources are aligned.
Once reports show that your real sending services consistently pass DMARC, you can begin enforcement to stop spoofed mail.
Gradually enforce stricter policies.
A common progression is none → quarantine → reject, optionally using pct= to roll out changes slowly.

Practical Application / Real-Life Example

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

Week 1–2: Publish p=none and confirm all legitimate senders (Google Workspace/Microsoft 365, your CRM, lemlist-related sending infrastructure, support tools, etc.) authenticate properly.
Week 3: Move to p=quarantine with a partial rollout using pct=50. This sends some failing mail to spam while you monitor impact.
Week 4+: Increase to pct=100 and/or move to p=reject once you’re confident only unauthorized sources are failing.

Example DMARC Records

Example	Description
`v=DMARC1; p=none; rua=mailto:[email protected]`	Start in monitoring mode (no enforcement).
`v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=50`	Quarantine half of unauthenticated emails.
`v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100`	Fully enforce - block unauthenticated emails.

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=none (or use p=quarantine; pct=) while you correct SPF/DKIM for the failing sources, then re-enforce gradually.

Issue: You’re overwhelmed by XML reports.

Root cause: Aggregate DMARC reports are sent as XML by most providers.
Fix: Use a report parser/dashboard tool (for example: dmarcian, Postmark DMARC, or EasyDMARC) to make reports readable.

DMARC Policy Options (Quick Reference)

Policy	What It Does	When to Use
p=none	Collects reports but doesn’t block emails.	For monitoring and testing.
p=quarantine	Sends unauthenticated emails to spam/junk.	When you’re ready to start enforcing.
p=reject	Blocks all unauthenticated emails completely.	For full protection once SPF & DKIM are stable.

Tip: Start with p=none for a few weeks, then move to quarantine or reject once reports confirm only unauthorized mail is failing.

DMARC Tags Explained

Tag	Description
v=	Version (`DMARC1`).
p=	Policy (none, quarantine, or reject).
rua=	Aggregate report recipient (where daily 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 start with p=none and confirm your legitimate senders are passing authentication?
Do you know where your rua= reports are being delivered, and can you read them using a DMARC dashboard?
Before moving to quarantine or reject, have you confirmed that every tool/service you use to send email is covered by SPF and/or DKIM?

Set up DKIM, SPF, and DMARC

Configure DNS for email deliverability

Set DNS records on GoDaddy

Set DNS records on Google Domains

Find the DNS health section