Best practices for sending on behalf of your users

In many cases, you may want to send emails on behalf of your customers. For instance, if you run help desk software but want to use Postmark to power your emails, you can set up all of the necessary authentication for your domain, vendordomain.com, but your customers would most likely rather their customers see their brand, customerdomain.com, instead of yours.

Sending on behalf of your users webinar

Watch a recording of our webinar covering everything you need to know about sending on behalf of your users.

Watch the Recording 30 minutes

When sending on behalf of your customers, you have several options that vary in both technical complexity and effort. In this guide, we’ll explore the pros and cons of each of these approaches at a high level, and then we’ll dive in to show you how a hypothetical help desk company could use Postmark to implement each of the sending tactics. The API endpoints and requests will vary from one ESP to the next, but the interface and concepts should stay the same.

Options for sending on behalf of your customers #

Before we dive in, here’s a quick overview of the pros and cons of each option for sending on behalf of your customers through Postmark.

Option 1: Fully-aligned Authenticated Customer Domain #

In an ideal world, any sending on behalf of your customers would use a customer domain with fully-aligned authentication. This includes DKIM and SPF/return-path. However, your customers won’t always be comfortable modifying DNS, or, in some cases, they may not be able to add entries to their company’s DNS. The other challenge with this approach is that it requires either significant development to handle on your end or significant manual intervention to set up authentication for each customer domain. While authenticating domains can’t guarantee delivery, it does maximize your customers’ opportunity for reliable delivery.

Option 2: Verified “From” Email Address #

When your customer can’t fully authenticate their domain for sending with your service, you can still send from their email address. However, without the authentication, some email clients like Gmail and Outlook will display “via” or “on behalf of” tags in conjunction with the sending address. Also, while Postmark offers this option, it’s not something that’s available from all email providers.

With this process, you still want to verify that your customer controls the “From” address that you’ll be using. In order to do this, you need to use a verification process to send an email to the address and have the user either follow a link or use a one-time code sent to that email address to verify ownership. With Postmark, this is built-in. Postmark will send a verification email to the address with a link for the recipient to click to confirm ownership. 

Option 3: Custom “From” Name #

The final option is the simplest both in terms of implementation effort on your part and configuration effort on the part of your customer. You can send the emails from your own domain and simply specify a different “From” name when you send the email. You could also potentially set up unique email addresses for each customer. For example, you might use Jane Customer <info@vendordomain.com> or you could use Jane Customer <customer@vendordomain.com> or even Jane Customer <customer@customer.vendordomain.com>. For your customer, they only need to provide the sender name.

One catch to be aware of with with this approach is that some email clients will aggressively add new contacts to address book, and someone may unintentionally be added to an address book with the wrong email address associated with their name. One solution is update the name to say “Jane Customer via (vendor)” so that it’s clear it’s not the sender’s primary email address.

A comparison of 3 options for sending on behalf of your customers.
Each option has distinct advantages and disadvantages on the spectrums of both effort and customer branding.

What should the process look like? #

Let’s look at how the process of setting up sending should work for your customers and also address ways that the process can educate them to make the best decisions for their situation. What can you do if your customer isn’t familiar with DNS or isn’t comfortable making changes to their company’s DNS settings? There’s a lot of room to make mistakes, so let’s break it down into an approachable process.

One thing you’ll notice in common with all of the options is that you’ll want to create a server for each customer in Postmark. This allows you to organize stats and mail streams on a per-customer basis. Not all ESPs provide the concept of servers, but you can think of them as primarily organizational concepts so your various customers’ emails aren’t inter-mingled. It’s entirely optional, but it comes in handy.

You can offer your customers all three options, or you can limit the options. In each case, you’ll want to provide some guidance on the pros and cons of why they would or wouldn’t want to use a given option.

Option 1: Fully-aligned Authenticated Customer Domain #

Having your customer authenticate their domain so you can send emails with their domain is a great solution, but it’s also the most technically complex to implement for both you and your customers. It also requires that they have the ability to make DNS changes. 

A process flow diagram representing how you might design the functionality to enable customers to send from their own domain.
While the most complex to build and configure, this is the best overall process for customers who went to send from their own domain.
  1. When you create a new domain in Postmark, Postmark returns the relevant information for authenticating the domain in the response. You can then present this information to your customers.
  2. You’ll want to provide some sort of verification mechanism so your customers can verify that they’ve successfully configured their DNS entries correctly.
  3. Send instructions to a teammate.
  4. Let people change their minds. While this option sounds great in theory, once a customer sees what’s involved, they may change their mind and prefer to go another route. Make sure to provide them a way to back up and go a different route.
  5. With Postmark, you can optionally use the API to create a separate server to keep each customer’s stream of email separate from your other customers.

To get an idea of what’s involved presenting DNS configuration instructions guidance to your customers, you can visit the “Sender Signatures” section of your Postmark account and add a new domain.

Option 2: Verified “From” Email Address #

A verified “From” address isn’t the most seamless experience, but it’s vastly simpler to set up. It only requires that your customer has the ability to check emails at their desired sending address. Then, when you use the Postmark API to create the Sender Signature for that address, Postmark will automatically send a verification email to that address.

A process flow diagram representing how you might design the functionality to enable customers to send from their own email address using Postmark.
Without authenticating customer domains, the workflow is a little simpler, but your customers' emails will display Via tags in Gmail.
  1. The verification email and confirmation page currently come from Postmark, and while that can’t be changed, we are exploring options for removing the Postmark branding and replacing it with your own.
  2. Since the verification emails come from Postmark, you’ll want to address that and set expectations with your customers so they expect the email and complete the verification process.
  3. You may also want to provide the ability to resend verifications. Postmark’s API provides an option for doing this.
  4. With Postmark, you can optionally use the API to create a separate server to keep each customer’s stream of email separate from your other customers.

A word on sending using a customer’s domain without authentication

If you’re sending emails on behalf of your customers and using their domain, the best approach is having them set up DKIM, SPF, and return-paths to in order to both authenticate and verify ownership of their domain. Since it’s not always easy or possible for customers to make changes to their company’s DNS, you may consider sending from a customer’s domain without authentication. While this is possible, it does have some drawbacks.

This approach ensures that they own and should be allowed to send email from the verified email address, but that’s all it does. Sending on behalf of users without fully-aligned authentication for the sending domain can lead to situations with some email clients and services showing the from address as being sent “on behalf of” or “via” the email provider. In order to ensure that the authentication is fully aligned, the authenticated domain needs to match the From address domain. 

A screenshot of examples where "via" tags are displayed with the from name.
Without authenticating to send using your customers' domains, via tags like above will be displayed in Gmail.

Without fully-aligned authentication, emails may look unprofessional at best, or, untrustworthy at worst. Ideally, in order to send on behalf of your customers, you’ll want to go a step beyond simply verifying domain ownership and get into authentication for their custom domain by encouraging them to set up DKIM and SPF/return-paths. 

Option 3: Custom “From” Name #

This is the simplest and most convenient method for everyone, but it also means your customers won’t be using their own domain. It’s a great option to start with in your first version because it will always be relevant. Remember that when someone signs up for your service to try it out, they may not be comfortable immediately setting up DNS authentication. Giving them a quick and easy way to test it out before they’re fully-committed can really help make your service more approachable.

A process flow diagram representing how you might design the functionality to enable customers to send from your domain with a custom display name.
Simply changing the display name requires the least effort, but the underlying email address will still use your domain rather than your customers' domain.
  1. In some cases where recipients are on a controlled domain, for internal applications for example, you may be able to have your customers email their recipients and explain that they’ll be receiving emails from your service/domain.
  2. You can suggest a variety of formats for the sending name that may be more recognizable to recipients. For instance “(Vendor Name) for Jane Doe” or “Jane Doe via (Vendor Name)” could both be options so that your customer can use their name but make it clear that the email is originating from your service.
  3. With Postmark, you can optionally use the API to create a separate server to keep each customer’s stream of email separate from your other customers.

What’s the best option for your scenario? #

The answer of course, is, it depends on your priorities. Each of these options has significantly different benefits. If giving your customer control over their brand is of the utmost importance, you might want to focus on fully-aligned authentication for your customers’ domains. However, if your customers tend to be less technical, providing a simpler process with fewer steps is likely the right move. There are quite a few variables to consider. 

One important thing to remember is that you can always start simple and expand your options over time. For version one, you may just offer a single option and then wait to see what your customers are most interested in. You’ll have to weigh your options and choose the one that feels best for your goals.

This post was originally published Apr 26, 2018

Still have questions?

  • Ashley Harpp Ashley
  • Dana Chaby Dana

Ask us anything! We’re eager to help you with any problem or question you have…