spf=pass

spf=pass means the receiving server looked up the SPF record for the domain in the envelope sender (the bounce address, shown as smtp.mailfrom) and found the IP address that connected to it on the list. It answers one narrow question: was this machine allowed to send mail using that bounce domain? It does not look at the From address your mail app displays.

What the RFC says

RFC 7208 §2.6.3 defines pass as an explicit statement that the client is authorized to use the checked identity. §8.3 adds that the domain can then be held responsible for the message for reputation purposes. The checked identity is normally the MAIL FROM domain (§2.4); when the envelope sender is empty, as with bounces, it is built from the HELO name instead. RFC 8601 §2.7.2 maps the spf method in Authentication-Results onto these definitions and records the identity as smtp.mailfrom or smtp.helo.

Return-Path: <bounce-7731@bounces.mailer.example.net>
From: "Example Shop" <orders@example.com>
Authentication-Results: mx.example.org;
       spf=pass (sender IP is 198.51.100.24) smtp.mailfrom=bounces.mailer.example.net;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Which domain passed?

Read the smtp.mailfrom value before anything else. In the snippet above, SPF passed for mailer.example.net, an email service, not for example.com. That is normal for newsletters and receipts, and it is also why SPF on its own proves little: anyone can register a throwaway domain, publish an SPF record for their own server and get a clean pass while writing any name they like in From. RFC 7208 §11.2 makes the same point: an SPF pass does not vouch for the other identities in the message.

DMARC closes that gap with alignment. An SPF pass only counts toward DMARC when the smtp.mailfrom domain matches the From domain, or shares its organizational domain in relaxed mode (RFC 9989 §4.4.2 and §3.2.10.1). The analyser shows that alignment check beside the SPF badge. It works out organizational domains from the Public Suffix List, which closely approximates the DNS-based method the current DMARC standard uses.

If you received this message

Treat it as one piece of evidence. If the bounce domain and the From domain line up and the message also shows dmarc=pass, the sender's domain checks out. If they differ, read the DKIM and DMARC results instead. A pass for a domain that looks almost like a real brand is a common phishing pattern; see lookalike domains.

If you own the sending domain

The SPF record itself is fine. Check alignment next. If your email provider uses its own bounce domain, set up a custom return-path (providers call it "custom MAIL FROM", "bounce domain" or "return-path domain") on a subdomain of yours, so the pass lines up with your From address. Sign with DKIM using your own domain as well, because SPF usually breaks when mail is forwarded. The Return-Path guide explains how the two addresses relate.