It's not like impersonation is dead. When I signed up for the Gmail roll-out, [email protected] was reserved, but you can email me at [email protected] - 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 [email protected], 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...
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: [email protected] 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.