Email/

How to Fix DMARC Failures

When legitimate mail fails DMARC, the cause is almost always one of a few predictable things: a missing or misaligned SPF or DKIM result, forwarding that breaks SPF, or a third-party sender that was never authenticated for your domain. The fix is rarely loosening your policy. It's finding the source and authenticating it properly.

How do I know what's failing?

Start with your reports, because they tell you exactly which source is failing and why. Your aggregate reports break mail down by sending IP and show the SPF and DKIM results plus alignment for each. A source showing pass for the raw check but fail after alignment is the most common pattern, and it points straight at the problem. If you're not comfortable reading them yet, how to read a DMARC report walks through the fields.

Once you can see which source is failing, it's almost always one of the causes below.

Cause 1: An alignment gap

This is the big one. SPF or DKIM passes, but for a domain that doesn't match your visible From address, so DMARC counts it as a fail. It usually means a sending service authenticates with its own domain instead of yours.

The fix is to bring the service into alignment. For SPF, that means sending with a Return-Path (bounce domain) on your own domain. For DKIM, it means signing with a key published on your domain, so the signing domain matches your From. Most email platforms support a custom domain for exactly this: you publish a CNAME or two and the alignment falls into place. The concept is explained in how DMARC works.

Cause 2: Forwarding

Forwarding quietly breaks SPF. When a message is forwarded, the forwarding server sends it onward, and that server isn't in your SPF record, so the SPF check fails at the final destination. There's not much you can do about other people's forwarding rules.

The good news is that DKIM usually survives forwarding, because the signature travels with the message. This is exactly why DMARC passes on either SPF or DKIM: as long as your DKIM is solid and aligned, forwarded mail still passes DMARC even when SPF drops. The practical fix for forwarding failures is to make sure DKIM is correctly set up and aligned, then stop worrying about the SPF column for forwarded mail.

Cause 3: A third-party sender you forgot

Almost every organization sends through more services than it remembers: a CRM, a help desk, an invoicing tool, a marketing platform, a survey service. Each one needs to be authenticated for your domain, or its mail fails DMARC. New sources showing up in your reports are usually one of these.

Work through them one at a time. For each legitimate service, follow its instructions to set up SPF and DKIM on your domain (the wording is often "authenticate your domain" or "use a custom sending domain"). Then confirm in your next reports that the source has flipped to passing and aligned. Keep a running list, because this is the part that drifts as teams adopt new tools.

Cause 4: SPF too broad, or over the lookup limit

Two SPF-specific traps. If your SPF record has grown past 10 DNS lookups (a hard limit in the spec), it can fail outright, taking otherwise-fine mail down with it. And an overly permissive record can pass mail you didn't intend to authorize. Audit your SPF record, consolidate include: entries if you're near the limit, and remove services you no longer use.

What you should not do

Don't fix failures by weakening your policy back to p=none and leaving it there. That makes the reports stop bothering you, and it also stops protecting anyone, so the spoofing problem you were solving is wide open again. Treat a failure as a signal to authenticate a source, not a reason to retreat. The one legitimate way to ease off is using pct= to ramp enforcement gradually, which what is a DMARC policy covers.

Put it together

Read the report, find the failing source, decide whether it's legitimate, and either authenticate it or recognize it as spoofing you're now blocking. Work the list until every real sender passes and aligns, and your policy can sit safely at reject. If you're still setting things up, how to set up DMARC covers the foundation, and Bird's authentication guide has the domain-specific records. Most failures look alarming and turn out to be a five-minute alignment fix once you know which source to chase.

Empieza con un canal.
Añade los demás cuando estés listo.

Una clave API de prueba es tuya de inmediato. El acceso a producción se desbloquea cuando añades un método de pago y verificas un remitente.

¿Usas Claude Code, Cursor o Codex? Copia un prompt de configuración y tu agente instalará el Bird CLI y las habilidades por ti. Elige el tuyo:

Cursor