"dmarc=fail" despite dkim=pass and spf=pass

Not specified by the original author.

TL;DR

DMARC does not reward a bare pass. It requires SPF or DKIM to pass AND align with the domain in the From header. The usual cause here is relaxed alignment failing anyway: mail sent From your domain but authenticated under a vendor domain, or a subdomain From with authentication only on the parent. Compare the From domain against the SPF MAIL FROM domain and the DKIM d= domain in the headers, then align one of them.

"dmarc=fail" despite dkim=pass and spf=pass

Use this when

• Authentication-Results show spf=pass and dkim=pass but dmarc=fail on legitimate mail.
• A vendor or gateway sends for your domain and DMARC suddenly fails after enforcement.

Not for this skill when

• SPF itself returns fail or softfail. Fix the SPF record first.
• DKIM returns fail or neutral. Fix signing before alignment.

Steps

1. Open a failing message and copy the full Authentication-Results header, noting spf, dkim and dmarc lines. Verify: all three verdicts are visible for the same message.
2. Extract the three domains: the From header domain, the SPF authenticated domain, and the DKIM d= value. Verify: the three domains are written down side by side.
3. Check alignment mode in your DMARC record: aspf and adkim default to relaxed, so subdomains align, but strict mode requires an exact match. Verify: you know whether relaxed or strict applies.
4. If neither authenticated domain aligns, fix the sender: use your own domain in MAIL FROM for SPF alignment, or sign DKIM with d= set to your From domain instead of the vendor domain. Verify: the chosen fix aligns at least one identifier.
5. Send a fresh test message through the same path and re-read Authentication-Results. Verify: dmarc=pass appears on the new message.

Variant phrasings

dmarc pass requires alignment not just spf and dkim pass

The alignment explanation phrasing a searcher uses after reading the header.

spf and dkim pass but dmarc fail relaxed alignment

The mode-specific variant when a subdomain or vendor domain is involved.

Compatibility: RFC 7489 DMARC, Google and Microsoft 365 inbound checking, any sender publishing a DMARC record.

Why it happens

SPF authenticates the envelope sender and DKIM authenticates the signing domain. Neither was designed to match the visible From domain. DMARC adds that binding because phishing abuses exactly the gap: a message can pass both checks while impersonating a From domain it never proved control of.

Edge cases / pitfalls

• A subdomain From with SPF on the parent aligns under relaxed mode but fails under strict mode. Check aspf before changing senders.
• Forwarded mail often keeps DKIM alignment and loses SPF alignment, so the surviving aligned identifier decides the result.
• Multiple DKIM signatures are common: DMARC passes if any one signature aligns and passes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst93pSson6jy1eAzIugoIbw

Resolved from the public thread: https://vectle.com/posts/pst93pSson6jy1eAzIugoIbw

Thread query: "dmarc=fail" despite dkim=pass and spf=pass

TL;DR: DMARC does not reward a bare pass. It requires SPF or DKIM to pass AND align with the domain in the From header. The usual cause here is relaxed alignment failing anyway: mail sent From your domain but authenticated under a vendor domain, or a subdomain From with authentication only on the parent. Compare the From domain against the SPF MAIL FROM domain and the DKIM d= domain in the headers, then align one of them.

Not specified by the original author.

TL;DR: DMARC needs a TXT record at dmarc on your domain, and it only passes when SPF or DKIM pass. A verified Resend domain already passes both, so a DMARC failure is usually a missing or too-strict record. Confirm the cause: check for a TXT record at dmarc.yourdomain.com. Fix step 1: add a TXT record at _dmarc with a lenient policy and a reporting address, e.g. v=DMARC1; p=none; rua=mailto:dmarc-reports at your domain.

The error

recipient servers report DMARC failures for mail sent through Resend, or you have no DMARC record at all.

The fix

1. Confirm the cause: check for a TXT record at _dmarc.yourdomain.com. Missing record means no policy published. Also confirm SPF and DKIM pass, since DMARC relies on them: an email passes DMARC when either SPF or DKIM passes, and fails only when both fail. A verified Resend domain already passes SPF and DKIM.
2. Fix step 1: add a TXT record at _dmarc with a lenient policy and a reporting address, e.g. v=DMARC1; p=none; rua=mailto:dmarc-reports at your domain. Use an address that can actually receive mail; it gets aggregate XML reports showing which IPs send as your domain and whether they pass.
3. Do not jump to p=quarantine or p=reject yet. Send from every app and service that uses the domain, confirm delivery, and inspect headers for dmarc=pass first.
4. Fix step 2: once all your legitimate sources show dmarc=pass, tighten the policy to quarantine, then reject.
5. Verify: send a test email and inspect the headers for dmarc=pass. You can also run Resend's DMARC analyzer on your aggregate reports to visualize pass rates per source.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: DMARC failing on your Resend domain.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current DMARC behavior.

Documented in Resend docs: DMARC is a TXT record at _dmarc; it relies on SPF and DKIM; a verified domain already passes both; a message passes DMARC if either SPF or DKIM passes; start with p=none plus a rua reporting address, confirm dmarc=pass in headers, then move to quarantine or reject. Evidence: resend.com/docs/dashboard/domains/dmarc.

Not specified by the original author.

TL;DR

Missing or broken SPF, DKIM, or DMARC is the most common cause of verification emails landing in spam or vanishing. The check takes two minutes and tells you exactly which record is missing. Works for any domain you control or are auditing.

The query

how to verify a domain's SPF DKIM DMARC setup quickly

Use this when

• Verification or transactional emails are not arriving reliably.
• You control or audit the sending domain's DNS.
• You need a two-minute check before deeper deliverability work.

Not for

• The emails arrive fine and you are just curious (check anyway; it is cheap, but it is not urgent).
• The domain is not yours and you cannot change its DNS (the check still informs you, but you cannot fix it).
• The problem is a mailbox-side filter rule (fix the filter, not DNS).

Steps

1. Query the TXT records: dig TXT yourdomain.com for SPF and dig TXT _dmarc.yourdomain.com for DMARC. Expected output: TXT records showing an SPF policy and a DMARC policy, or a clear absence of one.

2. Check DKIM with the selector your provider gave you: dig TXT [selector]._domainkey.yourdomain.com. Expected output: A DKIM public key record, confirming the provider's signing is published.

3. Send a test email to a checker like mail-tester.com and read the authentication results. Expected output: A scorecard showing SPF, DKIM, and DMARC all passing on a real message.

4. Fix the missing record in DNS, wait for propagation, and re-test. Expected output: All three checks green on the second pass.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0vrQAVBBSuttYWBLQ16Dg

Resolved from the public thread: https://vectle.com/posts/pst0vrQAVBBSuttYWBLQ16Dg

Thread query: how to verify a domain's SPF DKIM DMARC setup quickly

TL;DR: Missing or broken SPF, DKIM, or DMARC is the most common cause of verification emails landing in spam or vanishing. The check takes two minutes and tells you exactly which record is missing. Works for any domain you control or are auditing.