An SPF pass can be completely correct while doing nothing to authenticate the address your customer sees. The sending server may be authorised for a vendor's envelope domain while the visible From uses your business domain. DMARC asks whether a passing authentication identity aligns with that author domain.
This is an identity problem, not necessarily a missing-IP problem. Start with the domains in the actual received message before extending SPF permissions.
Compare three separate observations
Record the visible From domain, the domain SPF evaluated, and the domain in each passing DKIM signature's d= field. Record the receiver's result for each mechanism separately. Do not infer alignment from a green SPF or DKIM badge that hides the domain it evaluated.
RFC 9989 section 4.4.2 defines SPF alignment. Strict alignment requires the SPF and author domains to match exactly under RFC 9989 §3.2.10.2. Relaxed alignment uses the organisational-domain discovery in RFC 9989 §4.10.2. It does not allow any domain owned by a vendor with which you have a contract.
Worked example: a correct pass with no alignment
The following is a synthetic diagnostic fixture assuming an applicable DMARC policy. A message displays From: accounts@example.com. Its MAIL FROM is delivery@vendor.example.net. The connecting IP is 192.0.2.17. The vendor envelope policy is v=spf1 ip4:192.0.2.17 -all, so SPF passes.
Assume the organisational domains are example.com and example.net. They differ, so the SPF path does not align in relaxed or strict mode. If DKIM also passes only with d=vendor.example.net, neither passing identity aligns. DMARC therefore lacks a passing aligned path under RFC 9989 §5.3.5. Adding that IP to example.com's SPF record does not change the fact that this transaction used vendor.example.net.
Now consider a supported custom envelope of return@bounce.example.com. If SPF passes for bounce.example.com and both it and example.com have the same discovered organisational domain, relaxed SPF alignment can pass. Strict alignment still does not because the names differ. Alternatively, a passing DKIM signature with d=example.com can supply an aligned DKIM path.
Choose a supported correction
Ask the service documentation or administrator whether it supports a custom MAIL FROM domain, aligned DKIM, or both. Obtain the exact generated DNS values from the service. A generic SPF include does not configure a custom envelope by itself, and manually fabricating the provider's return address can disrupt bounce handling.
Choose the correction that fits the workflow and your policy. An aligned DKIM deployment often provides useful resilience through forwarding, although changes to covered content can break signatures under RFC 6376 §3.7. If you use custom MAIL FROM, test the actual envelope after the provider reports setup complete. Product availability and configuration steps must be verified for the product and account in use.
Do not relax alignment just to remove a warning without understanding the boundary it creates. Conversely, do not select strict alignment as a badge of security if legitimate subdomain senders were intentionally designed for relaxed alignment. Document why the chosen identity relationship is acceptable.
Retest the path, not just DNS
Send a representative message to a mailbox where you can inspect trusted receiver results. Test the notification type that failed, since a provider's marketing and transactional products may use different identities. Capture the new envelope, SPF result, DKIM signing domain and DMARC result.
If direct mail works but forwarded mail does not, investigate that route separately. Do not call a DNS correction unsuccessful merely because an unrelated content filter still places the message in spam. Authentication results and mailbox placement are distinct outcomes.
The practical takeaway
A useful diagnosis names the passing domain and shows why it does or does not align. Repair the supported sending identity, then verify a real message. Broader SPF permissions on the wrong domain cannot close an alignment gap.
Keep the decision reproducible
Use one row per passing identity and its alignment mode. With only vendor.example.net passing for From=example.com, mark both raw passes as unaligned rather than joining one result to another domain. If d=example.com also verifies, record that separate aligned DKIM path. Test custom MAIL FROM behavior independently even if overall DMARC already passes.