Presence of an MX record should _not_ be used as a litmus test for a valid email domain.<p>RFC 5321 section 5 specifies that you lookup the MX and, if absent, use the A/AAAA record. I'm simplifying a bit, but that's the gist of it.<p>Using just the A record is more common than you might expect.<p>[1]: <a href="https://tools.ietf.org/html/rfc5321#section-5" rel="nofollow">https://tools.ietf.org/html/rfc5321#section-5</a>
The first line mentions:<p>> Validates email looks like an email i.e. contains an "@" and a "." to the right of it.<p>But what about emails coming from a hostname without a dot, or a TLD without a subdomain?<p>Even the HTML email field supports emails without a dot after the @ because it's technically valid.
For most applications email validation is really not nesecarry. instead a service can rely on email verification. If the address is invalid, mails sent to it will never arrive at a destination.
Hopefully this doesn't get used in some kind of registration flow in full since for example if you register with an aliased address, or you have a catchall address or email is just proxied the SMTP checks would fail.
There is exactly one right way to validate an email: send a message to it.<p>Email is a very old protocol with a lot of hacks and backwards compatibility. At this point, pretty much any string <i>could</i> be a valid email address. You can certainly run a bunch of tests and get a decent signal, but it's a lot of work, and if you reject an email address without testing it you're going to cause someone some trouble at some point. It's a lot easier and more accurate to just accept the string and try to send email to it.
Interesting, I wrote a similar tool some time ago, in Rust: [link redacted]<p>I'm using a similar technique to check deliverability, i.e. parsing SMTP responses.