Successful Email delivery can not be guaranteed anymore!
This is a second Internet Software Sciences Newsletter devoted to Email delivery! I feel this is one of the most important topics that every business and organization should be researching, discussing and engineering solutions today. We all need to maximize your email delivery to your clients. Can you imagine the steps you would take if you felt that your regular postal mail was sometimes delivered, based on the subjective analysis of the carrier? Email is still the conduit by which much of “business” of the world still depends upon. Having that conduit reliability of email delivery continually changing is a big problem, especially when many organizations simply do not have the bandwidth or expertise to upgrade their email systems to stay current.
For background about Email Delivery Issues, please review the last ISS newsletter on Email delivery.
In this issue, we are going to focus on solutions that you can do increase your email delivery rates.
External Authenticated SMTP Servers
In a nut shell, email delivery is more likely to pass the mail receivers sniff tests when the SMTP server or gateway that is used to send the email can be successfully verified for the domain of the sender.
If I send you an email from support@inet-sciences.com, the gateway IP of the SMTP server that sends that email is recorded in the email message and carefully reviewed by the receiver email system. The receiving email system them looks at the domain name of the sender (inet-sciences.com) and then checks to see if there exists special domain records that list that gateway IP as an authenticated SMTP gateway for my domain. If I send that email through an open relay or some SMTP gateway that is shared by multiple users and domains, typically that STMP domain authentication/verification will fail and your email could be put into SPAM or blocked, or possibly never accessible for the destination user.
To send your emails through an external SMTP gateway that can configure the necessary SMTP SPF email verification, I configured am external SMTP Server I researched on the Internet to test sending of regular emails and also Web+Center email notifications.
I selected the vendor SMTP2Go.com. They offer for free 1000 emails per month which should be sufficient for this trial test and long term Web+Center support operations here.
After creating an account with them, you will have to configure some CNAME records on your domain that will be used when receivers get emails sent through their SMTP gateway and their software wants to “authenticate” that this gateway (SMTP2Go) is authorized to send email from your domain.
To do this, SMTP prompted with this webpage that shows what 3 CNAME records I needed to add to my domain.
NOTE: You must have access to your domain manager to be able to add CNAME records to your domain for this work.
So I added the 3 CNAME records of em455488, s455488._domainkey , link wit the values specified.
Once I entered those DNS entries in my GoDaddy DNS manager, I clicked the Verify button to confirm that the correct CNAME records were now visible to those doing an DNS lookup for SMTP domain authentication.
When I send email through their SMTP server, I use an SMTP user account I have set up at SMTP2GO that has a user name and password I used when connecting to the SMTP server.
So my SMTP connection is:
- SMTP Server: mail.smtp2go.com
- SMTP Port: 2025
- SSL
- Specified username and password for Inet-sciences.com
Tracking and Delivery
Using this SMTP gateway, I can also access delivery and tracking information for each email as the figure shows below.
Web+Center notifications and External SMTP servers
I originally became aware of some of these issues when a Web+Center client submitted a Web+Center based trouble ticket on my support site and he was never receiving the customer notification messages. I was updating the ticket, and the notification emails were sent out through the default SMTP gateway provided for Virtual Private Servers at GoDaddy. After many levels of probing of IT departments that control email security where the email was stuck on the receiver side, he determined that there was no way the emails sent from that GoDaddy SMTP gateway from my ticketing system could ever be whitelisted to be delivered to this city employee.
To solve this problem I configured my SMTP2Go info and thenI entered in my external SMTP information on the SMTP host configuration options on the System Configuration Options page the details:
Additionally, I had to modify the SendEmail.inc file, located in the Web+Center language directory with some custom code to handle the special 2525 port TLS requirements by adding these lines of code at the end of SendEmail() subroutine.
IF (instr(1, smtp_host_address, “smtp2go”, 1) <> 0 ) Then ‘ The string smtp2go is found in the hostname so launch tls ‘ 11/16/20
‘ Send email by SSL connection with direct TLS with port 2525.
oSmtp.ServerPort = 2525
oSmtp.SSL_init
oSmtp.SSL_starttls = 1
End If
For my Virtual Private Server hosting, some other port blocks were preventing mail delivery over Port 2525. I additional had to create a special new rule under Windows Firewall with Advanced Security as a new outbound rules. I don’t think this step will be required for most, but I included it here if you are hosting Web+Center on a VPS that has other restrictions for outgoing mail.
First the rule was created with these settings on the Protocols and Ports tab:
I have configured other outgoing emails to use this external SMTP gateway that has proper Email Domain verification integrated with their messages. Email delivery has been confirmed by that Web+Center client that couldn’t receive them before this change.
Conclusions:
I am writing this newsletter for many of small businesses and organizations that you might be supporting as a Web+Center IT ticketing system user. Your IT support organization may be savvy enough to have your SPF records finely tuned for delivery, but are your small business clients aware of the Email Domain verification requirements for proper delivery? Special thanks to Dave, a long time Web+Center user that uses Web+Center for a larger government system application. He was instrumental in discovering and researching his lost emails and helped perform various delivery tests and verification.