Common DMARC Mistakes

Starting with p=reject

This is the most common way to break email. p=reject tells receivers to discard failing mail. If you haven't yet identified every legitimate sender and confirmed they're all passing alignment, enforce at reject and you will lose real mail.

Always start at p=none. Collect reports. Fix senders. Move to quarantine at low pct first. Then reject. The enforcement path exists for a reason.

Not accounting for all third-party senders

Organizations routinely underestimate how many systems send email as their domain. Beyond your primary mail platform, look for:

• CRM platforms (Salesforce, HubSpot)
• Marketing tools (Mailchimp, Klaviyo, Constant Contact)
• Billing and invoicing software (Stripe, QuickBooks, FreshBooks)
• Helpdesk tools (Zendesk, Freshdesk, Intercom)
• Website contact forms and notification scripts
• HR and payroll systems
• Monitoring and alerting tools
• WordPress plugins with email notifications
• Legacy on-premises mail servers

Any of these that send as your root domain need to be configured for alignment before you enforce. The reports at p=none will reveal them.

Publishing multiple SPF records

You cannot have two SPF TXT records on the same domain. This:

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

...causes a PermError. SPF evaluation stops, SPF counts as a fail, and DMARC can't align on SPF. Combine everything into a single record:

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

Exceeding the 10-lookup SPF limit

SPF allows a maximum of 10 DNS lookups per evaluation. If your record has many include: statements and each of those pulls in additional records, you can exceed the limit. The result is a PermError — the same as a misconfigured record.

If you're approaching the limit, you have two options: consolidate includes where possible, or use SPF flattening to replace include: references with their resolved IPs. Flattened records need to be kept current as vendors change their infrastructure.

Assuming SPF alone is enough

SPF breaks on forwarding. When email is forwarded, the envelope sender changes and SPF fails for your domain. If your only passing authentication is SPF, forwarded mail will fail DMARC.

DKIM signs the message content and typically survives forwarding. For most domains, having both SPF and DKIM set up — with both aligning — is the right target. DMARC only needs one to pass, but having both gives you resilience.

Staying at p=none forever

p=none is a monitoring mode. It gives you visibility but provides no protection. A domain at p=none indefinitely still allows spoofed mail to reach inboxes at participating receivers. The purpose of DMARC is enforcement. If you're collecting reports and your senders are clean, there's no reason to stay at none.

Confusing SPF pass with DMARC pass

SPF can pass without DMARC passing. If your marketing platform passes SPF under its own domain, that's a technical SPF pass — but the domain doesn't align with your From: address, so DMARC still fails. Check alignment results in your reports, not just SPF and DKIM pass/fail in isolation.

Ignoring reports after reaching reject

DMARC is not set-and-forget. New senders get added. Keys rotate. SPF records drift out of sync. DNS changes can silently break authentication. After reaching p=reject, continue reviewing aggregate reports regularly — at minimum monthly, ideally weekly.