Rejected: SPF (SPF check failed)

SPF is a very weak defense.  Most spammers have it configured correctly and many legitimate senders have mistakes.  SPF only matches the internal authorized-as information to the source IP address, and that internal identifier is often unrelated to the "From" information seen by the user.

If UTM would allow simulation of the impact, it might be useful., but at present I find it useless.

Are you sure about that?

You have to know my dns-server account to change my domain SPF. Or the spammers have to manipulate the UTM spf check, because it is not provided in the email headers or body.

Any mailer can put anybody's information in the "From" line seen by the user, which is what matters for social engineering attacks.   SPF is not intended to check what the user sees.  The SPF check is done during the HELO before the user-visible From is even transmitted.

I think DKIM can be used to validate either the From or the Authorized-As, and DMARC can be used to say that DKIM information must be present, but I do not think it can state that the From is always verifiable. UTM does not seem to support DMARC, nor does my other spam filter, so I may be mistaken.

Most large companies use third parties for promotional mailing under their name.   Big web platforms like Salesforce also mail under tbe identity of their clients.  These contracts are often established without involvement of the corporate mail team, which is why the SPF informaion is often wrong.

My attempts to evaluate SPF effectiveness have led me to conclude that the incremental volume of blocked spam is trivial, and less than the number of false positives.   Because UTM only provides a block option for SPF, it is impossible to evaluate blocked messages to discern if they are legitimate or spam.

That, at least, has been my experience.

Any mailer can put anybody's information in the "From" line seen by the user, which is what matters for social engineering attacks.   SPF is not intended to check what the user sees.  The SPF check is done during the HELO before the user-visible From is even transmitted.

I think DKIM can be used to validate either the From or the Authorized-As, and DMARC can be used to say that DKIM information must be present, but I do not think it can state that the From is always verifiable. UTM does not seem to support DMARC, nor does my other spam filter, so I may be mistaken.

Most large companies use third parties for promotional mailing under their name.   Big web platforms like Salesforce also mail under tbe identity of their clients.  These contracts are often established without involvement of the corporate mail team, which is why the SPF informaion is often wrong.

My attempts to evaluate SPF effectiveness have led me to conclude that the incremental volume of blocked spam is trivial, and less than the number of false positives.   Because UTM only provides a block option for SPF, it is impossible to evaluate blocked messages to discern if they are legitimate or spam.

That, at least, has been my experience.

You are wrong. SPF Check has nothing to do with the email transmission or email data. Most domain owners authorize only one or multiple ips to send emails in behalf to their emails. And other owners dont put spf record on their mx records. UTM scans for SPF records after the email is received.

If the owner didn't put a spf record the email will pass. If there is a SPF record but the IP is not there, the email is considered as spam.

To be clear, the owner of the domain who sends the email in this way protects his domain reputation

For anyone interested in digging further, this is the current RFC for SPF

https://tools.ietf.org/html/rfc7208