I read blogs, as well as write one. The 'blogroll' on this site reproduces some posts from some of the people I enjoy reading. There are currently 2 posts from the blog 'Postmark.'
Disclaimer: Reproducing an article here need not necessarily imply agreement or endorsement!
When you think about an email address, you probably think of it as something that doesn’t change, such as your co-worker’s address, your friend’s personal address, or a company support address. You likely don’t think of an email address as something that spawns as needed: a generated email address.
Generated email addresses are a great way to make your SaaS product a lot more convenient to use. Consider the following two scenarios:
- An issue tracking tool lets users send emails directly to a project. These emails automatically create new issues in the project. Whenever someone updates an issue, the person assigned to it is emailed. They can then reply to that email and the issue is automatically updated without requiring that user to log in to the app.
- A job applicant tracking tool lets aspiring candidates send a resume and cover letter to a customized email address rather than through a web form. These emails create new application records in the tracking tool allowing a hiring team to review, respond and schedule interviews with the applicant.
Both scenarios require a way to map incoming emails to the right place. The only practical way to do this is if the email addresses are generated from within the app. For instance, every time a new project is created in the issue tracker, a custom email address is assigned to that project. Similarly, every time a new job opening is created in the job applicant tracker, a custom email address is assigned for application submissions. This way you can store the generated email addresses in a database, reference it whenever emails are sent in, and map the addresses accordingly.
This is exactly how we handle incoming emails with DoneDone, an issue tracking and customer support tool. For the past six years, we’ve relied on Postmark to process all of our incoming application emails. Users can send emails to a custom project address to log an issue or reply back to application emails to update issues.
In this post, I’ll show you how we use G Suite (formerly Google Apps) and Postmark to process generated emails. Before we begin, you should have a G Suite account tied to your product’s domain name, and you should have configured MX records for the domain to point to Gmail. While this tutorial highlights how we use this technique for issue tracking, generated email addresses could be used to update anything in your SaaS product.Set up a catch-all address for incoming email
The first step is to set up a new user in our G Suite account. This user’s email address will serve as the catch-all address for any random email addresses pointing to our domain. In our case, for example, we can set up a user with an email address of firstname.lastname@example.org.Route emails to your catch-all address
Next, we want Gmail to forward all inbound emails that do not already map to an existing G Suite user account to our catch-all address. The key to routing an email to the right place is in the local-part of the generated email address.
For example, a support desk project might have an address of email@example.com. An email update to an issue might have a reply-to address that looks something like firstname.lastname@example.org. When DoneDone receives email, it looks at the local-part of the address (e.g. c8h29d73-issue-reply) and the from address of the email. With those two pieces of information, the application knows who the email is from and what it is in reference to.
In the Google Admin portal, go to Gmail’s routing settings. The admin portal is a bit of a jungle, so I just type “routing” in the search bar and select the result pointing to Gmail’s “Advanced settings.”
Once there, scroll down to the “Routing” section. Rollover the Routing subsection and click “Add” to add a new routing rule. At this point, a modal window should pop up with routing options.
Here’s what to fill out:
- Name the routing rule. I call mine “Catch-all routing.”
- Under Messages to affect, check “Inbound.”
- Under For the above types of messages, do the following
- Select “Modify message” from the dropdown.
- Under Headers, check “Add X-Gm-Original-To header.”
- Under Envelope Recipient, check “Change envelope recipient.”
- Next, select the "______@ existing-domain" option. In the input field, type in the local-part of the email address for the user you just created. (e.g. “catch-all”).
- Next, select the “Show Options” link.
- Under Account types to affect, check ”Unrecognized / Catch-all.”
- Finally, save the new routing rule.
So, what did we accomplish here? We created a rule letting Gmail know to direct any emails to an unrecognized email address in our domain to the catch-all address. Now, whatever randomly generated email address we create will land there!Configure inbound forwarding and processing in Postmark
Now that we have our catch-all address setup, we need to:
- Forward emails from this inbox into our Postmark server.
- Set up an inbound webhook to deliver the email as JSON data to our product.
Click the above links for the instructions to complete the steps.Parse the incoming Postmark webhook
Finally, we’ve reached our moment of glory. With the webhook URL setup, we now need to build a webhook on our end to process the incoming emails from Postmark.
At first glance, we might simply look at the “To” value of the incoming JSON payload to pull the generated email address that the message was sent to:
In this case, we’ve got what we need to update the issue assigned to the email@example.com email address.
However, there’s a big catch.
When creating new issues, some of our customers forward emails directly from their support address to the generated new issue address. For instance, instead of sending emails directly to firstname.lastname@example.org, emails are forwarded from, say, email@example.com to firstname.lastname@example.org. This way, users don’t have to remember a cryptic address when creating new issues.
Here’s the problem. When Postmark receives emails that are set up this way, the “To” address shows the original “To” email address instead of the address that we generated:
Fortunately, there’s a simple fix. Remember all the work we did to set up the catch-all routing? This is where it pays off.
Every email routed into Postmark from our catch-all address will contain a specific header named X-Gm-Original-To. This is what we configured in Step 3b, two sections above. The value of this email header will always be the generated email address, regardless of whether emails are sent directly to the address or are forwarded from another address.
Since we can always rely on the X-Gm-Original-To header, this is what we inspect to determine the true “To” address for all of our inbound emails. In our webhook code (written in C#), we can do something like this to pull the address from the deserialized Postmark JSON object:
var originalReplyToAddress = Headers.Single(h => h.Name == "X-Gm-Original-To").Value;
We can then pull the message body, attachments, and any other information out of the email to use as part of the issue creation or update.
I hope this tutorial helps you see the value in generated email addresses, and that in conjunction with Postmark and G Suite, you can use them to set up a system like the one we’ve set up at DoneDone for yourself.
Your IP represents the sending environment, typically a shared IP owned by your email service provider (ESP). Knowing the sending IP reputation gives insight into the reputation of your ESP, which directly influences connection-level blocks and sending delays. In other words, a poor IP reputation means more bounces and slower delivery.
When it comes to shared IPs, if an ESP accepts customers who are prone to spam complaints and excessive bounces, receivers will lower their opinion of the traffic coming from that IP. At the same time, being on a shared IP with many high-quality customers typically improves deliverability by buffering effects when an inevitable sending mistake happens. The performance of a shared IP pool is directly related to the ESP’s standard for their customers, so it’s a good sign when creating your account involves completing questionnaires and replying to support messages.
So how can you tell if your ESP is following best practices for your deliverability? First you need to see what IP your messages are sent over. Open any message sent from your ESP (not triggered through an ESP’s testing feature, since tests are sometimes sent over different IPs than live sends), and view the message headers. What those headers look like may vary based on who’s being sent to, but I find the simplest way to find the sending IP (especially in Gmail) is to look at the SPF authentication results:
In the raw, unformatted headers, you may see something like this:
Authentication-Results: spf=pass (sender IP is 18.104.22.168)
Received-SPF: pass (domain of example.com designates 22.214.171.124 as permitted sender)
For those sending over a shared pool (multiple IPs), open as many live messages as you can that were sent in the past week. Going back too far could yield inaccurate results, since some ESPs move customers to different IP pools periodically. Make note of the various IP addresses you see in those headers, and you’ll likely even notice a pattern that they’re all in the same range. For example, if I see that I’m sending over 126.96.36.199 and 188.8.131.52, I might get additional insight from checking the reputations of 50.31.156.[126-127].
If you use custom SPF/DKIM authentication and have signed up for Google Postmaster Tools (you should!), refer to the “IP reputation” visualization there to get a shortcut to both finding your sending IPs as well as understanding their reputation.
Of course there are also public IP check tools you can use to understand its reputation for multiple receivers. The most popular likely being ReturnPath’s Senderscore service, and you might need to create a free account there to see enough data. A SenderScore in the 90s is ideal, and anything lower (especially below the 80s) you’ll want to reach out to your ESP to investigate.
Another public service I like to use is Talos Intelligence by Cisco, looking for a grade there called “Email Reputation”. You may also get some insight from ReputationAuthority, although it tends to give a “neutral” reputation to most IPs (especially those where they’ve received little data). For both of these tools, it’s less informative to see a “good” or “neutral” grade which they tend to hand out to most IPs. Instead the most insight comes from whether the IP is less than “neutral”, meaning it definitely needs the attention of a deliverability professional or your ESP.
Beyond reputation, you may also want to know if the IP is currently on any blacklists. It’s good to note that these may not have any direct effect on reputation, simply because a receiver has to actually reference that specific blacklist for it to make any difference in deliverability. There are countless public blacklists because pretty much anyone with a computer can make one, so it helps to do some research first (or talk to your deliverability team) to know whether the blacklist is widely used and reputable. The quickest blacklist check for an IP is probably MultiRBL, but if you see a listing there, be sure to follow the link to blacklist’s website to check again directly (sometimes MultiRBL’s cache is inaccurate or delayed in marking de-listings).
Now that you’ve collected some data on your sending IP, what’s next? If you’ve found your IP to be in good standing everywhere, you’re working with a top-notch sending environment that will allow your own good sending habits to shine! Of course continue to re-check your IP reputation regularly in case there are any changes.
If you’ve found the IP to have some reputation issues, definitely reach out to your ESP to determine the work to be done to correct it. For dedicated IPs, they should be able to advise you on improving sending practices and help with reaching out to affected ISPs and blacklists. For shared IPs, they’ll need to launch their own investigation into any customers that may have caused the reputation drop. A responsive ESP to these kinds of issues is a clue whether this is a one-off situation or a common reputation problem that may require an email provider switch.