Optimizing transactional email deliverability with JangoSMTP

Overview:

Email deliverability is a key concern for most transactional email senders, and at JangoSMTP, we do everything possible to ensure the highest possible inbox placement of our clients' emails. In fact, we measure blocking at the SMTP level and have found that on average only 0.2% (2 out of every 1,000) emails are blocked.

Internally, JangoSMTP runs on a highly customizable platform, giving us internal control over sending speeds, email headers, and SMTP protocol level customizations. Externally, users can take advantage of certain settings and features and ensure high email deliverability and sometimes a 0.0% blocking rate. This article focuses on those user-configurable settings.

Following the steps below will solve most email delivery issues.

1. Use your own email address as the SMTP MAIL-FROM address rather than the default of your-username@jangomail.com.
   
   The SMTP MAIL-FROM address is NOT the same as the From Address on your outbound emails. The SMTP MAIL-FROM address is usually invisible to the recipient and is only used during transmission of the email message from one server to another. It is determined by the setting under Settings --> Tracking --> General --> Use system MAIL-FROM address. It is also the address that is used for SPF and SenderID validation. By default, all JangoSMTP accounts start with this checkbox checked, which ensures SPF/SenderID compliance by default and that the MAIL-FROM address is your-username@jangomail.com.
   
   There are two methods to take control of the MAIL-FROM address.
   
   1. Uncheck the "Use system MAIL-FROM address" box under Settings --> Tracking --> General. This helps separate your email delivery reputation from the rest of the JangoSMTP user base. If you uncheck this checkbox, you must ensure that you include jangomail.com in the SPF record for your domain to avoid SPF-based blocks. You can do so by including "include:jangomail.com" in the SPF record.
   
   or
   
   2. Create a special domain or sub-domain specifically for this purpose, inform our Support team, and then we'll set your account to always use your-username@sub.domain.com as the MAIL-FROM. If you opt for this, ensure that the SPF record for sub.domain.com includes "include:jangomail.com" and that the MX record for sub.domain.com points to mail.jangomail.com, which is the incoming email handler for JangoSMTP.
   
   What's the difference between methods 1 and 2?
   
   If your domain is browniekitchen.com, then in method 1:
   
   Display From = joe@browniekitchen.com
   MAIL FROM = joe@browniekitchen.com
   
   You must ensure that the SPF record for browniekitchen.com includes "include:jangomail.com". Replies will go to joe@browniekitchen.com, including auto-replies like "out of office" messages and "Thank you for emailing us" messages. Additionally, replies with "remove" or "unsubscribe" in the Subject will also be sent to joe@browniekitchen.com and have to be manually processed by "Joe". All hard bounces will still be handled automatically by JangoSMTP.
   
   With method 2:
   
   Display From = joe@browniekitchen.com OR joe@mail.browniekitchen.com
   Reply-To = joe@mail.browniekitchen.com
   MAIL FROM = joe@mail.browniekitchen.com
   
   You must ensure that the SPF record for mail.browniekitchen.com includes "include:jangomail.com". Legitimate replies will go to joe@browniekitchen.com or joe@mail.browniekitchen.com, but auto-replies like "out of office" messages and "Thank you for emailing us" messages will go to joe@mail.browniekitchen.com, to be processed and filtered by JangoSMTP automatically. These messages will be viewable under Reports. All hard bounces will still be handled automatically by JangoSMTP. Additionally, replies with "remove" or "unsubscribe" in the Subject will be automatically handled by JangoSMTP, and those recipients added to your Unsubscribe List.
   
   Both methods provide for better deliverability than the default option. Method 2 is the best option in terms of branding around your own organization and the automatic reply-management and bounce processing of JangoSMTP.
   
   Who should do this? The technical person who manages your domain's DNS settings.
   
2. Use a branded tracking domain, that is based on your organization's domain name. The tracking domain is the domain referenced in the open-tracking mechanism, the click-tracking re-directs, and the unsubscribe link. By default, every new JangoSMTP account is assigned a system tracking domain that is shared amongst multiple clients, like x.jango5.com for example.
   
   By setting up your own, you can isolate yourself from the activities of our other clients. Set up your own by clicking the Edit Icon to the right of Settings --> Tracking --> Tracking Domain. If your domain is browniekitchen.com, then setting up x.browniekitchen.com makes for the perfect tracking domain.
   
   
   
   
   
   
   
   Who should do this? The technical person who manages your domain's DNS settings.
   
3. Setup DomainKeys/DKIM for the domain use in your From Address. Both Yahoo! Mail and GMail currently look for DKIM signatures in the headers of email messages. The presence of a DKIM signature fosters a sense of trust that the email was sent by who was purported to send the email. To setup DomainKeys and DKIM in JangoMail, see our PDF entitled Setting up DomainKeys/DKIM with JangoSMTP.
   
   
   
   
   
   
   Who should do this? The technical person who manages your domain's DNS settings.
4. After creating a DomainKeys/DKIM record, click the link in the confirmation email sent from Yahoo to postmaster@yourdomain. Whenever you create a DomainKeys record, we upload it to Yahoo! so that they can process complaints properly and report them back to JangoSMTP via a "Feedback Loop". Yahoo has a special process where they send a confirmation email to postmaster@yourdomain, and that email message contains a link that must be clicked by you in order to activate the Feedback Loop. If you do not do this, complaints will not be properly reported, and your delivery to Yahoo email address will be negatively impacted by recipients that complain over and over and aren't added to your unsubscribe list.
   Who should do this? The person who has access to the postmaster@domain account for your domain. Usually this is your organization's system administrator.
   
5. If you're sending HTML email, make sure you include a corresponding plain text message. Spam filters tend to frown upon emails that have a heavy ratio of HTML to plain text content. This is as easy as setting the Plain Text Message to "auto-generate". This will cause a plain text message to be generated (based on your HTML message) at the time of email sending.
   
   Who should do this? The developer integrating your application with JangoSMTP.
   
6. Enroll in the Return Path Certification program. In order to be accepted, you must have a complaint rate of 0 to 0.1%. Once enrolled, your emails are sent from IP addresses that are certified. Hotmail virtually guarantees inbox placement for emails sent from certified IPs, and Yahoo prioritizes emails sent from certified IPs.
   
   Who should do this? The person using JangoSMTP.
   
7. If using click-tracking, anchor text should be phrases, not URLs. Some spam filters look closely at how you link to determine whether the link is legitimate or fraudulent. They do this to prevent phishing scams--a type of scam where an email pretends to be a request from a legitimate company in order to get the login credentials of that company's user. For more information on phishing, see the Wikipedia article on phishing. The best way to explain good links versus bad links is with an example:
   
   Good Link: Visit our web site.
   
   Bad Link: http://www.browniekitchen.com/
   
   When these URLs are click-tracked in JangoSMTP, the final email message looks like:
   
   Good Click-Tracked Link: Visit our web site.
   Bad Click-Tracked Link: http://x.jango5.com/y.z?l=http://www.browniekitchen.com
   
   What makes the bad link bad is that the anchor text is a URL, and that domain in that URL does not match the domain in the link destination. Phishing filters look for this domain mismatch. In the good example, however, the anchor text is not a URL to begin with, so the phishing filter will accept it as legitimate.
   
   Who should do this? The person designing your email campaigns.

You will now see higher transactional email open rates

Tonight we've made a slight adjustment to how JangoSMTP detects an "open" on a transactional email sent via the API or the SMTP server (relay.jangosmtp.net).

First, some background

Email systems detect that an email has been opened by inserting a 1-pixel image at the bottom of the email message and waiting for that image to be downloaded from the server. Some email programs block images by default, and therefore they prevent transactional email systems like JangoSMTP from detecting the "open". If an email message can be understood by its recipient by not seeing the actual images, because perhaps there is enough text to explain the email message, then it's even more likely that the 1-pixel image won't be downloaded.

Therefore, we have always only counted an email as being "opened" if the 1-pixel image at the bottom of the email was downloaded, meaning that the recipient had viewed the email, and that images (even if there aren't any in the email body) are turned on.

New way to detect an open

We recently determined, however, that in many cases, a recipient may click a URL in an email (thus counting as a click), but never downloads the images in the email (thus NOT counting the open). And since clicking the email is indicative of also opening it, we've made the following change to Open Tracking:

If an email is clicked, but that recipient has not yet been counted as an "open" for that email campaign because images haven't been downloaded, the recipient now WILL get counted as an "open" anyway due to the click.
The net effect of this change is that you will now see higher Open Rates on Transactional Groups, and the Open Rates will be more accurate and reflective of what recipients are actually doing with the transactional email message.

How much of a difference does this make?

Our analysis shows that this makes a big difference. For a recent email campaign we did to a segment of our own customers, these were the statistics in Reporting:

Recipients: 6,369
Unique Opens: 993 (15.6%)
Unique Clicks: 384 (6.0%)

An analysis of the data showed that there were 118 unique recipients that clicked that never registered as having opened the email. So if we add the 118 to 993, that's now a total of 1,111 opens, for an actual open rate of 17.4% instead of 15.6%.

New Feature: Get rid of those From Addresses...

...not literally. You still need a From Address when sending any type of email, but you no longer need to specify your From Addresses in your JangoSMTP Settings when using SMTP Authentication (SMTP AUTH) to authenticate into relay.jangosmtp.net.

This is a substantial enhancement to the SMTP service. By simply setting your email client to use SMTP AUTH and passing in your JangoSMTP username and password, the system will be able to assign your emails to your account. This is especially beneficial to organizations that send emails from many different From Addresses through one single JangoSMTP account.

As a result, we will soon be taking away the screen within Settings where you would normally specify a list of From Addresses when using SMTP username/password authentication.

[This screen will soon be removed from JangoSMTP.]

Note that this only applies to users using username/password to authenticate into the SMTP server. If you're using IP authentication, then there is no change, as users using IP authentication have always been able to send without specifying From Addresses.

Presenting...the first ever JangoSMTP YouTube commercial

You've sent an urgent email. Hours pass, and no response. Do you keep your cool, or fly off the handle?

Why the SMTP service requires a list of From Addresses when using SMTP Authentication

12/6/10 - IMPORTANT UPDATE - As of December 6, 2010, the SMTP service NO LONGER requires a list of From Addresses when using SMTP Authentication. You can disregard this blog post, which was originally written on November 23, 2010. If you're interested in a bit of JangoSMTP history though, then feel free to read on!
-------------------------------------------------------

There are two ways to authenticate into to the JangoSMTP service:

1. By IP Address of the connecting application
2. By SMTP authentication with username and password, also known as SMTP-AUTH. This, coupled with a specified From Address allows you to send an email through the SMTP server.

We are often asked why in the latter case it is necessary to specify a From Address. Why is it not enough to authenticate with username and password for an email message to be validated for a particular account?

Some might guess that it's a security issue, to prevent a flood of unauthorized emails being relayed through a user account should the username and password become compromised or end up in the wrong hands.

It's actually not a security issue, but an architectural limitation of the SMTP service that we will soon be fixing. An explanation of this architectural limitation, for interested readers, is below.

The basic limitation is that SMTP username/password authorization is done at the SMTP-transmission level, and once the email arrives, there is nothing inside the email message to indicate what SMTP username was used to allow the email to arrive in the first place. Hence, the system has to key off the From Email Address.

The steps JangoSMTP takes when an email is relayed to the SMTP server are:

1. At the SMTP level, the email is authenticated by connecting IP address or by SMTP-AUTH. The email must conform one of those two checks in order to arrive. Otherwise, the email will be rejected at the SMTP level with a "we do not relay" error after the RCPT-TO command during the SMTP transaction.
2. Once the email has arrived, a secondary process analyzes the email file in order to determine to what user account it belongs. First, the connecting IP address, which is present at the top of the file in the "Received" line is matched against IP addresses specified in user accounts, and if a match is found, the email is determined to be of that user account. If there's no match, then the assumption is made that the email arrived via SMTP-AUTH and not by IP Address Authentication. In this case, however, there is nothing in the email file that indicates what SMTP username/password were used to transmit the email message, since the SMTP username/password authentication is done during the SMTP level message transmission. No header within the email file contains the SMTP-AUTH information. It is for this reason that the process must rely on the From Address to determine to what user account the email belongs.
   
   
   
3. If it cannot be determined to what user account an email message belongs, it is discarded. If it can be determined, then the process continues with the next step.
   
4. Next the email message is passed to a web service, where it is disassembled and reassembled order to add open tracking, click tracking, DKIM signing, and other mechanics that JangoSMTP supports.
5. Lastly the web service passes the email message to an email sending server in order for final transmission to the email recipient.

Fortunately, this will soon change. We are having the SMTP listener modified such that it will write an X-header to the email message containing the SMTP-AUTH username if it was transmitted via SMTP-AUTH. This will allow our process to then key off of the account username to identify a matching user account, rather than having to key off of the From Address. Once this is in place, it will no longer be necessary to specify From Addresses when using the SMTP service.

JangoSMTP Ports

We've recently had some users ask us on what ports they can connect to the SMTP server at relay.jangosmtp.net. While it's documented on our website on the How it Works page, we thought a separate blog post would make it clearer. You can connect to relay.jangosmtp.net on ports:

1. 25
2. 2525
3. 587
4. 465 for SSL/TLS connections

For more information on SSL/TLS, see the blog post on connecting to JangoSMTP securely.

Transactional Email integration with Google Analytics

Google Analytics integration is now available with transactional email sent through the SMTP relay or through the API.

To start tracking your transactional email with Google Analytics, first turn on Google Analytics in your JangoSMTP account. Click the Edit Icon next to Google Analytics Integration under Settings --> Tracking and follow the steps outlined in the Procedure section.

Transactional email with click-tracked links will take the recipient to a URL that looks like this:

http://www.browniekitchen.com/?utm_source=JangoMail&utm_medium=Email&utm_campaign=Welcome+Group+(22514)&utm_content=ajay.goel%gmail.com

For transactional email, the Campaign Name inside your Google Analytics account will be the Transactional Group Name inside your JangoSMTP account. And the Content inside your Google Analytics account will be the email address of the recipient.

For transactional email, it wouldn't make sense to use each individual email's Subject line, because if you send 1,000 transactional emails, all with different Subject lines, you'll end up with 1,000 different campaigns in your Google Analytics account, and making sense of the data would be impossible. That's why transactional emails will be categorized by their Transactional Group Name and not their Subject.

You may use any combination of these values in the four Google Analytics variable fields:

%%EmailAddress%% = the email address of recipient
%%TransactionalGroupName%% = the Transactional Group Name of a transactional email
%%TransactionalGroupID%% = the Transactional Group ID of a transactional email

To set this up...

1. You must have click-tracking enabled on your transactional email. If using the SMTP Relay, check the Activate Click Tracking checkbox under Settings --> Tracking --> General. If using the transactional email API, set "ClickTracking=True" in the Options input parameter of one of the following methods:

SendTransactionalEmail
SendTransactionalEmailFromTemplate

2. Turn on Google Analytics by checking the box under Settings --> Tracking --> Google Analytics Integration, as shown in the second screenshot.

New Feature: Our platform, your servers

Going Freemium: Our platform, your servers

You can now use JangoSMTP's interface, features, and functionality, with your own email servers. Specifically, you can now designate one or more "Smart Hosts" for your JangoSMTP account and have all transactional email sent by the Smart Hosts instead of JangoSMTP's own email servers. A smart host is an email server on your own network or one that you control. The best part is you can send 100,000 emails/month for free when using your own email servers to deliver your email.

How can this possibly work?

By setting your account to use a Smart Host, you are telling JangoSMTP to route email messages through the Smart Host rather than directly to the recipients. The Smart Host will actually deliver each email message to the recipient.

For example, let's say you manage www.browniekitchen.com. Your corporate email servers are smtp.browniekitchen.com and smtp2.browniekitchen.com, and you want your transactional email sent from your servers instead of ours. You would designate these to be the Smart Hosts for your JangoSMTP account. You then use your JangoSMTP account to send 100 email messages, to varying domains, like yahoo.com, gmail.com, and aol.com. JangoSMTP will send all 100 emails to smtp.browniekitchen.com and smtp2.browniekitchen.com, and these servers will then deliver the email messages to Yahoo's, GMail's and AOL's servers.

In essence, when using Smart Hosts with the SMTP relay, your application would relay the emails to relay.jangosmtp.net, which would then process the email, add open tracking, click tracking, and a DomainKeys signature, and then relay the email back to your own server for delivery to the recipient.

So the Smart Host is just a middleman server between JangoSMTP and the final recipient?

Yes. It allows the emails to originate from your IP and your domain name and your organization rather than ours. It allows you complete control over your own email deliverability, and allows you to monitor SMTP logs, traffic, blocks, and throttling on your email server. Learn more about Smart Hosts with the Wikipedia article on Smart Hosts.

What's the point of this feature?

This feature is meant for those customers that want to use us for everything, except email deliverability, and enjoy a significant cost savings for doing so. It's for those that like our feature set, our interface, our API, and everything else about JangoSMTP, but don't need us for actual email delivery, because their own email servers can handle that.

We spend a lot of time ensuring that our own email servers are clean, fast, of high reputation, and secure. Deliverability issues can also be difficult to research. By allowing you to have the emails sent from your own email servers, it gives you the full power to research such issues because you now have the information necessary to do so.

Setting up this feature is not for the average JangoSMTP user. It's meant for network administrators, sysadmins, and developers who want to take advantage of a significant cost savings by offloading email delivery onto their own network. When using a Smart Host, you must ensure that the Smart Host is configured properly to deliver high volume email. Most corporate email servers are not able to deliver high volume email because a.) Their upstream ISP does not allow the network to be used for mass email delivery and b.) The IP address of the organization's email server does not have the deliverability reputation necessary to deliver large amounts of emails to consumer email domains, like gmail.com, yahoo.com, aol.com, and live.com. This reputation can be developed over time, however, using a process called IP Warmup.

How do I configure my Smart Host to send emails from JangoSMTP?

Click the Edit Icon next to Settings --> Advanced --> Smart Hosts. You must ensure that your Smart Host server is able to relay emails that originate from our IP addresses. By default, all emails being routed to Smart Hosts will be sent from one of three IP addresses:

sh1.jsmtp.net - 216.75.6.141
sh2.jsmtp.net - 209.190.39.50
sh3.jsmtp.net - 66.40.10.14

This list of servers is also shown in this section. You should enter all of the IP addresses into the "Authenticated IPs" or "Allow Relays From these IPs" settings in your smart host's SMTP settings.

Optionally, if your Smart Host server is able to authenticate by domain name, you can allow any servers that are named *.jsmtp.net to relay through your server. That way, should the JangoSMTP IP addresses change, you won't need to change your smart host configuration.

If you don't do this, when JangoSMTP attempts to send emails to your smart host, JangoSMTP will get a "Relay access denied" or "Unable to relay email" type SMTP error, and the email will not deliver.

You can test your email server's configuration with the Test Icon under Settings --> Advanced --> Smart Hosts. The test feature will attempt to relay an email message through your email server from all three JangoSMTP servers. If the test passes, you're ready to send through your Smart Hosts. If the test fails, that means you haven't configured your Smart Host properly to allow SMTP relays from the three JangoSMTP IP addresses.

In the above example for the Brownie Kitchen account, emails sent to yahoo.com will be sent by smtp2.brownikitchen.com and all other emails will be sent by smtp.browniekitchen.com. Domain-specific rules take precedence over an ALL DOMAINS rule.

Can I use a third party server as my JangoSMTP Smart Host?

Yes, you can! There are many third-party SMTP services, any of which you can use as a smart host with JangoSMTP, provided that third-party SMTP service allows relay authentication by IP address. Remember that wherever your smart host is located, it must allow relays from our three IP addresses:

sh1.jsmtp.net - 216.75.6.141
sh2.jsmtp.net - 209.190.39.50
sh3.jsmtp.net - 66.40.10.14

Unfortunately we do not support SMTP-AUTH authentication.

This may lead to the question: Can a JangoSMTP user use JangoSMTP as the Smart Host? Your account is prevented from doing this, as this would create an infinite email loop.

Won't SPF/SenderID fail if I set a smart host?

Not if you set up properly. You must carefully take into account SPF/SenderID settings when using a smart host. You need to ensure the following:

1. Ensure that the MAIL-FROM setting is correct.
   
   a. Transactional email via API: Set UseSystemMailFrom in the Options parameter to False.
   b. Transactional email via SMTP Relay: Uncheck the Use system MAIL-FROM address box under Settings --> Tracking --> General.
   
   
   
   
   
   
2. Ensure that the SPF record for the domain in your From Address, which is a DNS TXT record, includes the IP address of your Smart Host.
   
   For example, if you're sending emails from orders@browniekitchen.com, and your Smart Host is smtp.browniekitchen.com, and the IP address for smtp.browniekitchen.com is 10.10.10.5, then the SPF record for browniekitchen.com might look like this:
   
   "v=spf1 include:jangomail.com ip4:10.10.10.5 a mx -all"
   
   While the include:jangomail.com directive is not necessary, it can be left in place in case Smart Hosts are ever removed from your account in the future.
   

How do I set up Feedback Loops (FBLs)?

Most feedback loops (FBLs) work based on the sending IP address. Yahoo! is the exception, as it's based on the DomainKeys signature. Since by using Smart Hosts, the sending IP address will be that of your own email server, you must set up FBLs for your own IP. For ease of management, you may have the abuse reports sent to fbl_sh@us.jangomail.com, a special email address we've set up to process Abuse Reports for customers using Smart Hosts.

How do I my ensure DomainKeys/DKIM settings work?

DomainKeys/DKIM headers are preserved in transit, so regardless of how many email servers your messages bounce between before arriving to their final recipient, your DomainKeys/DKIM headers will remain intact.

What are the disadvantages of using Smart Hosts?

When you have your emails sent through your own smart hosts, you are in charge of all email delivery issues. Our support staff will only be able to provide very limited help for email delivery issues since the email is being sent from your server, not ours. Therefore, it's only recommended you use this feature if you're able to monitor your delivery as well. All tracking functionality, like open tracking, and click tracking, and web site activity tracking, will still work, and you'll still see all of that data in Reporting.

Will I lose any functionality if I send through a Smart Host?

No. Every single JangoSMTP feature will still work. The only difference when you setup Smart Hosts is that the emails are sent from your servers, not ours.

What if I try sending through my own servers, but I find the email deliverability too difficult to manage?

No problem, you're welcome to come back to the "regular" JangoSMTP service and have the emails sent through our high deliverability servers. All you have to do is delete the Smart Hosts entries from your Settings --> Advanced --> Smart Hosts page.

What are the cost savings for sending through my own servers?

You may send up to 100,000 emails/month for free through JangoSMTP if using Smart Hosts.

Exactly what do I need to do to set up Smart Hosts for my account?

1. Configure your Smart Host. Modify your email server's settings to allow SMTP relays from the three above-mentioned IP addresses.
2. Add the Smart Hosts into your JangoSMTP account. Go to Settings -> Advanced --> Smart Hosts, and add the Smart Host. Then Test it to ensure that your email server is setup correctly.
3. Set up SPF/SenderID. Go to Settings --> Tracking --> General and uncheck the Use system Mail-FROM address checkbox. Additionally, ensure that the IP address of your Smart Host is listed in the SPF record of your organization's domain.
4. Set up Feedback Loops, so that complaint reporting is reflected in your account. Set up feedback loops with AOL, Comcast, Juno/NetZero, Yahoo! and anyone else that allows them, and have the Abuse Reports sent to fbl_sh@us.jangomail.com so that our system can process them.
   

New SMTP relay service feature: Authenticate a Class C IP block

Our customers using the Jango SMTP relay can now add a full class C IP block to their list of authenticated IP addresses, instead of adding single IPs at a time. To add a class C block of IP addresses (255 IP addresses), contact our support team, and they can do this for you, as the feature is not yet available through our web interface.

Why would I need to allow 255 IP addresses to relay email?

Most customers will not need to do this, but we have some customers that are ISPs, web hosting companies, and cloud computing services. These organizations often need to allow larger blocks of IP addresses in order to serve their own customers.

New method to specify Transactional Group using the SMTP server

We've introduced a new method to assign a transactional email to a Transactional Group. Along with specifying the Transactional Group in the Subject line, you can now also specify it in a custom X-Header.

If you're using the JangoSMTP server to send transactional email, you're likely familiar with the concept of Transactional Groups -- categories to which you can assign various types of transactional emails. For example you may have the following Transactional Groups set up in your account:

1. Order Confirmations
2. Renewal Reminders
3. Thank Yous

Previously you could assign an email to a particular Transactional Group by specifying the Transactional Group's name in the Subject Line surrounded by curly brackets. For example, if I sent an email with the Subject:

Subject: Thanks for your purchase {Thank Yous}

...then this email would get assigned to the Transactional Group called "Thank Yous", and the email would be sent with the curly brackets and the part in between stripped out.

Now, there's an alternate way to assign an email to a particular Transactional Group...you can specify an X-header with the Transactional Group's ID. If you're sending emails through relay.jangosmtp.net programatically, such as through .Net or PHP code, and if you have the ability to add an X-header to the email message, you can use this method. The format is as follows:

X-TransGroupID: TransactionalGroupID

For example, if the Transactional Group "Thank Yous" had an ID number of 78929, then you would add the header:

X-TransGroupID: 78929

Specifying an X-TransGroupID header overrides any Transactional Group designation in the Subject Line.

You can retrieve the ID number of a Transactional Group by going to the Transactional Reporting section of your account, where the various Transactional Groups are listed, along with their delivery statistics and their ID numbers.

Better design for API homepage

We have re-designed the homepage of the API to be cleaner, more organized, easier to use, and easier to access documentation for each individual web service method. You can see the difference between the new and the old versions below.

Each method is organized into its proper category, has a link to a test form to call the method, and a link to the detailed documentation for the method.

New API homepage design

Old homepage design

JangoSMTP now supports SSL/TLS

JangoMail has added support for SSL connections to our relay server from your email client of choice (e.g. Outlook, Thunderbird, Mac Mail, etc.). Just as when you use an HTTPS connection to connect to a website and make a secure online purchase, you can use the same technology to setup a secure connection with JangoMail and send email through your JangoSMTP account. This ensures your JangoSMTP username and password remain secure as they are transmitted between your computer and JangoSMTP relay servers. All that's needed to enable this feature a quick settings change in your email client.

Note: These instructions assume you already have your JangoSMTP account setup in your mail client. Follow these directions if you don't already have your mail client setup to send through your JangoSMTP account.

Outlook:

1. Click on Tools -> Account Settings
2. Highlight your JangoSMTP account and click Change...
3. Click More Settings...
4. Go to the Advanced tab
5. Choose SSL in the Use the following type of encrypted connection: dropdown
6. Change the Outgoing server (SMTP) port number to 465

Thunderbird:

1. Go to Tools -> Account Settings
2. Click Outgoing Server (SMTP)
3. Choose the entry for relay.jangosmtp.net and click Edit
4. Check the Use Secure Connection box and choose SSL/TLS from the Connection security dropdown

Mac Mail:

1. Go to Mail -> Preferences
2. Click on the Accounts tab
   
3. Choose your JangoSMTP account at the left
4. Click on Edit Server List... from the Outgoing Mail Server (SMTP) dropdown
5. Select the entry for relay.jangosmtp.net and click on the Advanced tab
6. Put a check next to Use Secure Sockets Layer (SSL)
7. Select Use custom port and enter 465 as the value

Most modern email clients support SSL/TLS. If your email client is not listed above, open up your account settings configuration page and find the outgoing email server connection settings. The option you want to enable will be called SSL/TLS (not STARTTLS). Also look out for a default connection port. Generally this port number will be 25 or 2525 before you setup SSL/TLS, but it should be changed to 465 after the feature is setup. When in doubt, submit a support ticket and a member of the JangoSMTP support team will be able to assist you in choosing the right options.

Three Bug Fixes to SMTP Service

We've deployed three bug fixes to JangoMail's SMTP Server, relay.jangosmtp.net. These three bugs were detected by customers relaying emails with eccentric attributes through the SMTP server.

1. Emails containing MIME boundaries with parentheses will now be properly handled.

Previously, emails with parentheses in the MIME boundaries, such as a boundary like:

Content-Type: multipart/mixed; boundary="nqp=nb64=()BDXjw0yWx"

would cause the JangoSMTP parser to throw an error. This is now fixed.

2. Emails containing unrecognized Content-Transfer-Encoding types will now default to "7bit".

Previously, if an email message contained an unrecognized or misspelled encoding type, like:

Content-Transfer-Encoding: 7 bit

would cause the JangoSMTP parser to throw an error. This is now fixed.

3. Emails containing foreign characters encoded as ISO-8859-1 will be properly handled.

Previously, an email containing certain foreign characters would have those characters replaced with ? marks or garbled when passed through the relay. For example, a Subject like:

Subject: Confirmation d'Inscription à la Liste de Diffusion - Liste TEST ML

would not have its foreign characters preserved. This is now fixed.

SMTP Relay Server Enhancements

We've deployed a couple of enhancements and bug fixes to the SMTP service.

1. MIME encoded Subject lines containing a Transactional Group are now handled properly.
   
   According to the SMTP MIME specification, certain email headers can be MIME encoded. It's called the encoded-word syntax. For example, the Subject of an email might actually look like:
   
   Subject: =?utf-8?Q?Savings_For_Today{Daily_Alert}?=
   
   This represents a subject that is character-encoded as UTF-8 and content-transfer-encoded as quoted-printable. This Subject, properly rendered by an email client would look like:
   
   Subject: Savings for Today{Daily Alert}
   For the purposes of the JangoMail SMTP Server, the subject can contain the Transactional Group that the message should be assigned to in curly brackets. So if this message was relayed through relay.jangosmtp.net, then the actual Subject would be "Savings for Today", and this message would be assigned to the Transactional Group "Daily Alert" in the user's account. Previously, our system was not decoding the Subject properly in order to determine the correct Transactional Group name to which to assign the email, but that has now been corrected in today's release.
   
2. If the Sender header is specified in the original email, that header is now preserved.
   
   The Sender header, similar to the From header of an email, can be used to denote additional information about where the email originated. Most email messages do not contain a Sender header, but in some cases, a Sender header is inserted by an email system if the user is using a From Address not local to that particular email system. For example, GMail users who send "from" an address other than their gmail.com address will have a Sender header inserted into the email where the Sender header equals the gmail.com address and the From address equals the user's chosen From Address.
   
   On the receiving side, some email clients will show the Sender header as a phrase to the email recipient, saying "From [From Address] On Behalf Of [Sender Address]"
   
   Previously, if an email was relayed through the relay server that included a Sender header, the Sender header would be discarded by our system and not included in the final email message. Now, the system is preserving the Sender header.

Why you can't connect to the SMTP relay server

We often get inquiries from customers telling us that they're unable to relay emails through relay.jangosmtp.net. Here is a list of the most common reasons why it doesn't work.

1. Your Internet Service Provider (ISP) is blocking access to external email servers. By default, the SMTP server listens on port 25, and many ISPs block connections on port 25 in order to prevent you from emailing through an external email server. For this reason, our SMTP server also listens on port 587 and 2525. You can also connect securely over SSL/TLS on port 465. You can test connectivity from a Command Prompt by typing:
   
   telnet relay.jangosmtp.net 25
   
   
   
   
   Successfully connecting to relay.jangosmtp.net
   
   
   If that doesn't work, try:
   
   telnet relay.jangosmtp.net 2525
   
   You should get a response from the server as shown in the screenshot above.
2. You haven't setup a proper authentication method. In order to relay emails through relay.jangosmtp.net, you must login to your account, go to Settings --> SMTP Relay, and authenticate either by IP Address or Username/Password.
3. You are connecting to the wrong server. We've had customers attempt to connect to relay.jangosmtp.com, relay.jangomail.com, and relay.jangomail.net, all of which are incorrect. The correct server is relay.jangosmtp.net.
4. You are manually inputting SMTP commands in order to complete a SMTP transaction. Unfortunately, unless you manually input the data for a proper and well-formed email message, including a Subject and a Message, our system will discard it.

How do you know if your email goes through the relay server properly? You will see your email almost instantly in Reporting after you send it.

New API method to retrieve SMTP log files

Several years ago, we were the first email service provider to provide access to SMTP logs for email marketing campaigns. Now we're the first to provide access to SMTP logs via an API. Today we have launched the method Reports_GetSMTPLog to retrieve the SMTP log for a given email address for a given email campaign. Just pass in the campaign ID and the recipient email address.

This method only retrieves SMTP logs for broadcast email marketing campaigns. We are working on a method to retrieve SMTP logs for transactional email messages as well, but this poses some challenges not seen with broadcast campaigns. For example, while broadcast campaigns generally don't have duplicate email addresses, it is very possible that in a Transactional Group's email messages, a single email address has received multiple transactional messages over time. Thus, simply passing in a Transactional Group Name and an email address won't suffice for retrieving the log, since the API needs to be able to determine the time range of logs to search in order to display them to the caller.

Reports_GetSMTPLog
Returns the SMTP log for a specified recipient of a specified email campaign

Two new API methods to change Group names

We have deployed two new API methods. Groups_Rename allows you to change the name of an Email Group (aka Email List). And TransactionalGroups_Rename allows you to change the name of a Transactional Email Group.





Both of these methods were the request of a client.

TransactionalGroups_Rename
Renames a transactional group. Returns a String.

Groups_Rename
Renames a group. Returns a String.

Five new API methods

We've added the following five API/web service methods to improve our transactional email capabilities. All were requested by prospects evaluating JangoMail. Do you have a request for an API method that would make your developer's life easier? Let us know by filling out our Support form.

Click each method name to use its corresponding test form.

Reports_GetBouncesByTransactionalGroup_XML
Retrieves list of bounced addresses for a particular transactional group. Includes SMTP Diagnostic Code and Definitive columns. Returns an XML document.

Reports_GetBouncesByTransactionalGroup_String
Retrieves list of bounced addresses for a particular transactional group. Includes SMTP Diagnostic Code and Definitive columns. Returns a string.

Reports_GetBouncesByTransactionalGroup_DataSet
Retrieves list of bounced addresses for a particular transactional group. Includes SMTP Diagnostic Code and Definitive columns. Returns a .NET DataSet.

DeleteTransactionalGroup
Deletes a transactional group from account. Returns a string.

GetTransactionalGroupID
Gets a transactional group id. Returns a string.

Two bug fixes in SMTP relay service

We've just deployed two fixes to the JangoSMTP transactional email service:

1. Previously, lines in an email message that begin with a single period would result in two periods when delivered to the recipient. This was a bug related to how SMTP treats the escaping of periods. This is now fixed. To read more about issues involving SMTP and periods, see this article: http://db.ilug-bom.org.in/lug-authors/philip/docs/mail-stuff/smtp-intro.html

2. Previously, if an email message was relayed to relay.jangosmtp.net and included both the Disposition-Notification-To and the Return-Receipt-To headers, then JangoSMTP would throw an error on the email message:

System.ArgumentException: An item with the same key has already been added.

This is now fixed, and email messages containing both headers will be delivered properly.

Transactional emails now support List-Unsubscribe header option

Back in July, we announced support for the List-Unsubscribe header in broadcast email campaigns sent via JangoMail.

Starting today, the List-Unsubscribe header will also be applied to transactional email messages. Transactional emails are email messages sent via any of the following methods:

1. The SMTP relay service
2. Any of the following API methods: SendTransactionalEmail, SendTransactionalEmailFromTemplate, SendTransactionalEmailRaw

See the original July blog post for information on how this header affects your email messages. It is our recommendation, that all clients leave this header turned on. If you wish to turn it off, you may do so under Settings --> Unsubscribe Options.