Your mail is not SPF-aligned

SPF checks the envelope sender — the address a receiving server bounces to, which your reader never sees. SPF is aligned when that envelope domain matches your From: domain. A platform that sends on your behalf normally bounces to its own domain, so SPF passes and does not align.

Whether this is worth fixing

If DKIM is already aligned for this source, you can leave it. DMARC needs one aligned mechanism, and DKIM is the better one to have — it survives forwarding, and SPF does not. Sojka counts a source as green on DKIM alignment alone, deliberately.

It is worth fixing when neither leg aligns, or when this platform cannot sign as your domain at all. Then SPF alignment is the only route to a DMARC pass and the mail is failing until you get it.

How to align SPF

You cannot do it in your SPF record. Adding the platform to v=spf1 makes SPF pass; it does nothing about alignment, because alignment is decided by the envelope domain the platform uses, not by who is authorised. The change has to happen on the platform.

Look for custom return-path, custom MAIL FROM, custom bounce domain or dedicated sending subdomain in the platform's settings. Different vendors, same feature.
You will be asked to publish records for a subdomain of yours — typically an MX and an SPF TXT at something like bounce.yourdomain or mail.yourdomain.
Once the platform bounces to that subdomain, SPF aligns under relaxed alignment (aspf=r, the default). It will not align if your DMARC record sets aspf=s, which demands an exact match — that combination is worth a second look before you start.

Some platforms simply do not offer it. That is a real answer, and it is why DKIM is where the effort belongs.

While you are in the SPF record

Ten lookups is a hard ceiling. Every include:, a, mx, ptr and exists: spends one, and includes nest. Past ten, SPF returns permerror and stops evaluating — the record fails whole, not partly.
End with ~all or -all. +all authorises the entire internet and ?all asserts nothing.
One SPF record per name. Two v=spf1 TXT records is a permanent error, not a merge — combine them into one.