Setting Up DMARC for Your Domain

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that sits on top of SPF and DKIM. It doesn’t check the message itself, it tells receiving mail servers what to do when a message fails those checks, and it gives you a feed of reports showing exactly who is sending email using your domain. If you already have SPF and DKIM configured, DMARC is the piece that turns them into an enforceable policy instead of two independent checks nobody acts on.

Prerequisites

• SPF and DKIM already configured and passing for your legitimate senders
• Access to your domain’s DNS
• An email address (or a DMARC report processing service) to receive aggregate reports

Setting up DMARC before SPF and DKIM are solid is the most common mistake. DMARC only enforces what those two records already established, so fix them first.

Adding the Record

Create a TXT record at _dmarc.yourdomain.com with a value like:

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

• p=none is a monitoring-only policy. Nothing gets blocked yet, you just start collecting reports.
• rua= is where aggregate reports get sent. Use an address you actually check, or a dedicated inbox.
• pct=100 applies the policy to all mail (adjustable during rollout).

Rollout Strategy

Don’t jump straight to enforcement. DMARC has three policy levels:

1. p=none (monitor only): run this for at least 1-2 weeks. Every sender that uses your domain, including ones you forgot about, will show up in the reports.
2. p=quarantine: once reports show only legitimate senders passing, move failing mail to spam instead of blocking it outright.
3. p=reject: the end state. Anything failing SPF and DKIM alignment is rejected. Only move here once you’re confident every real sender is accounted for.

Skipping straight to p=reject is the fastest way to silently lose legitimate mail, including your own transactional email, if a sender was missed in setup.

Reading Aggregate Reports

Reports arrive as compressed XML attachments, which are unreadable directly. Use a DMARC report parsing tool or service to turn them into a readable summary showing:

• Every IP address that sent mail claiming to be from your domain
• Whether each one passed SPF, DKIM, or both
• Volume, so you can tell a real third-party sender from a one-off spoofing attempt

Common Issues

• Alignment failures despite passing SPF/DKIM: DMARC requires the domain in SPF or DKIM to align with the domain in the visible “from” address, not just pass independently. A third-party sender using their own domain in SPF won’t align even if SPF technically passes.
• Legitimate mail getting quarantined after moving off p=none: a sender was missed during the monitoring period. Go back to p=none, extend monitoring, and check reports again before re-attempting enforcement.
• No reports arriving: the rua= address is unreachable, or the DNS record has a syntax error and isn’t being read at all. Validate the record with a DMARC record checker before assuming reports are simply delayed.

Once SPF, DKIM, and DMARC are all in place and enforced, your domain is meaningfully harder to spoof, and you have ongoing visibility into every service sending mail on your behalf.