How to configure HexValidEmail

Because the HexValidEmail component checks email addresses by actually stepping through the process of sending email, you must treat the machine that runs HexValidEmail as if it were a mail server to get the best results. Various anti-spam systems have made this more complicated than in the past, and you may need the cooperation of your network administrator.

If you do not follow the instructions below, your validations may still work in many cases. Sometimes, however, you will get false rejections of good email addresses or just "Could not verify recipient" errors. These errors may escape your notice for a while and cause problems for your own users, so setting up your machine correctly from the start is important. If you do encounter such problems, check the Error property and SmtpSession property (or Manifest.LastErrorCode and Manifest.SmtpSession in the .NET version) after the failed validations to get more information about what went wrong.

  1. Verify that your firewall allows outgoing SMTP connections to TCP port 25. When doing SMTP validation, the HexValidEmail component has to talk directly to destination mail servers to verify that they recognize the email addresses under test. Relaying through a local mail server will not work for this purpose. If a firewall blocks your SMTP traffic, all your validations that reach the SMTP stage will time out. Note: Many residential ISPs and some web hosts block outgoing port 25 traffic as an anti-spam measure, so you will not be able to do SMTP validation from their networks unless you arrange for an exception.
  2. Make sure that your local DNS servers can resolve external domains. This is almost always the case, but sometimes DNS servers on a private company network will not return A or MX records for public domains. You can quickly test your DNS servers by entering the following on a command line: nslookup -type=mx hexillion.com. This should yield at least one MX record for the hexillion.com domain. If your DNS servers are not properly configured, all your validations may time out or indicate that the email address domains do not exist.
  3. Make sure that your IP address has a reverse DNS mapping (PTR record). Many mail servers, as an anti-spam measure, will refuse to talk to a system with an IP address that does not resolve to a domain name. Furthermore, that domain name should resolve back to the IP address. You can check your reverse mapping with our Domain Dossier utility. Set HexValidEmail's FromDomain property (or the heloDomain parameter in the .NET version) to the domain a remote mail server will see.
  4. Include "mail", "smtp", "relay", or "mx" in the domain name for your machine. (For example: mail.example.com, smtp.example.com, or mx1.example.com.) Some mail servers, notably those serving domains hosted at GoDaddy, will expect domain names that look like mail server names.
  5. Set the FromEmail property (or the fromAddress parameter in the .NET version) to a working address of the person responsible for email address validation or to a blank string (or to null in .NET).
  6. Check the SPF records for both the FromDomain and FromEmail domain (if different) to make sure that they designate your machine's IP address as a valid sender. Not all domains have SPF records, and you can skip this step if your domains don't. You can look for SPF records using our Domain Dossier utility. They are often embedded in TXT records.
  7. Search for your IP address in blacklists. If your machine's IP address is listed in one of the many DNS blacklists, your SMTP validations will be rejected on some systems. Not only will this reduce the efficacy of your validations, but it may also lead to incorrect rejections of email addresses in some cases because of ambiguous SMTP error codes.
  8. Do not use a residential or dynamic IP address. Some mail servers routinely block mail from residential and dynamically-assigned IP address pools on the assumption that they are more likely to be sources of spam than legitimate email. Thus, for best results, your machine should use an IP address from a range assigned to businesses—web hosting companies or your own company, for example.
  9. Don't use the VRFY and EXPN option. It is off by default, and you should leave it off. It is included only for rare (and now almost completely obsolete) diagnostic purposes and will sometimes cause SMTP validation failures.
Show site map

contact us    privacy policy    legal information