Almost every email-security problem we see comes down to a small set of DNS mistakes. The good news is that they are predictable, and DMARCER flags most of them for you automatically. This article walks through the ones that catch people out most often, what each one does to your mail, and how to put it right with your DNS provider.
How DMARCER spots DNS mistakes
When DMARCER checks a domain it runs a series of checks on your SPF, DKIM, DMARC, MX, MTA-STS and TLS reporting records. Each check looks at what is actually published in your DNS and raises a finding with a short explanation and a suggested fix. You do not have to wait for the next scheduled scan: open the kebab menu on a domain and choose Recheck now, or tick several domains and use Recheck selected. Rechecks read your DNS live with no caching delay, so a record you have just published will be seen straight away.
Because rechecks read your live DNS, they are also the quickest way to confirm a fix. After you edit a record with your provider, run Recheck now and the finding should clear once your change has had time to take effect.
Getting the record basics right
The most common failures are not clever policy errors; they are simple typing slips when entering a record into your provider's console.
- Wrong record type. SPF, DMARC, DKIM and the DMARCER ownership record are all TXT records. If you save one as a CNAME, A or anything else, it will not be found.
- Wrong host or name field. SPF lives at the root of the domain, DMARC lives at _dmarc.yourdomain, and a DKIM key lives at selector._domainkey.yourdomain. Putting the value in the wrong name field is the same as not publishing it at all.
- Stray spaces or quotes. Copying a value can bring in spaces at the start or end, smart quotes, or an extra set of quotation marks. Paste into a plain text field first and check the very start and end of the value carefully.
- Editing the wrong zone. If your domain uses one provider for DNS and another for hosting, make sure you are editing the live zone that is actually in use, not a parked or spare one.
When you first add a domain, DMARCER asks you to prove ownership by publishing a TXT record at the root of the domain. The Verify Domain Ownership dialog shows you the exact Name and Value, with a copy button next to each. Checking runs automatically, or you can press Recheck Now once you have published the record. Use the copy buttons rather than retyping to avoid the spacing and quoting mistakes above.
Only one record per name
Several record types must appear exactly once. When two copies exist, DNS hands them back in no particular order, so different receiving mail servers can see different policies. The result is behaviour that is inconsistent and hard to pin down.
- More than one SPF record. A domain must publish a single v=spf1 record. Having two is treated as a clear error by receivers, so combine all your sending sources into one record instead.
- More than one DMARC record. There must be exactly one v=DMARC1 record at _dmarc.yourdomain. If two exist, keep the one with the strictest policy (p=reject, then p=quarantine, then p=none) and the most complete rua reporting list, and delete the rest.
- More than one DKIM record for a selector. Each DKIM selector should resolve to a single TXT record. Two records on the same selector make signed mail pass for some receivers and fail for others. If a key change left an old record behind, keep the one matching your current signing key and remove the others.
DMARCER raises these as critical findings because the effect is serious: across the many mail servers that receive your email, your protection against spoofing effectively becomes a coin toss.
SPF-specific pitfalls
SPF has a few traps of its own, beyond simply having more than one record.
- The record is too long. As an SPF record nears the size limit DNS allows for a single record, it can be cut short, and receivers then either fall back to a slower lookup or treat SPF as unavailable. DMARCER warns you once a record reaches 450 characters. The usual fix is to open the SPF modal for the domain and turn on SPF Flattening, which condenses your list of sending sources into one compact, hosted list of IP addresses.
- The ptr mechanism. Using ptr in an SPF record is discouraged by the standard because it relies on a slow reverse lookup that many receivers skip or get wrong. Replace it with explicit ip4, ip6 or include entries for your real sending services.
- Both redirect= and all. If a record contains a redirect= modifier and an all terminator, receivers quietly ignore the redirect and use the local all instead, so the shared policy you were pointing at is skipped. Stick to one approach: either redirect= with no local all, or an explicit all with your senders listed directly.
Tag order and copy-paste traps
DMARC records are read one tag at a time, and the v=DMARC1 tag must come first. A very common mistake is pasting rua=mailto:... ahead of v=DMARC1 when copying a snippet from a reporting service's setup instructions. If v=DMARC1 is not the first tag, receivers reject the whole record and treat your domain as having no DMARC policy at all, even though the TXT record is clearly there. This fails quietly: aggregate reports stop arriving and enforcement never happens. Edit the record so it starts with v=DMARC1; followed by the other tags, each separated by a semicolon.
MX and CNAME pitfalls
An MX record must point at a hostname that resolves directly to A or AAAA records, never to a CNAME. This trips people up surprisingly often, because some mail providers' setup wizards suggest pointing MX at a branded alias that is itself a CNAME. Some receivers will follow the chain, but many reject the mail outright, so delivery becomes unreliable. If your provider gave you a CNAME alias, ask them for the direct hostname, or point your MX records straight at the provider's hostname rather than through the alias.
After any change, give DNS a little while to update and then run Recheck now from the domain's kebab menu. Because rechecks read your DNS live with no caching delay, a finding that clears is solid confirmation that your fix has landed.