The short version

Your mailbox provider is rarely the only thing sending as your domain. The CRM, the helpdesk, the invoicing and payroll tools, the newsletter platform and the website’s contact form all put example.com in the From line, and each one passes DMARC only if it signs with your domain’s DKIM or sends with a return path on your domain. Most don’t until you set them up. Find them in your aggregate reports before you tighten your policy, or p=reject will refuse their mail.

Why they fail DMARC

DMARC passes when SPF or DKIM passes for the domain in the From address. A service sending as billing@example.com usually:

  • sends with its own return path, such as bounces.service.example.net. SPF checks that domain, so SPF passes for the service, not for you;
  • signs with its own DKIM domain, with d=service.example.net in the signature. DKIM passes, again for the service.

Both pass, and DMARC still fails, because neither is aligned with example.com. We go through this in why SPF and DKIM can pass while DMARC fails.

Find them in your reports

Aggregate reports list every server that sent mail claiming your domain, with the SPF and DKIM domains it used. Three patterns to look for:

  • A steady sender with SPF and DKIM passing for another domain. A service of yours that isn’t aligned yet. This is most of the list.
  • A steady sender failing everything. A system of yours with no authentication at all: a scanner, a website form, an old server.
  • A burst from addresses you don’t recognise, then nothing. Someone spoofing the domain. Nothing to fix; it’s what p=reject is for.

Reading raw XML is slow; the XML-to-human Converter turns one report into a table in your browser. In DMARCLoop, the Sources tab sorts senders into Compliant, Known sender, failing, Forwarded and Unknown or threat, and a recognised sender comes with its fix (identify your sending sources).

Fix each one

For each service, in its settings, look for a section called something like “domain authentication”, “sender authentication” or “custom domain”. It almost always gives you DNS records to publish:

  1. DKIM with your domain. One or more CNAME or TXT records under _domainkey.example.com. Once published and switched on, the service signs with d=example.com, and DKIM aligns. This is the fix that survives forwarding, so do it first.
  2. A custom return path. A CNAME such as bounce.example.com pointing at the service. SPF then checks a domain under yours and aligns (relaxed alignment counts subdomains).
  3. Or an SPF include. Adding the service to your SPF record helps only when it already sends with a return path on your domain, and each include costs DNS lookups against the limit of 10.

If a service can’t do any of these, move it to a subdomain such as mail.example.com with its own records, or have it send from its own domain with your address as the Reply-To.

Keep the list current

New tools get bought, and old ones keep sending long after anyone remembers them. Before each policy step, look at the reports for anything new. After you reach p=reject, keep watching: a sender that appears afterwards is refused from its first message, so the sooner you see it the better.

The path, with a date on each step, is in p=none to p=reject in 60 days.