Direct answer: An SPF or DKIM pass is not a DMARC pass. DMARC checks whether the domain that authenticated the message aligns with the visible From domain. If SPF passed on a vendor bounce domain while From is [email protected], you still have a DMARC fail — and in 2026 that fail can bounce bulk mail, not just land in a report.
The header pair that causes the ticket
Open the message source. Look for Authentication-Results, not the SPF record you published last year. A typical broken receipt looks like this:
Authentication-Results: mx.google.com;
dkim=pass header.d=bounce.vendor.com;
spf=pass smtp.mailfrom=bounce.vendor.com;
dmarc=fail header.from=example.comSPF did its job. It authorized the sending IP against the MAIL FROM / Return-Path domain. DKIM may have passed too — on the vendor’s signing domain. DMARC still failed because neither authenticated identifier aligned with the From the customer saw: example.com.
That distinction is the whole game. Receivers that enforce bulk-sender rules do not treat “something passed” as “the brand passed.” They ask whether the From domain is aligned with SPF or DKIM. Gmail’s bulk threshold (about 5,000 messages per day to personal Gmail) still requires that alignment. Non-compliant bulk can bounce with 550-5.7.26. High-volume mail to Microsoft consumer Outlook can bounce with 550 5.7.515 when the 5322.From fails the required authentication level — including DMARC fail after an SPF or DKIM pass on the wrong domain.
If you need the header roles themselves, they live in From, Reply-To, and Return-Path. If you need the record syntax, use SPF, DKIM, and DMARC explained. This article stays on pass versus align.
What “aligned” actually means
SPF authenticates the MAIL FROM / Return-Path domain. DKIM authenticates the domain in the signature’s d= tag. DMARC then compares those authenticated domains to the organizational domain of the visible From address.
Two modes exist. They are set on the From domain’s DMARC record, not on the vendor:
- Relaxed alignment (default). Organizational domains may match. From
[email protected]aligns with DKIMd=example.com, and with an SPF MAIL FROM on a subdomain ofexample.com(for example a custom bounce name under the same organizational domain). - Strict alignment. The domains must be identical. From
[email protected]requires DKIMd=example.comexactly, and an SPF MAIL FROM whose domain is exactlyexample.com— not a child. Set withadkim=sand/oraspf=s.
Relaxed is enough for Gmail and Yahoo bulk rules when the organizational domains match. Strict is a policy choice for brands that refuse any child-domain identity, not a receiver mandate. Do not flip both tags to s on a Friday if your sending stack still uses a bounce subdomain.
RFC 9989 (May 2026) did not change the alignment test. It changed how some receivers find the organizational domain: a bounded DNS tree walk (up to eight labels) instead of relying only on the public suffix list. In deep subdomain trees a 9989 receiver can compute a different organizational domain than an RFC 7489 / PSL receiver. That caveat belongs in SPF, DKIM, and DMARC on subdomains; it is not a reason to ignore alignment on the From you actually send.
Read the result as a four-cell table
| SPF | DKIM | Aligned with From? | DMARC |
|---|---|---|---|
| pass on vendor MAIL FROM | fail or missing | no | fail |
| pass on vendor MAIL FROM | pass, d= is the vendor |
no | fail |
| pass on a MAIL FROM under your org domain | fail | yes, via SPF (relaxed) | pass |
| fail or irrelevant | pass, d= is the From org domain |
yes, via DKIM | pass |
The third and fourth rows are the working designs. Most incident queues live in the first two. A vendor “domain verified” badge usually means the vendor can send something. It does not mean d= equals your From domain.
When two vendors share one From, the same table applies twice. One SPF record has to authorize both senders, and each vendor needs its own aligned selector. That failure mode is documented in Two vendors, one From address.
How the failure shows up in reports
Aggregate DMARC reports will show SPF as pass and DMARC as fail on the same row when the authenticated domain is the vendor bounce name. That is not a parser bug. The report is telling you the identifier that passed is not the identifier on the From line.
Do not start by tightening p=. Start by making one identifier align. Then read volume by source in How to read a DMARC report. Policy enforcement on an unaligned stream just turns a spam-folder problem into a bounce problem.
The two fixes that actually work
Fix A — aligned DKIM. Sign with a selector whose d= is the From domain (or, under relaxed alignment, the same organizational domain). This is the usual path for product mail. A DKIM pass on d=example.com carries DMARC even when SPF authenticated a bounce subdomain.
Fix B — aligned custom MAIL FROM. Put the Return-Path on a name under the From organizational domain and publish SPF there. Under relaxed aspf, that SPF pass aligns. Under strict aspf, the MAIL FROM domain must equal the From domain exactly, which most bounce infrastructures will not do.
ArawaMail’s documented sending path does both kinds of work for domains you actually added. Enable receiving first, then enable sending. Enabling sending writes DKIM CNAMEs on the Cloudflare zone and configures a custom MAIL FROM domain with MAIL FROM MX and SPF. That custom MAIL FROM is bounce-domain alignment infrastructure. It is not a DMARC publisher. You still own the _dmarc record on the From domain.
The HTTP API will not invent alignment for a lookalike you did not add. The from domain must belong to the API key’s company and have outbound sending active. A restricted key can only send from the one domain it is scoped to. Sending as a cousin domain the company never registered will not align through ArawaMail, because the message never leaves as that From in the first place.
Copy live DKIM CNAME and MAIL FROM values from the product on the day you enable sending. Public docs do not list the hostnames, and guessed bounce names do not belong in a runbook.
When you actually need strict alignment
Use strict when a child name must not inherit the parent’s identity: a sold subsidiary, a tenant platform, or a marketing subdomain you do not want to vouch for receipts. Use relaxed when billing, support, and the app share one organizational domain and you want a custom MAIL FROM subdomain to count.
BIMI sits on top of a passing, aligned DMARC policy at enforcement. Alignment is the prerequisite; the logo is not a substitute. See BIMI explained after the From domain already passes.
If marketing and transactional mail fight for the same apex reputation, split them onto authenticated children instead of tightening adkim as a substitute for inventory. That split is why marketing and transactional email should use separate subdomains.
What to check this afternoon
- Pick one failed message. Read
Authentication-Results:spf=,dkim=plusheader.d,dmarc=plusheader.from. - Ask which identifier is supposed to align. If DKIM
d=is the vendor, fix the selector. If only SPF passed, move MAIL FROM under your organizational domain or add aligned DKIM. - Confirm the From domain is a domain your sending platform actually hosts. On ArawaMail that means the domain is added, receiving is active, sending is active, and the API key is allowed to use it.
- Leave
p=alone until aligned volume is the majority of the stream. - Spot-check the same From in ArawaMail tools and in a receiver that shows Authentication-Results. Do not trust a vendor dashboard that only prints “SPF pass.”
The domain you put on the From line is the product receivers score. That is the same thesis as Your domain is the product — alignment is how that product proves it sent the message.
How we analyzed this
This is a troubleshooting article, not a protocol textbook. Alignment rules follow RFC 7489 identifier alignment and the unchanged alignment test in RFC 9989. Receiver consequences cite Gmail bulk-sender alignment (including 550-5.7.26) and observed Microsoft consumer 550 5.7.515 behavior when 5322.From fails the required authentication level. ArawaMail behavior is limited to public docs: sending requires receiving; enable sending writes DKIM CNAMEs and a custom MAIL FROM with MAIL FROM MX and SPF; the API from domain must be a company domain with outbound sending active; API keys may be unrestricted or locked to one domain; ArawaMail does not publish _dmarc. Exact MAIL FROM hostnames and DKIM selectors are omitted because they are not in public docs.
Related guides
SPF, DKIM, and DMARC explained · How to read a DMARC report · From, Reply-To, and Return-Path · Two vendors, one From address · Authentication on subdomains · BIMI explained · Free email tools
FAQ
Why can SPF pass while DMARC fails?
SPF authenticated the MAIL FROM domain. DMARC compared that domain to the visible From. If those organizational domains do not match (relaxed) or the names are not identical (strict), DMARC fails.
Is relaxed alignment enough for Gmail bulk rules?
Usually yes, if the authenticated organizational domain matches the From organizational domain. A pass on amazonses.com while From is example.com is not relaxed alignment. It is a different organization.
Does ArawaMail custom MAIL FROM make SPF align with From?
It can, when the custom MAIL FROM is a subdomain of the From organizational domain and aspf is relaxed (the default). Confirm the live MAIL FROM name in the product. ArawaMail still does not write your _dmarc record.
When do I need strict alignment?
When a child name must not count as the parent. Strict is a brand-control setting (aspf=s / adkim=s), not a Gmail checkbox.
Where do I look in Authentication-Results?spf= and its MAIL FROM, dkim= and header.d, dmarc= and header.from. If pass and fail disagree, alignment is the missing column.
Can I send From a domain I have not added to ArawaMail?
No. The API rejects a From domain that is not registered to the company, not allowed by the key, or not sending-enabled. That rejection is better than an unaligned send.