DMARC Best Practices: A Checklist for Getting It Right

Setting up DMARC is straightforward. Setting it up well — so that it actually protects your domain without breaking your legitimate email — takes a bit more care. The difference between a DMARC deployment that works and one that causes problems usually comes down to following a handful of best practices.

This guide is a practical checklist. It covers everything from the prerequisites you need before publishing a DMARC record to the ongoing maintenance that keeps your authentication healthy over time. Work through it in order if you are starting from scratch, or jump to the sections that apply to your current stage.

Before You Publish a DMARC Record

Set Up SPF First

SPF tells receiving servers which IP addresses are authorized to send email on behalf of your domain. You need this in place before DMARC because DMARC relies on SPF results.

Audit every service that sends email as your domain: your email provider (Google Workspace, Microsoft 365), marketing platforms (Mailchimp, HubSpot), transactional email services (SendGrid, Amazon SES), CRM tools, helpdesk software, and any internal applications. Every one of these needs to be included in your SPF record. For a clear picture of how SPF, DKIM, and DMARC each play a role, see our SPF vs DKIM vs DMARC comparison.

Create your SPF record at spfcreator.com and publish it as a TXT record on your domain.

Set Up DKIM Second

DKIM adds a cryptographic signature to your emails that proves they were sent by an authorized system and have not been tampered with. It is the more resilient of the two authentication mechanisms because it survives email forwarding, which breaks SPF.

Configure DKIM signing for every service that sends email as your domain. Most hosted services make this straightforward — they provide CNAME or TXT records to add to your DNS. Generate your DKIM keys at dkimcreator.com.

Having both SPF and DKIM gives your emails two independent paths to pass DMARC. If one breaks — SPF failing during forwarding, a DKIM key expiring — the other keeps your messages authenticated.

Inventory All Your Sending Sources

Before you publish a DMARC record, make a complete list of everything that sends email as your domain. This is the step most people skip, and it is the one that causes the most problems later.

Check with your marketing team, sales team, support team, finance team, and IT team. Ask what tools they use that send email. Check for automated systems like monitoring alerts, invoicing software, and appointment schedulers. If you are not sure whether you have covered everything, start with p=none and let your DMARC reports fill in the gaps.

Publishing Your DMARC Record

Start with p=none and Reporting

Your first DMARC record should always use p=none with a rua address for aggregate reports:

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

This tells receiving servers to deliver all email normally, regardless of authentication results, but send you reports about what is passing and failing. It is risk-free and immediately valuable.

The fo=1 tag requests failure reports for any authentication failure, giving you more detailed data during the monitoring phase.

Use a Dedicated Reporting Address

Do not send DMARC reports to your personal inbox or a shared team mailbox. DMARC aggregate reports are XML files that arrive in volume — major providers send them daily. They will clutter a regular inbox quickly.

Create a dedicated address like dmarc-reports@yourdomain.com or, better yet, point your rua address to a monitoring service that processes the reports automatically. Read our guide on managing DMARC report emails for practical setup advice.

Verify Your Record After Publishing

After adding your DMARC record to DNS, verify it is published correctly at dmarcrecordchecker.com. Check for common mistakes: typos in the record, multiple DMARC records on the same domain (which is invalid), and incorrect DNS record types (DMARC must be a TXT record at _dmarc.yourdomain.com).

Moving Toward Enforcement

Review Your Reports for Two to Four Weeks

Before tightening your policy, you need data. Wait at least two weeks — ideally four — to collect aggregate reports from all major mail providers. Review the reports to confirm that every legitimate sending source is passing SPF or DKIM with proper alignment.

If you see failures from legitimate senders, fix their authentication before moving forward. Do not move to enforcement until your pass rate is consistently high across all sending sources.

Move to Quarantine with a Low Percentage

When your reports show clean results, update your policy to p=quarantine with a low pct value:

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

This applies the quarantine policy to only 25% of failing messages. The other 75% are still delivered normally. It limits the impact if you missed a legitimate sender.

Ramp Up the Percentage Gradually

Increase the percentage over several weeks: 25%, then 50%, then 75%, then 100%. At each stage, monitor your reports and listen for complaints about missing emails. This gradual approach is how the protocol was designed to be deployed — the pct tag exists specifically for this purpose.

Move to Reject

Once p=quarantine; pct=100 is running cleanly, switch to p=reject and repeat the gradual ramp. Start with pct=25 and work up to 100%. When you reach p=reject without a pct tag (which defaults to 100%), your domain is fully protected. See our quarantine vs reject comparison for a side-by-side look at the tradeoffs between these enforcement levels.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com;

This is the end state you are working toward. Our guide on DMARC policy levels covers the full journey in detail.

Protecting Non-Sending Domains

If you own domains that do not send email — parked domains, redirects, old brand names, defensive registrations — they still need DMARC. Agencies that manage portfolios of client domains should be especially vigilant here, as attackers specifically target domains without authentication records because there is nothing to stop their spoofed messages.

For non-sending domains, go straight to p=reject. There is no legitimate email to worry about, so there is no reason to start with monitoring:

v=DMARC1; p=reject;

You can also publish null SPF and DKIM records to make it explicit that no server is authorized to send email for these domains. A null SPF record looks like v=spf1 -all.

Ongoing Maintenance

Monitor Continuously

DMARC is not a set-and-forget system. DNS records change, new sending services get added, DKIM keys expire, and SPF records grow beyond the 10-lookup limit. Set up ongoing monitoring that alerts you when something breaks.

Review Reports Monthly

Even with automated monitoring, schedule a monthly review of your DMARC data. Look for new sending sources you do not recognize, changes in pass rates, and any unauthorized activity. This is also a good time to clean up services you no longer use from your SPF record.

Keep SPF Under 10 Lookups

Every time you add a new sending service, check that your SPF record is still within the 10-lookup limit. Remove services you no longer use. Consolidate include mechanisms where possible. An SPF record that exceeds 10 lookups fails silently for every message, and it is one of the most common causes of sudden DMARC failures.

Rotate DKIM Keys Periodically

DKIM keys should be rotated periodically — annually at minimum, quarterly for higher-security environments. Key rotation limits the damage if a private key is compromised. Most hosted email services handle rotation automatically, but if you manage your own DKIM keys, build rotation into your maintenance schedule. Developer teams can automate key rotation as part of their infrastructure-as-code workflow.

Protect Subdomains

Use the sp tag in your DMARC record to control subdomain policy, or publish separate DMARC records on subdomains that send email. Subdomains without their own DMARC record inherit the parent domain's policy, which may not be appropriate if the subdomain has different sending requirements. Our guide on DMARC for subdomains covers this in detail.

Monitor Your Email Authentication

You've set up your email authentication — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.