Troubleshoot Most Common Cause of Delivery Failures on Email Bulk Merges

Basic things to check what's causing the delivery failure:

     1. Check if  domain and email address of the recipient is valid. Check if the actual email domain is valid by visiting the domain or going to MXToolBox.com the use command whois:[DOMAIN to check].com.

     If the Domain is valid, there some ways where you can check if the email is valid by:

          a. Using Telnet, here are the corresponding commands and responses:

COMMAND:

   telnet mail.DOMAINtoBeCHECKED.com 25

RESPONSE:

   220 mail.DOMAINtoBeCHECKED.com ESMTP Postfix NO UCE NO UEMA  C=US L=CA

COMMAND:

   helo hi

RESPONSE:

   250 mail.DOMAINtoBeCHECKED.com

COMMAND:

   mail from: yourOWNremail@yourOWNdomain.com

RESPONSE:

   250 2.1.0 Ok

COMMAND:

   rcpt to: INVALIDemail@mail.DOMAINtoBeCHECKED.com

RESPONSE:

   550 5.1.1 <INVALIDemail@mail.DOMAINtoBeCHECKED.com>: Recipient address rejected: User unknown in local recipient table

COMMAND:

   quit

RESPONSE:

   221 2.0.0 Bye

              
     At this point, a response of 550 will indicate that the email is a bad address on this domain.

          b. Using a web tool to verify:

          Click here to verify the validity of an email address which uses essentially the same method described above but only done automatically.


     2. Proceed to check if either NetSuite or the Company is blacklisted. The reason for checking if both NetSuite and user's domain is blacklisted is even if the NetSuite domain is not blacklisted but the company's Domain for Bulk Merges is, the messages have a high possibility of not going through. Double check if either domains are blacklisted by using MX Toolbox and issuing the command : blacklist:[DOMAIN to check].com.

     3. If neither of the first two reasons seem to be reason for the emails not going through, send an email using means outside of NetSuite and check if the message can be delivered or will bounce. This is a good way to verify if the emails are indeed valid email addresses.

Some other factors and facts to consider when you encounter this behavior that aids in more advanced forms of troubleshooting and isolating the root cause.

• NetSuite uses a spoofing technique when sending emails in behalf of customers. This technique means that recipients of emails coming from NetSuite will display email headers showing the FROM property as the person actually sending the email, but the REPLY-TO property of the header actually shows an xxx.xxx.xxx@messages.netsuite.com address. This behavior is commonly used by spammers for phishing attacks and to some extent these emails are commonly blocked by mail servers by default. Whitelisting, SPF records as well as DKIM and Domains are among the more common solutions for this scenario to allow email to go through.
• Most mail servers and ISPs will commonly reject messages sent to a very large number of its users especially if the emails are coming from only one domain. This is sometimes misinterpreted as a DOS (Denial of Service) Attack on the mail server and to prevent the mail server from being overloaded, this behavior gets blocked automatically. Yahoo! Mail and Live Mail / Hotmail are known to exhibit this behavior causing emails not to reach subscribers who use these web mails.
• Some mail servers and ISPs will automatically junk messages with, but not limited to, the following characteristics due to being marketing or spamming related features:
• • Messages containing a lot of links to one ore more websites
  • Messages containing long lines of texts with characters not found in a common dictionary
  • Messages that appear to be spoofed
  • Messages containing a lot of images
  • Messages with a size of under 5k in size

Note:  In these cases, careful planning and studies will need to be done to the templates being used to ensure deliverability with or without Domains and DKIM set up.

Most mail servers, mail providers and ISPs will be able to analyze email logs for you. In extreme cases where looking at email logs pinpointing the exact time and date that the behavior has occurred would be needed as a last resort, Customers reporting this behavior can check with the receiving end ISP, mail server or mail provider to check how the messages are getting dropped. In most cases, the following things can be revealed when logs are read:

• Emails are automatically getting sent to the Junk folders of the mail server thus end recipients will never see them in their own Junk folders
• Emails are getting queued on the mail server end and may take some time to reach their intended recipients due to heavy processing on the mail server end
• User has marked messages from both the Customer's domain and Netsuite as spam and has prevented any successful future deliveries of email

     In the case where no logs indicate that emails have attempted to go through the mail server, this may mean that the mail server may already be blocking emails silently from either the Customer's Domain, Netsuite or both and further investigation and testing will be needed.

Note: Not all mail servers behave the same way, so in depth investigation on the root cause will always be needed to isolate what is blocking the email.