Our strategy, ensure there is a "@" and some text before and after the "@". We require email validation (click a link in an email) so if they enter in a bad email we catch it on the validation part anyhow.
Basically the same as yours, but validate that a TLD exists.
Technically, this would fail on a few valid email addresses: foo@localhost, foo@.co, or foo@2001:0db8:85a3:0000:0000:8a2e:0370:7334
All those are valid, but we decided that none of those would apply to any of our customers.
Any validation pattern that caters for the user should be trying to catch instances where the user has entered their address incorrectly. That means validating things like the general pattern ('does it have a @'), checking the TLD ('is the TLD part of the domain in this huge array'), and catching weird characters ('did the user really mean to use a ®'). Even if the validation fails the user should be able to submit their address (this is client side after all; the user can just disable it), but they should be informed that it appears there could be a reason to double check it first.