The message translated
The receiver is saying: “This message claims to come from example.com. I could confirm that through neither SPF nor DKIM. The owner of example.com told me via DMARC to reject such messages — so I am rejecting it.”
Worth noting: the sender ordered this rejection. The policy comes from your own DNS.
Alignment — where it usually breaks
It is not enough for SPF or DKIM to return some pass. The domain they checked must align with the visible sender domain:
- SPF alignment compares the envelope-from (return-path) with the
From:header. - DKIM alignment compares the signature's
d=tag with theFrom:header.
The classic case: a newsletter service sends with From: info@yourdomain.com but sets the envelope-from to bounces@vendor.net. SPF passes — for vendor.net. For DMARC that is worthless, because the domains do not match.
With relaxed alignment (the default) matching at organizational level suffices, so mail.yourdomain.com and yourdomain.com align. With strict (aspf=s/adkim=s) it must be the very same domain.
Narrowing down the cause
- Did the mail actually come from you? If not, DMARC is working exactly as intended and is blocking a forgery in your name. Nothing to repair.
- Which service sent it? The
ruaaggregate reports show precisely that: which source, which results, which alignment. Without aruaentry you are guessing. - DKIM is the more reliable route. DKIM survives forwarding, SPF does not. If the vendor offers DKIM signing with your domain in the
d=tag, that is the sturdier fix — usually via a CNAME to a selector. - Or align the envelope-from. Many services allow a custom bounce subdomain such as
bounce.yourdomain.com. That makes SPF align too.
Do not roll the policy back
Switching from p=reject to p=none stops the rejections immediately — and simultaneously removes the protection you set DMARC up for. It only makes sense as a deliberate, time-boxed step back into monitoring mode while you get the sources in order.