Top 10 Email Authentication Mistakes: SPF, DKIM and DMARC Errors and Their Fixes

Most organisations have SPF, DKIM and DMARC records, yet many still let attackers send mail as their domain, or have their own legitimate mail rejected, because of a handful of repeat mistakes. This list ranks the ten email authentication errors that most often leave domains spoofable or break delivery, with how to spot each one in DNS and in DMARC reports and exactly what to change. It reflects the standards as they stand on 8 November 2026, including RFC 9989, the May 2026 DMARC standard that obsoletes RFC 7489, and the bulk sender requirements published by Yahoo and Microsoft. It is written for email administrators, DNS owners and security teams. For how the three protocols work, read the DMARC, SPF and DKIM Guide; for the wider threat list, see the Top 10 Email Security Threats.

Key takeaways

• p=none is not protection. RFC 9989 defines p=none as Monitoring Mode, where the domain owner expresses no handling preference for failing mail, so spoofed messages are still delivered.
• SPF breaks silently. More than 10 DNS-querying terms, more than two void lookups or two SPF records all produce permerror, which receivers may treat as a failure.
• Alignment is what DMARC checks. SPF or DKIM passing for a vendor's domain does not help unless that domain aligns with the visible From domain.
• Every domain needs a record, including the ones that never send. NCSC publishes a four-record set for parked domains that stops them being used for spoofing.
• The standard has moved. RFC 9989 removes the pct tag, adds np, psd and t, and replaces Public Suffix List lookups with a DNS tree walk, so old staging habits need review.

The Top 10 at a glance

1. Staying at p=none indefinitely

RFC 9989 describes p=none as Monitoring Mode: the domain owner still receives aggregate reports but "expresses no handling preference" for messages that fail DMARC. It is the right first step and the wrong destination. Large mailbox providers now require bulk senders to publish DMARC, but only at p=none as a minimum: Yahoo's sender requirements, enforced from February 2024, ask bulk senders for at least p=none, and Microsoft's Outlook.com requirements for domains sending more than 5,000 messages a day, effective 5 May 2025, set the same floor. Many organisations met the requirement and stopped there.

• Check: query _dmarc.example.com TXT for every domain and list those at p=none, with the date the record was first published.
• Fix: set a dated plan to move to p=quarantine and then p=reject once aggregate reports show all legitimate sources passing with alignment, as Microsoft also recommends (none, then quarantine, then reject). See the Email Authentication Checklist.

2. SPF over the 10-lookup limit

RFC 7208 Section 4.6.4 says implementations "MUST limit the total number of those terms to 10", counting the include, a, mx, ptr and exists mechanisms and the redirect modifier, but not all, ip4, ip6 or exp. It also says implementations should limit void lookups (queries returning no data or a name error) to two. Exceeding either limit returns permerror. Each new SaaS sender adds an include, and nested includes count too, so records drift over the limit without anyone editing them. Microsoft's Outlook.com guidance notes that more than 10 SPF lookups can cause SPF to fail.

• Check: expand the record recursively and count DNS-querying terms; look for permerror in DMARC aggregate reports.
• Fix: remove includes for services no longer used, move bulk and marketing senders to their own subdomains with their own SPF records, and if you flatten includes to IP ranges, automate updates because vendors change their ranges.

3. Multiple or malformed SPF records

RFC 7208 Section 3.2 states that a domain "MUST NOT have multiple records" that would select more than one SPF record, and Section 4.5 says that if more than one record is found, the check produces permerror. This happens when a second team adds a new v=spf1 TXT record instead of editing the existing one. The ptr mechanism is marked "do not use" in Section 5.5 and should not be published.

• Check: list all TXT records beginning with v=spf1 at each name; check for ptr, syntax errors and records longer than a single DNS string without proper splitting.
• Fix: merge into one record, remove ptr, and route all SPF changes through one owner with a change ticket.

4. Third-party senders not aligned

DMARC passes only if SPF or DKIM passes for a domain that aligns with the RFC 5322 From domain: relaxed alignment (the default adkim=r and aspf=r) allows a subdomain match, strict alignment requires an exact match. A CRM or ticketing platform that signs with its own DKIM domain and uses its own return-path produces SPF and DKIM passes that do nothing for your DMARC. Microsoft's Outlook.com requirements state that the From domain, or a subdomain of it, must match the domain used by SPF or DKIM, and that third-party senders still require records in your own DNS.

• Check: in aggregate reports, group sources that pass SPF or DKIM but fail DMARC, which almost always means an unaligned vendor.
• Fix: configure each vendor with a custom DKIM selector in your domain and, where supported, a custom return-path; give vendors a dedicated subdomain where they cannot align on the main domain. See the Email Authentication for Developers Guide.

5. Parked domains and subdomains left open

Domains bought for brand protection, old product names and acquired companies' domains often have no SPF or DMARC at all, which makes them ideal for spoofing. The NCSC recommends four records for parked domains: v=spf1 -all, a DMARC record with p=reject and an rua address, a null MX (MX 0 .) where the domain has an A record but no MX, and a wildcard DKIM record with an empty key (*._domainkey TXT "v=DKIM1; p="). RFC 9989 also provides the sp tag for existing subdomains and the np tag for non-existent subdomains, which otherwise inherit p.

• Check: reconcile the domain registrar inventory with DNS, and test subdomains that do not exist to see which policy applies.
• Fix: publish the NCSC parked-domain set on every non-sending domain, and add np=reject at the organisational domain once all sending subdomains are known.

6. Weak, shared or never-rotated DKIM keys

RFC 8301 states that signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits", and that rsa-sha1 "MUST NOT be used for signing or verifying". RFC 6376 explains that selectors exist so public keys can be replaced on a routine basis, advises assigning new keys to new selectors rather than reusing a selector, and says an empty p= value means the key has been revoked. Keys created years ago by a departed administrator, or shared across many vendors, are a quiet risk. See the Cryptographic Key Management Guide.

• Check: list every selector you publish, its key length and which system holds the private key.
• Fix: move to 2048-bit RSA, rotate on a schedule by publishing a new selector, switching signing, and keeping the old public key for a validation interval before revoking it with an empty p=.

7. Using the DKIM l= body length tag

The l= tag tells verifiers to check only the first part of the message body. RFC 6376 Section 5.4.1 warns that it can allow "complete alteration of the text of the message without invalidating the signature" and that it is "likely to convey no additional benefit while providing an avenue for unauthorized addition of text". An attacker can append content to a genuinely signed message and it still passes.

• Check: inspect DKIM-Signature headers on outbound mail from every sending platform for an l= tag.
• Fix: configure signers to sign the full body; if a vendor cannot, move it to a subdomain with a stricter policy.

8. No reporting, or reports nobody reads

Without the rua tag, a domain owner has no view of who sends as the domain, which sources fail, or whether spoofing is happening. RFC 9989 requires receivers that send aggregate reports to support mailto: addresses. Microsoft sends aggregate reports to rua addresses and does not plan to send failure (ruf) reports, so aggregate data is the dependable source. Reports sent to a personal mailbox, or to a vendor contract that has ended, are as bad as none. See the DMARC Buyer's Guide.

• Check: confirm every DMARC record has an rua address that is monitored, and that external report destinations are authorised.
• Fix: send reports to a group mailbox or reporting service, review weekly during rollout and monthly after, and alert on new sending sources.

9. Staging with pct under RFC 9989

RFC 7489 allowed pct to apply a policy to a percentage of failing mail. RFC 9989 drops pct from the tag list (its appendix covers the removal) and adds t, a test mode: t=y asks receivers not to apply the policy as published, with handling expected to be one level lower, for example reject treated as quarantine, without affecting reports. Records written for the old standard, such as p=reject; pct=10, may not behave as their authors expect at receivers that implement the new standard. See the DMARCbis Changes Guide.

• Check: search all DMARC records for pct values below 100.
• Fix: stage enforcement with t=y and by subdomain, then remove pct; document the date each domain reached full enforcement.

10. Ignoring forwarding and mailing lists

Forwarding changes the connecting server, so SPF fails, and mailing lists that edit subjects or footers can break DKIM. Microsoft's Outlook.com guidance notes that forwarding can break DMARC alignment and recommends ARC for forwarders and mailing lists. Organisations that move to p=reject without signing all mail with aligned DKIM see genuine messages rejected after forwarding, and often retreat to p=none.

• Check: in aggregate reports, look for failures from known forwarding services and list servers where DKIM is absent or broken.
• Fix: sign every outbound stream with aligned DKIM, since DKIM survives plain forwarding, and enable ARC sealing on any gateway or list server you operate.

Detection: what to monitor

Measures that show progress: percentage of owned domains at p=reject (including parked domains); percentage of legitimate volume passing DMARC with alignment; number of unrecognised sending sources per month; SPF lookup count per sending domain (target well under 10); percentage of DKIM keys at 2048 bits and rotated within policy; and time from a new vendor going live to its alignment being confirmed.

Common failure patterns

• Treating DMARC as anti-phishing: DMARC stops exact-domain spoofing; lookalike domains (ATT&CK T1583.001) and compromised genuine accounts still pass, so user reporting and inbound filtering remain necessary. See the Email Identity and BEC Guide.
• No owner for DNS email records: marketing, IT and vendors all edit TXT records and nobody reviews the result.
• Enforcing before inventorying: moving to reject without knowing all senders causes outages and a rapid return to none.
• Forgetting acquired and regional domains: the main domain is at reject while dozens of others have no records.
• Vendor offboarding without DNS clean-up: includes and DKIM selectors for old vendors stay published, keeping their ability to send as you.

Mapping to frameworks

CIS Controls v8.1 Safeguard 9.5 is "Implement DMARC", and US federal civilian agencies have been directed by CISA to reach p=reject under Binding Operational Directive 18-01.

Where to start

1. Week 1: export every domain you own from the registrar and record its SPF, DKIM selectors and DMARC policy in one sheet.
2. Week 2: publish the NCSC parked-domain records on every non-sending domain; these carry little risk because the domains send no mail.
3. Weeks 3 to 6: point rua at a monitored destination, fix SPF lookup counts and duplicates, and align each vendor using aggregate reports.
4. Month 2: move sending domains to p=quarantine with t=y where supported, watch reports and bounces for two weeks, and roll back by reverting the record if genuine mail fails.
5. Month 3: move to p=reject, add np=reject, rotate DKIM keys to 2048 bits, and schedule quarterly reviews.

Practitioner checklist

• Every owned domain has a DMARC record, with a dated plan to reach p=reject.
• One SPF record per name, under 10 DNS-querying terms, no ptr.
• Every third-party sender aligned through custom DKIM or a dedicated subdomain.
• NCSC parked-domain records on all non-sending domains.
• DKIM keys at 2048-bit RSA, no rsa-sha1, rotated with new selectors, old keys revoked.
• No l= tag on any outbound DKIM signature.
• rua reports go to a monitored destination and are reviewed.
• No pct values below 100; staging uses t=y and subdomains.
• ARC enabled on gateways and list servers you operate.
• Vendor offboarding includes removing SPF includes and DKIM selectors.

Standards and references

• IETF: RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• IETF: RFC 7208 Sender Policy Framework (SPF)
• IETF: RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
• IETF: RFC 8301 Cryptographic Algorithm and Key Usage Update to DKIM
• NCSC: Protecting parked domains
• NCSC: Email security and anti-spoofing
• Yahoo: Sender Best Practices
• Microsoft: Outlook's new requirements for high-volume senders

Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide, Top 10 Email Security Threats, Email Security Guide, SMTP Security, STARTTLS and MTA-STS Guide.