To answer you question:
DMARC is designed not only to make sure spoofers are unable to use your domain in an unauthorized way, but also allow authorized senders to show that they are legit.
SPF can fail even on legitimate emails because of a number of reasons. The most common being forwarding.
The DMARC report contains several sections for each record.
One is the
<policy_evaluated>, which tells you how well the sender authenticated in alignment with your domain, used in the
Then there is the section
<auth_results>, which will include an
<spf> section as well and possibly a
<dkim> section. Here the SPF result may even be pass while the policy evaluated result for SPF may fail, meaning the sender successfully authenticated the domain used in the bounce /
envelope_from address, which can be different from the
header_from address which the recipient is shown in the email client.
A common scenario in which you'll see failed SPF authentication (in both policy_evaluated and auth_results) on legit emails, is forwarding. If the bounce / envelope from address is not rewritten while forwarding, the forwarding server's IP address will likely not be present in your SPF record.
In this case DKIM is a more resilient authentication mechanism. It survives forwarding as long as the signed header fields are left untouched.
Here is an example aggregate report where
fwd.me forwarded an email from
example.com while rewriting the bounce address to their domain, on which consequently the SPF check passed, because the sending IP
126.96.36.199 was included in the SPF record for
fwd.me. The bounce /
envelope_from domain is not aligned with the
header_from domain and so it fails the DMARC check for SPF.
Because the original DKIM signing survived the forwarding, the email was not rejected.