DMARC alignment, and why SPF passing is not enough
DMARC does not care that SPF passed. It cares that the domain SPF passed for matches the domain in the From header your recipient sees. That mismatch is the most common invisible DMARC failure.
What this actually means
This is the common pattern we see when dmarc alignment comes up in search.
Run the free checker on your domain to see your own numbers. The checker shows the full SPF include chain, the exact lookup count, and which selector actually exists for DKIM.
Why it matters for payment flows
Customers who pay successfully but never get a receipt, invoice or status update assume the payment failed. Support tickets follow, refunds are requested, and the engineering team spends hours debugging a webhook that never had a chance to be read.
What to do next
- Check the domain with the free tool.
- Fix the mechanical issue first — lookup limit, missing DKIM, absent DMARC. Those are checkable in under a minute.
- If email authentication is clean and the customer still sees nothing, the fault is downstream: a webhook that failed signature verification, an event type you never subscribed to, or a status that never synced.
Sources and standards
- RFC 7208 SPF, RFC 7489 DMARC, RFC 6376 DKIM — the actual specifications, not a blog summary.
- Lookup counts measured live with the engine in this repo, https://payflowfix.dev.
FAQ
DMARC alignment: why SPF passes but DMARC still fails
Where does this fit in a payment flow?
Can I check this myself?
Do you log my domain?
Still broken after the DNS is right?
Email authentication is DNS. Payment notifications not arriving is usually not — it is a webhook that failed signature verification, an event type you never subscribed to, or a status that never synced. That is what I fix: a fixed-fee $99 root-cause diagnosis, credited toward the repair.