Location metrics have been relocated within Reporting

To improve consistency and avoid confusion in a campaign's Reporting metrics, Geotracking Location data has been moved to display along with the Raw Data of a Campaign's Details reports. This data had previously been located along the different ways to group data (by Domain, by Sender, by Email Client, etc.), though it did not group by location.

Now, you will find the location data in the raw data report itself.

The additional columns showing Geotracking's Country Code, Region, City, Zip Code, ISP, Domain Name, Latitude, and Longitude are on the right.

New web service method to fetch SMTP log of transactional email

We've launched a new JangoSMTP API method to retrieve the SMTP log for a transactional email message. The method, Reports_GetSMTPLog_Transactional, is described in detail below.

Reports_GetSMTPLog_Transactional
Returns the SMTP log session for the specified transactional email message

The method takes, as input parameters, the JangoSMTP account username, password, and the numeric Transactional ID corresponding to the transactional email for which the SMTP Log should be retrieved. The method was designed around the Transactional ID rather than a recipient email address, since the Transactional ID will always be unique per individual transactional email message. With email addresses, there can be multiple transactional emails to the same address within an account.

Thet Transactional ID can be retrieved from the User Interface in Reporting, or via other API methods, like Reports_Transactional_GetRecipients_XML.

A sample output of Reports_GetSMTPLog_Transactional is shown below:


JangoSMTP is the only email service that offers access to SMTP logs for transactional email, and is now also the only service to do so through an API. The full API, including documentation and test forms, is at http://api.jangomail.com. The methods that apply to JangoSMTP are in the categories Transactional Sending and Transactional Reporting.

How replies are routed when you send a transactional email to an email-to-SMS gateway address

We recently had a JangoSMTP client report to us that when they used JangoSMTP to send an email message to an SMS-gateway address, that replies didn't go to the From Address. We investigated and found that transactional emails sent to SMS-gateway email addresses replies routed not to the From Address, but to the SMTP level MAIL-FROM used during the SMTP transaction.

The MAIL-FROM address is also known as the "envelope sender" or the "Return Path".

The MAIL-FROM address is a different part of the email message than the regular From Address which most recipients see. The MAIL-FROM address is used during the communication between two servers as an email message is sent. In our research we've found that the MAIL-FROM only ever receives replies if the email is sent to an SMS gateway email address.

To make sense of the technical details, it's easiest to look at an example. I use T-Mobile for my BlackBerry. My mobile number is 937-838-0921 (I've altered the number to protect my phone from ringing off the hook after this post.) Anyone can send me an SMS message by sending an email to 9378380921@tmomail.net. tmomail.net is the domain T-Mobile is using for their email-to-SMS gateway. If you send an email to 9378380921@tmomail.net, that email message generates an SMS to my BlackBerry.

[Above is an email message "from" ajay.goel@silicomm.com that generates the SMS]

[Above is the SMS message on my BlackBerry]

Let's examine the SMS message on my BlackBerry. Notice that the From Address of ajay.goel@silicomm.com shows in the message, but it's not the From Address of the message, because SMS messages don't have From Addresses. The sender of an SMS message is usually a mobile number or a short-code, but in this case, the sender is simply shown as 3662. The actual text of the SMS message is a concatenation of the various parts of my original email...specifically, the text of the SMS message is my email's From Address plus its Subject plus its Message.

Therefore replying to this text will not send an email to ajay.goel@silicomm.com. It sends it to a T-Mobile system, identified by the number 3662.



T-Mobile receives the reply and then sends an email, but where will T-Mobile send this email? One would guess that the reply would be routed to the From Address of the original email (ajay.goel@silicomm.com), but in fact the reply is routed to the MAIL-FROM of the original email (ajay.goel@jangomail.com). In this case, "ajay.goel" is the username of the JangoSMTP account used to send the email, which is why the MAIL-FROM is ajay.goel@jangomail.com.

The MAIL-FROM address is shown in the SMTP log of the original email message:



Why do replies to text messages work this way?

We don't know exactly, and our research into how SMS works hasn't provided any answers. We've verified that replies work this way on both T-Mobile's and AT&T's networks. Our best guess is that mobile phone companies all use the same software to translate email messages into text messages, and during the transmission of the email to the SMS gateway, the first address seen is captured and stored as the reply address. Since an actual SMS message doesn't have a property for a return email address, the mobile network must store the reply address on its end, outside of what the mobile phone user sees, and then associate that reply address with the SMS user's response to the 4-digit sender code (3662 in the above example). The first address that's seen is the MAIL-FROM address during the initial SMTP communication, and therefore that becomes the reply address that the mobile company uses.

What happens when an email is sent to your-username@jangomail.com?

JangoSMTP is intelligent enough to receive the email sent to your-username@jangomail.com, identify the email as a legitimate reply to your message, and then forward the message to an email address of your choosing. Any legitimate reply email messages sent to a MAIL-FROM address that is controlled by JangoSMTP, such as any @jangomail.com addresses, are then forwarded to the address that you used when you first created your JangoSMTP account. This can be changed by contacting our Support team. In the future, this will be a configurable parameter under Settings.

How JangoSMTP sets the MAIL-FROM address

By default, the MAIL-FROM address is your JangoSMTP account username followed by @jangomail.com. So if your username is "browniekichen" your default MAIL-FROM address is browniekitchen@jangomail.com.

Even if you set your actual From Address on your transactional email to joe@browniekitchen.com, the MAIL-FROM will be browniekitchen@jangomail.com. It is set this way to ensure SPF/SenderID compliance and to allow for automated bounce processing.

However, JangoSMTP does allow you to override the default and take control the MAIL-FROM address. There are two methods to accomplish this, and they are both explained in step 1 of the post on optimizing transactional email deliverability.

Both methods provide for better deliverability than the default option.

Resources:

Wikipedia's list of email-to-SMS gateways
Wikipedia article on the MAIL-FROM address
JangoSMTP Support

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?