How to set up DMARC safely

To set up DMARC safely, publish a monitoring record first, use its reports to authenticate every legitimate sending source, then raise the policy in stages from none to quarantine to reject. The order matters: enforcing before your sources pass will block real mail. Done in sequence, you reach full protection without disrupting delivery.

Before you start

DMARC depends on SPF and DKIM, so confirm both exist first. SPF (RFC 7208) lists the IPs and services allowed to send for your domain in a TXT record. DKIM adds a cryptographic signature published as a public key in DNS. You need at least one of them passing and aligned for DMARC to pass, and ideally both. Also note the SPF 10 DNS lookup limit: an SPF record that triggers more than ten DNS lookups fails, which then breaks DMARC alignment.

Step by step

1. 1

   1. Publish a monitoring record

   Add a TXT record at _dmarc with v=DMARC1; p=none; rua=mailto:rua@example.com. This collects data without affecting delivery.

2. 2

   2. Gather reports

   Wait two to four weeks and read the aggregate (RUA) reports to see every source sending as your domain.

3. 3

   3. Authenticate each source

   For every legitimate sender, set up SPF and DKIM so it passes and aligns with your From domain.

4. 4

   4. Move to quarantine

   When legitimate mail passes consistently, set p=quarantine, optionally using pct to ramp gradually.

5. 5

   5. Move to reject

   Once quarantine shows no legitimate mail failing, set p=reject for full protection.

6. 6

   6. Keep monitoring

   Continue reading reports so new services and any abuse are caught early.

Handle the SPF lookup limit

Many organizations exceed the SPF 10 DNS lookup limit as they add cloud services, which silently breaks SPF and undermines DMARC. Flattening SPF resolves the included mechanisms into direct IP addresses so you stay under the limit. EmailAuth's SmartSPF flattens your SPF record automatically and keeps it updated as your vendors change their IPs.

Common pitfalls

• Jumping to p=reject before sources are authenticated, which blocks real mail.
• Forgetting subdomains: set an sp policy or they may be left unprotected.
• Publishing two DMARC records, which invalidates DMARC completely.
• Ignoring the SPF 10-lookup limit, which breaks SPF and DMARC alignment.
• Enforcing and then never checking reports again, so new senders go unnoticed.

Make ongoing management easier

EmailAuth can host your DMARC, SPF, DKIM, and BIMI records by CNAME delegation, so you point DNS once and manage policy changes in a dashboard instead of editing DNS repeatedly. It parses RUA and RUF for you and flags sources that still need work. To see your starting point, run a free domain scan, then follow the staged path above to reach p=reject.

Frequently asked questions