5 ms·

In addition to a very simple regex, you can do some light verification on DNS and SMTP - nslookup –type=mx email.com - pick the highest priority MX server -

In addition to a very simple regex, you can do some light verification on DNS and SMTP - nslookup –type=mx email.com - pick the highest priority MX server - telnet mx1.email.com 25 - validate SMTP handshake - Start a connection: EHLO email.com - mail from:<sender@youremail.com> - rcpt to:<recipient@email.com> Obviously, this might be outside the capabilities of some hosts or users. There's a bunch of services that expose this workflow for you as an api. (https://trumail.io/ https://trumail.io/, for example)

teh_klev 5y ago
See point 10 in the article: "The domain name does not need to resolve" Also the mail server may be temporarily offline or unreachable.
- deleted 5y ago
  [deleted]
- jusssi 5y ago
  Non-resolving or offline mail servers count to your bounce rate if you have a 3rd party service handling your outgoing mail. So for that purpose, it is an invalid address in the sense that you should avoid sending anything to it.
  - teh_klev 5y ago
    Those are rules made up for the convenience of marketers and have nothing to do with the technical aspects of mail delivery as defined in the RFCs. Edit just to clarify: KPI's such as bounce rates etc aren't a function of how mail is delivered (RFC5321). These are KPI's collected and collated by non-SMTP applications sitting on top of SMTP infrastructure monitoring bounces. Nowhere in RFC5321 does it mention that a mail server should or must not delivery mail in respect of bounce rates. These are operator defined metrics outside of the scope of RFC5321, that may be aided by additional software or services such as spam detection.
    - johncolanduoni 5y ago
      On the contrary, those kind of rules are made up to try and keep marketers in check to some degree. Why would a marketer want to get dinged for sending an email to a nonresponsive domain?
      - teh_klev 5y ago
        You're going to need to quote the RFC(s) that specifically mention bounce tracking to keep marketers in check. My original reply arose because there are times when a receiving domain or destination email address can be "temporarily" unavailable. I pointed this out to demonstrate that services that pre-validate recipient addresses upon submission of a form don't take into account transient outages due to any number of valid factors. SMTP was designed with this in mind, i.e. try to re-deliver up to some acceptable threshold and then at some point give up (the hard bounce which is the thing that should cause the "ding", especially if they keep retrying beyond "soft bounces").
        johncolanduoni 5y ago
        You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Or maybe give up on every practical aspect of a technology defined in RFC(s) being covered by those RFC(s). SMTP seems a particularly bad example if you expect to be able to write a useful program using only the RFC(s), since every MTA has a whole host of workarounds for non-spec behavior.
        teh_klev 5y ago
        > You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Perhaps re-read "jusssi"'s comment then mine. I didn't assert that bounce tracking was for the convenience of marketers, or suggest it was mentioned in any way in the RFC's, they implicitly did and I wanted to point out the error in their understanding. > SMTP seems a particularly bad example if you...etc But the central theme of this whole HN discussion thread is about SMTP. If you're interested, sections 6 of RFC5321[0] are where bounce messages are mentioned (just three times in the whole RFC - bouncing, bounced and bounce) with no reference to marketers. See also 6.1: Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system. Which brings us back to my original comment, far above, that services that check once if an email address is "valid" using trumail.io or whatever when upon form filling are flawed solutions. [0]: https://datatracker.ietf.org/doc/html/rfc5321 https://datatracker.ietf.org/doc/html/rfc5321
  - iggldiggl 5y ago
    Amazon supposedly distinguishes between soft and hard bounces, and only hard bounces count towards your failure rate for which you eventually might be penalised: https://github.com/awsdocs/amazon-ses-developer-guide/blob/ec08804/doc-source/sending-concepts-deliverability.md https://github.com/awsdocs/amazon-ses-developer-guide/blob/e... Although annoyingly in the case of a soft bounce they apparently only retry for up 12 hours, which for a small mail server is very much on the too short side: In the worst case my mail server/hoster goes down just as I go to sleep, in the morning I either don't notice it or can't do anything about it anyway as I need to go to work, at work I can't do anything about it either, and it's only when I get back home that I can stand up my emergency mail server if the outage hasn't resolved itself by that time, which means > 20 h of down time and therefore far exceeding Amazon's retry window. (The RFC5321 recommendation is to keep retrying for 4 to 5 days, which is much more amenable for that case)
- icedchai 5y ago
  Ok, so the article is wrong. For an email to be valid right now, yes, the domain part has to resolve. If you're accepting any email address that might be an email in the future, then they are correct, but for 99.9% of use cases: yes, the domain has to resolve.
jeffbee 5y ago
Close but you also need to fallback to AAAA or A lookup of the domain when the MX record doesn't exist. Also, do you really want transient unavailability to stop your signup flow? The whole point of the way mailers are written is the mail gets delivered even in the face of transient unavailability.

teh_klev 5y ago

See point 10 in the article: "The domain name does not need to resolve" Also the mail server may be temporarily offline or unreachable.

deleted 5y ago
[deleted]
jusssi 5y ago
Non-resolving or offline mail servers count to your bounce rate if you have a 3rd party service handling your outgoing mail. So for that purpose, it is an invalid address in the sense that you should avoid sending anything to it.
- teh_klev 5y ago
  Those are rules made up for the convenience of marketers and have nothing to do with the technical aspects of mail delivery as defined in the RFCs. Edit just to clarify: KPI's such as bounce rates etc aren't a function of how mail is delivered (RFC5321). These are KPI's collected and collated by non-SMTP applications sitting on top of SMTP infrastructure monitoring bounces. Nowhere in RFC5321 does it mention that a mail server should or must not delivery mail in respect of bounce rates. These are operator defined metrics outside of the scope of RFC5321, that may be aided by additional software or services such as spam detection.
  - johncolanduoni 5y ago
    On the contrary, those kind of rules are made up to try and keep marketers in check to some degree. Why would a marketer want to get dinged for sending an email to a nonresponsive domain?
    - teh_klev 5y ago
      You're going to need to quote the RFC(s) that specifically mention bounce tracking to keep marketers in check. My original reply arose because there are times when a receiving domain or destination email address can be "temporarily" unavailable. I pointed this out to demonstrate that services that pre-validate recipient addresses upon submission of a form don't take into account transient outages due to any number of valid factors. SMTP was designed with this in mind, i.e. try to re-deliver up to some acceptable threshold and then at some point give up (the hard bounce which is the thing that should cause the "ding", especially if they keep retrying beyond "soft bounces").
      - johncolanduoni 5y ago
        You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Or maybe give up on every practical aspect of a technology defined in RFC(s) being covered by those RFC(s). SMTP seems a particularly bad example if you expect to be able to write a useful program using only the RFC(s), since every MTA has a whole host of workarounds for non-spec behavior.
        teh_klev 5y ago
        > You’re going to need to show me the RFC(s) that specifically mention bounce tracking is for the convenience of marketers. Perhaps re-read "jusssi"'s comment then mine. I didn't assert that bounce tracking was for the convenience of marketers, or suggest it was mentioned in any way in the RFC's, they implicitly did and I wanted to point out the error in their understanding. > SMTP seems a particularly bad example if you...etc But the central theme of this whole HN discussion thread is about SMTP. If you're interested, sections 6 of RFC5321[0] are where bounce messages are mentioned (just three times in the whole RFC - bouncing, bounced and bounce) with no reference to marketers. See also 6.1: Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system. Which brings us back to my original comment, far above, that services that check once if an email address is "valid" using trumail.io or whatever when upon form filling are flawed solutions. [0]: https://datatracker.ietf.org/doc/html/rfc5321 https://datatracker.ietf.org/doc/html/rfc5321
- iggldiggl 5y ago
  Amazon supposedly distinguishes between soft and hard bounces, and only hard bounces count towards your failure rate for which you eventually might be penalised: https://github.com/awsdocs/amazon-ses-developer-guide/blob/ec08804/doc-source/sending-concepts-deliverability.md https://github.com/awsdocs/amazon-ses-developer-guide/blob/e... Although annoyingly in the case of a soft bounce they apparently only retry for up 12 hours, which for a small mail server is very much on the too short side: In the worst case my mail server/hoster goes down just as I go to sleep, in the morning I either don't notice it or can't do anything about it anyway as I need to go to work, at work I can't do anything about it either, and it's only when I get back home that I can stand up my emergency mail server if the outage hasn't resolved itself by that time, which means > 20 h of down time and therefore far exceeding Amazon's retry window. (The RFC5321 recommendation is to keep retrying for 4 to 5 days, which is much more amenable for that case)
icedchai 5y ago
Ok, so the article is wrong. For an email to be valid right now, yes, the domain part has to resolve. If you're accepting any email address that might be an email in the future, then they are correct, but for 99.9% of use cases: yes, the domain has to resolve.

jeffbee 5y ago

Close but you also need to fallback to AAAA or A lookup of the domain when the MX record doesn't exist. Also, do you really want transient unavailability to stop your signup flow? The whole point of the way mailers are written is the mail gets delivered even in the face of transient unavailability.