One challenge with phishing is that virtually all the "best practice" pieces written by the press still follow this Atlantic article's "blame the user" approach to phishing prevention. I.e., train your end users to not click on stuff in bad emails.
Unfortunately, what we've seen over the last year or so is exactly what you'd expect: now that many companies are running simulated phishing training campaigns -- sending fake phishing emails to end users to try to train them to not click on "bad links" -- attackers are now sending brand forgery emails that are essentially perfect looking. The key insight here is that the attacker actually has a labor-saving technique that is also completely devastating to the approach of training users: "Save As HTML".
It's obvious in retrospect, but all the attacker has to do is take the exact HTML from a real transactional email (say, a DocuSign request), edit it to change one link, and resend it. (In security parlance this is a kind of "replay attack".) By definition, the body of this email will look identical to the original transactional mail, so you're left with training users to see the invisible. The hapless end user logs in "to DocuSign" and thereby gives the attacker his/her credentials.
In contrast, a machine learning system that is trained to recognize brand-indicative clues from emails can trivially verify DKIM, etc. on the mail to determine whether the mail really is from DocuSign or not. (It's actually not really trivial, because DocuSign might send mail through MailChimp or some random domain they never told you about, but that's a detail...) Software 1, Humans 0.
This leads me to personally believe that while phishing awareness training is important and a good practice, the future must be one where the machines do the vast majority of phishing email identification, blocking these emails before they reach end users. And it's a hard problem.
Of course, attackers can't precisely control the headers -- e.g., they can't easily send DKIM-signed mail from a domain named docusign.com -- so they can't literally replay a real DocuSign mail. But here again they use lots of clever tricks. One of my favorite (i.e., most evil) real-world phishing emails was a clone of an American Express "confirm card activity" email sent from domain aexp-ib.com. Most recipients would plausibly believe that that domain was some kind of internal Amex mail server or something, so it doesn't look at all weird. Even more devastatingly, this email came DKIM-signed -- with SPF and DMARC "alignment" -- by a very high reputation sender (Google), so it sailed right through mail protection systems based around traditional "good mail / bad mail" signals.
Why was it signed by Google? Because the attacker set up a G Suite account and sent the emails from there. This is another challenging phenomenon we're seeing: it's trivial for attackers to "inherit" the good reputation of a shared service like G Suite in this manner. Similarly, instead of hosting phishing sites on sketchy-looking URLs that can be detected with simple Bayesian models (good vs bad URL detection), attackers now host their stuff on Google Sites and on compromised web sites with high Alexa rankings. You can use simple heuristics like "don't trust mail from a domain set up in the last 3 days" but that's problematic too, because attackers can simply bank domains. (And, for that matter, real senders create new domains and send legitimate mail from them.)
According to the FBI, email-based phishing attacks have cost companies over $12B since 2013. If there's any silver lining to this scourge, it's that it makes for a really interesting technical challenge for the white hats that pretty much everyone understands the need for. (A completely different set of techniques is required to block impersonations of people -- "spear phishing" -- but I'll leave that for another day.)