You forget that the Internet is not a place filled with nice people. It is a dark alley where nice people go at their own risk, often to their peril. If your spam filtering is doing its job, more than half of your email gets blocked. That means that if you blocked all traffic, you would be right more often than not!
The worst possible scenario is to accept a fraudulent message identifier as legitimate, and then exempt the attack from all content filtering because it has been falsely labeled as "trusted sender". Fraudulent email does not carry a warning label, so the only way to protect yourself from this scenario is to require that whitelisted senders are verified. Unfortunately, we do not have a standards-based technique for obtaining a verification result on every message.
IETF has defined two ways to validate two different parts of the email message:
SPF verifies the SMTP Sender (a.k.a. Mail From) address [RFC 5321]. Some senders don't have an SPF policy at al. Others have configuration mistakes, so that messages don't produce PASS even when they would if configured correctly. SPF does not have a feedback mechanism, so the errors tend to go unresolved because they are never reported. If forwarding has happened, SPF because either useless (Mail From is rewritten to match forwarder domain) or misleading (SPF fails if Mail From is not rewritten).
We don't have a very good way to identify forwarded messages, and the one tool that we do have (ARC) is wholly depending on the forwarder providing correct information, and non-forwarders not supplying data that will by definition be misleading.
DMARC verifies the Message's "From" header [RFC 5322] using either aligned SPF PASS or aligned DKIM PASS. Alignment can be "strict" (exact domain match) or "relaxed' (same organization). Alignment is determined by the DMARC policy, which is part of the reason that DMARC is only defined when a policy is present. One could note that exact match on SPF or DKIM does not depend on the existence of a DMARC policy. I have made that observation but it will not be in the next revision of the DMARC specification, because IETF is only interested in protecting the receiver if the sending domain owner wants to provide this protection. On the upside, DMARC policies are difficult to get completely wrong, so if they exist they should be usable. However, some domain owners publish p=reject when their messages don't have DKIM signatures. if the message is forwarded, the message fails authentication and is labeled as a fraud. If a message is forwarded with changes (common action by mailing lists and some spam filters), any DKIM signatures are invalidated, so the result is again FAIL. Also, a lot of messages do not have DMARC policies.
Mail From and From addresses are often different At lot of mail, my guess is about 50%, is sent by Email Service Providers (ESP) who specialize in delivery of messages in high volume and messages generated by web sites or other automation. The ESP domain is used for the SMTP Mail From address, and the client address is used for the message From address. There are other reasons as well. This is not fraud, this is just the way people need email to work.
Overall, both SPF and DMARC return results of "PASS=verified", "FAIL=repudiated", "Uncertain", and "No policy". Uncertain and No Policy are all too common, and false FAIL will also occur.
In the example you provided, it appears that the message was going to Junk because the message was producing FAIL. So making it a trusted sender does not solve the problem because the sender has an inherent trust problem.
In my environment, I have defined a custom exception structure so that I can configure alternate authentication for any wanted message that cannot produce PASS. It has required a lot of data collection and a lot of message review. But along the way I have detected and blocked a lot of malicious and unwanted senders, not merely impersonators, so I feel like the effort has been well worth it. But this goes way beyond what you can expect to get for free from a vendor whose primary business is mail handling, not spam filtering. I don't think you can even buy it. But you could build it.
Doug Foster