dmarc=fail (p=REJECT): neither passing check matches your From domain

The receiving server checked DMARC on your From domain, the check failed, and the server refused the message because you publish p=reject. The Authentication-Results header shows which checks passed and for which domain, so read it field by field before you change anything.

Is the vendor's setup broken? No. Its SPF and DKIM pass for its own domain, and neither one aligns with your From address.

The Authentication-Results line

SPF and DKIM both passed here, and DMARC still failed.

• dkim=pass header.i=@vendor.net. The signature verified for vendor.net. For DMARC, the domain that counts is the signing domain d=, shown here as header.i. That isn't your domain, so it doesn't align.
• spf=pass ... smtp.mailfrom=bounces@vendor.net. SPF passed for the envelope sender's domain, which is the vendor's. That isn't your domain either, so it doesn't align.
• header.from=example.com. This is the From domain your recipient sees, and it's the one DMARC protects. Neither passing check matched it.
• p=REJECT. This is your published policy, as the receiver read it. sp=REJECT is the policy for your subdomains.
• dis=NONE. This is what the receiver actually did. It delivered this message despite your policy, so you can see failures in headers before you see any bounces. Another receiver can apply dis=reject to the same mail, and you only hear about that in aggregate reports.

Fixes

1. Find the sender in smtp.mailfrom or header.i. The domain there is your vendor's.
2. Complete that vendor's domain authentication so it signs with d=example.com. A signature on your own domain also survives forwarding. Our provider setup pages have the records for the common vendors.
3. Set a custom return-path if the vendor offers one. That aligns SPF too, so your mail can pass DMARC on either check.
4. Verify with the DKIM checker that the selector the vendor asked you to publish resolves, then send a test and read the header again. You want dkim=pass header.i=@example.com.

Alignment

DMARC passes when at least one of these is true, with the default relaxed matching:

• SPF passes and the envelope sender domain is your From domain or a subdomain of it. So bounces.example.com aligns with example.com, and bounces.vendor.net never does.
• DKIM verifies and the signature's d= is your From domain or a subdomain of it.

If you set aspf=s or adkim=s, a subdomain no longer counts and the domains must match exactly. The alignment guide works through the cases with real header examples.

Where the header is

• Gmail: open the message, three dots, Show original.
• Outlook on the web: three dots, View, View message source.
• Microsoft 365: the same line plus compauth=fail reason=000, Microsoft's composite verdict. A compauth failure with everything else passing usually means alignment as well.
• Anywhere: send a message to a mailbox you control at a provider that writes this header. Gmail is the most readable.

Other senders

A header shows you one message. Aggregate reports list every sender at once, and they're the only way to know you've found them all before you tighten a policy. To read them yourself, start with reading a DMARC report by hand.

If you lower your policy while you fix this sender, guided enforcement can move it back to p=reject. We move the policy a step at a time, and you approve each step. With hosted DMARC, we read the reports in the days after each step. When a sender you marked as yours sends enough mail to measure and a step starts blocking it, we put the previous policy back and email you. Our rollback rules list the thresholds. We can't bring back mail a receiver already refused. Rollback comes with the Starter plan and up. You can try it free for 30 days with no card. Set up guided enforcement.