Ten common DMARC mistakes and how to avoid them

10 June 2026 · 12 min read

DMARC is one of those technologies where a single character in a DNS record decides whether legitimate invoices reach customers or quietly vanish into spam folders. The protocol itself is not complicated, but the rollout has a lot of sharp edges, and most of the damage comes from a small set of recurring errors. People publish a policy too aggressively and bounce their own newsletters. They misread alignment and assume a passing SPF check protects them when it does not. They turn on enforcement and forget the third-party services that send mail on their behalf.

This article walks through the ten mistakes we see most often when reviewing domains, in roughly the order they tend to bite. For each one you get the underlying mechanics, a concrete example of what goes wrong, and the specific steps to avoid or fix it. The goal is not to make you nervous about DMARC. It is to help you move from p=none to p=reject deliberately, with eyes open, and without a single legitimate message lost along the way.

If you want to check any claim against your own domain as you read, the free DMARC checker and the wider diagnostic tools will show you exactly what is published right now.

Mistake 1: jumping straight to p=reject

The single most expensive mistake is publishing an enforcing policy before you understand your own mail. A DMARC record like v=DMARC1; p=reject; rua=mailto:reports@example.com tells every receiver in the world to throw away mail from your domain that fails authentication. If you have not first confirmed that every legitimate sender aligns, you are betting your deliverability on an assumption.

The reason this is so tempting is that the security advice everywhere says "get to reject", and people quite reasonably want to be finished. But p=reject is the destination, not the starting point. You reach it by evidence, not by hope.

The correct sequence is:

1. Publish p=none with a rua address so reports start flowing, but no mail is affected.
2. Collect at least a couple of weeks of aggregate reports, ideally a full month, so weekly and monthly senders both appear.
3. Identify every source of mail and bring each one into alignment (more on alignment below).
4. Move to p=quarantine, optionally with a pct ramp, and watch the reports.
5. Only then move to p=reject.

We cover the safe path end to end in how to reach p=reject without breaking email. If you would rather not babysit the rollout yourself, the done-for-you DMARC service handles exactly this progression and only advances enforcement once the data says it is safe.

Mistake 2: treating p=none as protection

The opposite error is just as common and far more insidious. A domain sits on p=none for a year, reports arrive, nobody acts on them, and everyone assumes the domain is "protected". It is not. p=none is a monitoring policy. It asks receivers to send you data and to take no action whatsoever on failing mail. A spoofer can forge your domain freely and the policy does nothing to stop it.

p=none is the right first step, but it is a step, not a resting place. A domain that has been on none for six months with no movement is usually a domain where someone published the record, never set up report parsing, and forgot about it. That is a false sense of security, and we wrote a whole piece on why: p=none is a false sense of security.

To avoid this trap, treat p=none with a deadline. The moment you publish it, put a calendar reminder to review reports in two to four weeks and decide on the next step. If you are reading aggregate XML and it tells you nothing actionable, that is a sign you need help parsing it, not a sign your domain is fine.

Mistake 3: confusing authentication with alignment

This is the conceptual mistake that causes the most confused support tickets. SPF and DKIM can both pass, and DMARC can still fail. The reason is alignment.

DMARC does not simply ask "did SPF pass?" It asks "did SPF pass for a domain that matches the From header the user sees?" The visible From: address is what DMARC protects, and the SPF or DKIM result has to line up with that domain.

Consider a message where the visible From is billing@example.com, but the SPF check validates the envelope sender bounces@mailer.vendor.net. SPF passes. The vendor's servers are authorised for vendor.net. But vendor.net does not align with example.com, so from DMARC's point of view SPF provides no protection for this message. Unless DKIM is signing with an aligned example.com domain, DMARC fails.

There are two flavours to know:

• SPF alignment compares the envelope-from (return-path) domain with the header From domain.
• DKIM alignment compares the d= domain in the DKIM signature with the header From domain.

DMARC passes if either aligns. Each can be strict (exact match) or relaxed (organisational domain match, so mail.example.com aligns with example.com). Relaxed is the default and is almost always what you want.

The practical lesson: when a source shows SPF pass but DMARC fail in your reports, alignment is the culprit nine times out of ten. The fix is usually to get the sender to sign with DKIM using your domain, or to set a custom return-path under your domain. The SPF checker and DKIM checker let you confirm what is actually configured.

Mistake 4: forgetting your third-party senders

Almost every organisation sends mail from more places than it remembers. Marketing email goes through one platform, invoices through the accounting tool, support replies through a helpdesk, calendar invites and password resets through the app, and the occasional message straight from the office mail server. When you enforce DMARC, every one of these has to be aligned, and the forgotten ones are the ones that break.

The classic failure is the finance team's monthly statement run, sent from a billing platform nobody told IT about. It works fine on p=none. The day you reach p=reject, those statements start bouncing, and you find out a week later when a customer calls about a missing invoice.

To avoid this, build an inventory before you enforce:

• Read your aggregate reports and list every sending source that appears. The DMARC report analyzer turns raw XML into a readable list of who is sending as you.
• For each source, decide: is it legitimate? If yes, align it. If no, it can stay broken (that is a spoofer, and breaking it is the point).
• Cross-check the report list against what people tell you. Reports catch senders that humans forget.

The reason aggregate reports are so valuable here is that they show you reality rather than the org chart. A source you have never heard of, sending thousands of aligned messages, is a system you depend on and did not know about.

Mistake 5: blowing the SPF ten-lookup limit

SPF has a hard ceiling: an evaluator is allowed at most ten DNS lookups while processing a record. Mechanisms like include:, a, mx, ptr and exists each consume lookups, and include: chains are recursive, so one include can pull in several more. Exceed ten and the SPF check returns PermError, which most receivers treat as a hard SPF failure.

This sneaks up on you. Each new SaaS provider says "add include:_spf.theirservice.com to your SPF record", and individually that is fine. Add six or seven of them and you quietly cross the limit. The symptom is that SPF starts failing for senders that were passing yesterday, with no change to those senders.

A record like this is already at risk:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org include:_spf.salesforce.com include:sendgrid.net include:servers.mcsv.net ~all

Several of those includes themselves expand to multiple lookups, so the visible six can easily resolve to more than ten.

Ways to avoid PermError:

• Audit your lookup count with the SPF checker, which counts the real expanded total, not just the visible mechanisms.
• Remove includes for services you no longer use. Stale includes are extremely common.
• Flatten the record: replace include: chains with the specific IP ranges they resolve to, which costs zero lookups. The trade-off is that flattened IPs must be kept current, so this needs maintenance. We explain the mechanics in how SPF flattening works, and the hosted SPF product keeps a flattened record automatically updated.

Remember too that DMARC does not require SPF to pass. If DKIM aligns, DMARC passes regardless of SPF. So a healthy DKIM setup is also a hedge against SPF fragility.

Mistake 6: weak or missing DKIM, and the 1024-bit key

DKIM is the more robust of the two authentication methods because, unlike SPF, it survives most forwarding. A message forwarded to another mailbox usually breaks SPF alignment (the forwarder becomes the envelope sender) but keeps a valid DKIM signature. That makes DKIM the backbone of a DMARC setup that survives mailing lists and forwarding.

Two mistakes recur here. The first is simply not enabling DKIM on a sending source at all, relying on SPF alone, and then being surprised when forwarded mail fails DMARC. The second is using a weak signing key. A 1024-bit RSA key was acceptable years ago; 2048-bit is now the expectation, and some receivers treat short keys with suspicion. If your platform offers a key length choice, choose 2048-bit.

Other DKIM pitfalls worth knowing:

• A published selector that points at a malformed or truncated key record. DNS providers sometimes split long TXT records incorrectly. Verify with the DKIM checker.
• Rotating keys without overlap. If you publish a new selector and remove the old one before mail signed with the old key has drained, in-flight messages fail. Keep both live during a rotation window.
• Forgetting that each sending platform has its own selector and its own key. There is no single DKIM record for a domain.

The hosted DKIM product manages selectors and key rotation so the overlap window is handled for you.

Mistake 7: a typo or wrong location in the DNS record

DMARC records are fiddly, and a small error makes the whole thing silently inert. The record must live at the exact hostname _dmarc.example.com as a TXT record, and the value must begin with v=DMARC1. Get any of that subtly wrong and receivers act as if you have no DMARC policy at all.

Common variants of this mistake:

• Publishing the record at the apex (example.com) instead of _dmarc.example.com.
• A trailing or missing semicolon, or spaces inside tag values, that breaks parsing.
• Writing v=DMARC1;p=reject with no space, which is valid, but then mangling a later tag.
• Two DMARC records at the same name. The spec says that if more than one record is found, none is applied. A duplicate effectively disables your policy.
• A rua address that is just wrong, so reports go nowhere and you are flying blind.

The fix is to validate after every change. Do not assume the DNS panel saved what you typed. Run the DMARC checker immediately after publishing, and build records with the DMARC generator so the syntax is correct before it ever reaches DNS.

Mistake 8: ignoring subdomains and the sp tag

DMARC has a separate policy lever for subdomains, the sp tag, and overlooking it leaves a real gap. If you publish p=reject at the organisational domain but do not set sp, the subdomain policy defaults to the same value as p, which sounds safe. The problem appears when people assume the opposite, or when they want different behaviour for subdomains and never configure it.

The dangerous version is a domain that has no DMARC record on a subdomain it actually uses for sending, and assumes the parent policy covers it. Receivers do fall back to the organisational domain's policy for subdomains without their own record, but the alignment and reporting behaviour can surprise you if you have not thought it through.

Two scenarios to plan for:

• Unused subdomains should be locked down. Attackers love to spoof news.example.com precisely because nobody is watching it. Setting sp=reject at the parent slams that door.
• Subdomains with their own senders (say mail.example.com running a bulk platform) may need their own DMARC record so you can monitor and tune them independently.

We go deeper in do subdomains need their own DMARC record. The short version: decide your subdomain policy on purpose rather than by accident.

Mistake 9: setting up DMARC reports and then never reading them

A rua tag without a process behind it is theatre. The reports arrive as gzipped XML attachments, often dozens per day from different receivers, each one a wall of IP addresses and pass/fail counts. If nobody parses them, they pile up in a mailbox and the whole point of the monitoring phase is lost.

This is where rollouts stall. People publish p=none, the reports start coming, the XML is unreadable, momentum dies, and the domain sits unprotected for months. The data needed to advance to enforcement is sitting right there, unread.

Two related variants:

• Reports that look empty. Sometimes you genuinely get very little, which usually points at a rua problem or very low mail volume. We troubleshoot that in why are my DMARC reports empty.
• Misreading what the reports say. A column of failures from an IP you do not recognise might be a spoofer (good, the policy is working) or a forgotten legitimate sender (urgent, fix before enforcing). Telling them apart is the whole skill, and we walk through a real example in reading your first DMARC report.

To avoid this, do not commit to parsing XML by hand. Feed reports into the DMARC report analyzer for a one-off look, and use ongoing monitoring so that new and changed senders surface as alerts rather than as buried attachments.

Mistake 10: configure once, then never watch for drift

The final mistake is treating DMARC as a project that finishes. It is not. Your mail estate changes constantly. Marketing adopts a new email platform. A developer adds a transactional provider for password resets. Someone migrates a mailbox and the return-path changes. A DNS edit elsewhere in the zone accidentally clobbers a DKIM selector. Any of these can break alignment for a real sender, and at p=reject that means lost mail, often without an obvious alarm.

The reverse risk is regression: a well-tuned p=reject record gets edited back down to p=none during unrelated DNS work, or the whole record gets deleted, and your hard-won protection evaporates silently.

To avoid drift:

• Keep continuous monitoring in place so a new failing sender or a downgraded policy triggers an alert, not a customer complaint.
• Re-run the diagnostic tools after any DNS change, however unrelated it seems.
• Treat the addition of any new sending service as a DMARC task. The question "have we aligned this for DMARC?" belongs in the rollout checklist for every new email platform.

Configuration is a snapshot; deliverability is a moving target. The reason the hosted platform exists is that this watching never really stops, and a human team plus automated alerting is more reliable than remembering to check.

Tying it together

Most DMARC disasters are not exotic. They are the same handful of mistakes repeated:

• Enforcing before the evidence supports it, or never enforcing at all.
• Confusing a passing authentication check with passing DMARC, when alignment is the real test.
• Forgetting third-party senders, blowing the SPF lookup limit, or running weak DKIM.
• Fat-fingering the DNS record, ignoring subdomains, ignoring reports, and letting the configuration drift after launch.

Avoiding all ten comes down to a single discipline: change deliberately, measure with real report data, and keep watching after you reach enforcement. Start by confirming what your domain publishes today with the free DMARC checker, read the broader picture in the requirements overview, and if any term here is unfamiliar the glossary has plain-language definitions.

If you would rather not own the whole rollout yourself, the done-for-you DMARC service takes a domain from p=none to p=reject on the evidence, with no email outage, and keeps monitoring for drift once you are there. Either way, the destination is the same: a domain that genuinely cannot be spoofed, reached without breaking a single legitimate message.