DKIM, SPF, DMARC is all pretty simple, though. I’m running my own mail server with all those properly configured, and it wasn’t much work.
But good look getting through to postmaster@gmail|outlook etc.
But they'll hold you to some arbitrary standard that's supposed to mean "less spam" when they should have more than enough traffic to get by with statistical/ml methods anyway... /rant
DKIM+SPF+DMARC means you can prevent anyone else from impersonating your domain.
Every MTA will reject mails that violate the DMARC policy you specify in your DNS, if you have any.
All the old From: support@paypal.com scams are gone, impossible.
This means spammers either have to use hacked servers, or their real From: address.
And as soon as they have to use their real From: address, it becomes trivial to block spam.
Blocking spam is only so hard because From: was basically meaningless until now.
It's not like impersonation is dead. When I signed up for the Gmail roll-out, security@gmail.com was reserved, but you can email me at sikkerhetsansvarlig@gmail.com - a poor Norwegian translation equivalent. More importantly, I can email you from that address, and tell you there's a problem with your account, could you please verify that your password is "hunter2", if not email your current password so we can verify that your account is secure (not that I ever have, or will, I got the account for a laugh).
Federated trust (s/mime) or Web of trust/direct trust(gpg) secures email. All this domain pseudo secure dns nonsense... I'm not sure I accept it's better than static analysis.
If I get email from alice@example.tld, then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld.
The important part in this is spam prevention, and that if I get an email from @paypal.com, knowing that it's real.
What you're complaining about is another question, but not really relevant. Google always uses @google.com for employees, and if you get an email from that, it's real.
This is about enforcing identification, not verification, security, trust, or anything else.
Is this better than graylist+whitelist? Is it better than content based filtering? I'm not convinced.
Is it better than requiring tls with valid cert for smtp? I can't see how.
Rather than all this mess, I think I'd prefer we start at tls/ssl required for smtp...
With SPF, DKIM, DMARC correctly set up, correct IPv4 and IPv6 reverse DNS, only A or AAAA or NS or GLUE records used in the entire resolution path, correct from and reply-to addresses, you should usually be good to go, though.