DMARC Implementation Checklist

Phase 1: Inventory (before touching DNS)

• List every domain and subdomain you own that could send email.
• For each domain, list every service that sends as it: primary mail platform, CRM, marketing tools, billing software, helpdesk, website notifications, HR systems, monitoring tools, WordPress plugins, and any legacy or on-premises mail servers.
• Confirm you have DNS management access for each domain.
• Check whether an SPF record already exists. If you have more than one, that's a problem to fix now.
• Check whether DKIM is already enabled in your primary mail platform.

Phase 2: Set up SPF

• Write a single SPF TXT record that includes every authorized sender.
• Use include: for hosted platforms (Google, Microsoft, SendGrid, etc.).
• Use ip4: for any on-premises servers with fixed IPs.
• End with -all (hard fail) if you're confident in your sender list, or ~all (soft fail) during initial setup.
• Confirm you have exactly one SPF TXT record per domain after publishing.
• Check the lookup count doesn't exceed 10. Use an SPF validator to confirm.

yourdomain.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Phase 3: Enable DKIM on every sender

• Enable DKIM in your primary mail platform (Google Workspace, Microsoft 365, etc.).
• Publish the DKIM DNS record each platform provides (usually a TXT or CNAME).
• Verify or activate DKIM in the platform after publishing.
• Repeat for every third-party sender that supports custom DKIM signing under your domain.
• Use a 2048-bit key where supported. Avoid 1024-bit.

Phase 4: Publish DMARC at p=none

• Publish your first DMARC record at _dmarc.yourdomain.com.
• Use p=none — monitoring only, no enforcement yet.
• Set rua= to your reporting destination (a DMARC tool inbox or a monitored mailbox).
• Do not set ruf= (failure reports) unless you have a specific need. Failure reports can contain message headers and potentially personal data.

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

• Wait 24–48 hours for the first reports to arrive.
• Confirm reports are being received.

Phase 5: Review reports for 2–4 weeks

• Review aggregate reports weekly using your DMARC reporting tool.
• Identify every source sending mail as your domain.
• Classify each source: passing cleanly, legitimate but failing alignment, or unknown/unauthorized.
• For legitimate sources failing alignment, plan the fix: enable custom DKIM signing, configure a custom return-path, or move to a subdomain.
• For unrecognized sources: document them. They're potential spoofing attempts — exactly what DMARC enforcement will block.

Phase 6: Fix alignment failures

• For each legitimate sender failing DKIM alignment: enable custom DKIM domain signing at the vendor.
• For each sender failing SPF alignment: configure a custom bounce/return-path domain at the vendor, or add them to your SPF record.
• After each fix, wait for new reports to confirm the sender is now passing.
• Do not move to enforcement until all legitimate senders are passing alignment consistently.

Phase 7: Move to quarantine

• Update DMARC to p=quarantine; pct=25.
• Monitor reports and mail delivery for one week.
• Increase: pct=50 for another week, then pct=100.
• Watch for any legitimate mail landing in spam that shouldn't be.

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com"

Phase 8: Move to reject

• Update to p=reject.
• Continue monitoring reports. Spoofed mail will now appear as rejected in reports rather than delivered.
• Consider adding sp=reject to extend the policy to all subdomains.

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourdomain.com"

Ongoing

• Review aggregate reports at least monthly.
• When adding a new email-sending service, configure SPF and DKIM alignment before it goes live.
• When migrating mail platforms, verify alignment before decommissioning the old platform.
• Apply SPF -all and DMARC p=reject; sp=reject to any domains you own that don't send email.
• Keep DKIM key sizes at 2048-bit and rotate periodically.
• Monitor SPF record lookup count — it can exceed 10 as vendors change their infrastructure.