Let’s first see what SPF does and what it does not:
SPF authenticates the sending server of the email based on the sending IPv4/IPv6 address. SPF focuses on a header that is not visible to the end-user (Return-Path, MAIL FROM, Envelope-From, Bounce address, HELO/EHLO). SPF authenticates your email so that when an attacker tries to send fake email behalf of your domain, the receiving email server sees that it’s from a malicious source, and flags it. It boosts your domain reputation.
SPF does not require any alignment between the end-user’s visible domain and the typically invisible Return-Path that it checks. SPF does not provide any reporting functionality for the receiver to send back to the sender with the results of the email authentication. SPF does not survive forwarding and indirect mail-flows. SPF does not tell the receiving server what it should do with an email that failed SPF. For example, senders can publish “-all” but this has never been honored by receivers, as SPF breaks easily, and this would cause legitimate emails to be rejected. SPF specification has a limit on the number of DNS lookups (10) required to fully resolve an SPF record. SPF records have a 255 character string limit in Domain Name System (DNS). If you have an SPF record with a string longer than 255 characters, it will fail the SPF authentication check.