Three mechanisms, three different jobs
SPF publishes, in DNS, which IP addresses are allowed to send mail for your domain. DKIM attaches a cryptographic signature so a receiver can verify the message was not altered in transit and that it came from a domain holding the private key. DMARC ties them together: it checks whether the domain that passed SPF or DKIM aligns with the domain in the visible From header, and tells receivers what to do when neither aligns.
The trap is that SPF and DKIM can each "pass" against a domain that is not your From domain — the bounce Return-Path for SPF, or a provider's signing domain for DKIM — and DMARC alignment is what catches that.
SPF breaks when you add a second sender
SPF allows only one SPF record per domain, and it permits at most 10 DNS lookups while evaluating includes. Adding a second email provider is the most common way senders end up with two SPF records (which is invalid) or an eleventh lookup (which is PermError). Void lookups — includes that return an empty answer — also count against you.
The fix is to consolidate into a single record, count nested includes before publishing, and be cautious with SPF flattening, which trades the lookup limit for the ongoing job of maintaining a vendor's IP list yourself.
DKIM breaks at the signing boundary and at rotation
DKIM's body hash covers the message body as it was when signed. A gateway that appends a footer after signing, or a canonicalization mismatch, produces a "body hash did not verify" failure even though the key is fine. RFC 8301 sets the minimum acceptable key length, and rotating a selector without overlapping the old and new records breaks in-flight mail.
A provider change can also leave a CNAME and a TXT record fighting at the same selector name. Rotation should always publish the new selector, wait for propagation and in-flight mail to clear, then remove the old one.
What RFC 9989 changed for DMARC in 2026
In 2026 the IETF published RFC 9989, 9990 and 9991, replacing the 2015 DMARC RFC. The pct tag was removed because receivers implemented it inconsistently; staged rollout now uses a simple testing flag instead of a percentage. The ri tag and the report-URI size suffix are historic. Policy discovery no longer relies on the Public Suffix List: receivers perform a DNS tree walk, climbing label by label to find the first DMARC record and the Organizational Domain.
The sp and np tags now clearly separate policy for existing subdomains from policy for nonexistent subdomains. If your setup spans more than one label, publish DMARC at the Organizational Domain so the tree walk finds it for every subdomain, and revisit any rollout plan written before 2026.
Reading authentication failures from receiver codes
When mail is rejected or deferred, the enhanced status code and diagnostic text usually point at the layer. Gmail 5.7.26 and 5.7.30 are authentication failures; Outlook 550 5.7.515 asks you to raise your authentication level; Gmail 4.7.28 flags an unusual rate tied to your DKIM domain. Each maps to a specific check to run before resending.
The recovery pattern is the same across receivers: confirm SPF, DKIM and DMARC currently pass for the exact From domain, identify what changed, and resend a small verified batch before resuming normal volume.
Common questions
Can I publish more than one SPF record if I use several email providers?
No. A domain may have only one SPF TXT record. Multiple records is a permanent error. Combine all authorized senders into a single record and keep the total DNS lookups at or under ten, counting nested includes.
What changed for DMARC in 2026?
RFC 9989, 9990 and 9991 replaced the 2015 DMARC RFC. The pct tag was removed in favour of a plain testing flag, the ri tag and report-URI size suffix became historic, and policy discovery switched from the Public Suffix List to a DNS tree walk that climbs the domain label by label.
If SPF and DKIM can pass on their own, why does DMARC exist?
SPF and DKIM each prove something about a domain, but not necessarily your visible From domain — SPF checks the bounce Return-Path, DKIM checks whatever domain holds the signing key. DMARC adds the alignment test and a published policy, so receivers know what to do when neither authenticated domain matches the From address a person sees.
What DKIM key length should I use?
Use 2048-bit. RFC 8301 sets 1024-bit as the floor and expects signers to move above it. Longer keys are fine; the practical limit is what your DNS provider allows in a single TXT record, which sometimes requires splitting the value.
How do I roll out DMARC without blocking my own legitimate mail?
Publish at p=none first and use the aggregate reports to find every legitimate sending source and confirm it aligns. Only tighten to quarantine or reject once the reports are clean. Under RFC 9989 the staged step uses a plain testing flag rather than the removed percentage tag.
Do I need a DMARC record at my subdomain or at my main domain?
Publish at your Organizational Domain. The 2026 DNS tree walk means receivers will find that record for subdomains that have none, and the sp and np tags let you set separate policy for existing and nonexistent subdomains from that one record.