Set up DMARC and see who's sending email using your brand's domain.
x

How do I send email on behalf of my customers?

If you work for a web agency, operate a helpdesk/CRM service, or run an online marketplace or platform, chances are you need to send emails on behalf of your partners and customers. And when that’s the case, the right setup will help you:

  • Preserve your customers’ brand reputation 
  • Make the emails sent on their behalf appear trustworthy and official
  • Protect deliverability 
  • Manage each customer’s emails (and the associated risks) efficiently 
  • Deliver a great service 

There are three options for sending email on behalf of your customers, and each one has its own benefits and drawbacks. You can:

  1. Use your own authenticated domain. This is the least effort but least customer-branded approach, in which you send from your domain directly on behalf of your customers. You can change the “From” name, but the email address will use your domain.
  2. Verify your customer’s entire domain through domain verification. This is the most recommended choice as it ensures your emails are delivered and prioritizes secure email sending. Even though it requires a slightly longer implementation effort, the ensured deliverability will have longer-lasting positive effects and adoption by most email service providers. A verified domain = the best VIP access to the email world you could ask for! 
  3. Use a verified "From" email address from your customer's domain to send from that specific email address. This is less secure than verifying your domain and if you are verifying more than 1-2 Sender Signatures, this can become cumbersome to manage. While this is an essential part of setting up your Postmark account, we highly recommend pairing it with Step 2 as your best path to domain verification overall.

This chart shows how an example app called plumbercrm.com could use each method and how this would look for each option as it relates to from name, from address, and reply-to address for your recipients.

If your product or agency sends email on behalf of customers, like the imaginary CRM for plumbers from our chart, how do you choose which method is right for you? It really depends on the type and volume of email you’ll be sending, and on your customer’s expectations for those messages.

When you login to Postmark, you’ll see a menu item called “Sender Signatures” and when you select it you’ll see an option to “Add a new signature or domain.” Click here and you’ll be given two choices, verify a domain or an email address with what we call a Sender Signature.

Add domain

Option 1: Sending from your domain#

This is the fastest way to send for your customers because they don’t need to take any action outside of your app to send email. Another big advantage to this method is your customers don’t have to worry about setting up DKIM, Return Path, or DMARC. You can manage all of those email authentication protocols for them.

You can change the From name and ReplyTo address in your code when sending with SMTP. There are a variety of ways to accomplish this in your code, but the main thing to remember is you need to set this information in the header for SMTP messages.

If you are sending with the Postmark API you can set the From and ReplyTo for each message. You can see what you’d need to update with the example values sender@example.com and reply@example.com below:

{  "From": "sender@example.com",  "To": "receiver@example.com",  "Cc": "copied@example.com",  "Bcc": "blank-copied@example.com",  "Subject": "Test",  "Tag": "Invitation",  "HtmlBody": "<b>Hello</b>",  "TextBody": "Hello",  "ReplyTo": "reply@example.com",  "Headers": [    {      "Name": "CUSTOM-HEADER",      "Value": "value"    }  ],  "TrackOpens": true }

This isn’t the best method if your customers want to send email from their own domain, so if that’s a concern for your customers then you should consider one of the following methods.

Option 2: Verifying an email address in the Postmark interface#

Verifying an email address is a really great if your customers need to send from their own domain and you don’t want to ask them to update their DNS records. To send with this method, Postmark needs to know the email address your customers will be using. We’ll send them an email with a link they need to click to verify their email address. One place you can manage this setting is in the Postmark interface.

After you select ‘Add Sender Signature’ from the Sender Signatures page, fill in the full name and email address you want to use. Remember, this email address will need to be setup and accepting email so you or your customer can verify it by following a link in the next step.

The Personal note is a field to provide context to the recipient of what the confirmation email is for. This field is helpful if you're sending on behalf of a customer that might not know you're using Postmark for email, and is available via our API or UI when adding a Sender Signature.

Select Create Signature and your customer will receive a confirmation email from Postmark to verify their email address. This message will look like the one pictured here, and your customers will need select Confirm Sender Signature to verify their email address.

Option 3: Verifying a domain in the Postmark interface#

This option takes a bit more time for your customers to set up to get started, but it’s worth it. They can build on their domain’s email reputation and will be able to send from any address on their domain. To get started your customers will need to add a DKIM record to the DNS for their domain.

If you choose to verify a domain, Postmark will ask you to enter the domain you’d like to verify. Then on the next page, you’ll get a DKIM key to add to the DNS for the domain you’re verifying. Your customers will need to add this value to their DNS. Like everything related to DNS, it can take some time for these records to propagate. Standard practice says to give them up to 48 hours to show up, but it normally doesn’t take that long.

DKIM record

Postmark Pro Tip #1: Verify an email address or domain with the Postmark API#

Like I mentioned earlier, if you’re sending on behalf of a ton of customers you probably don’t want to have to manually add each domain or sender signature to your domain. This is where the Postmark API can do some of the heavy lifting for you!

You’ll need to use the Postmark API to create a Sender Signature to verify an individual email address or a domain. The first thing you need to know is an email address your customers want to verify. Remember, your customers can’t verify email addresses from free email providers like Gmail with Postmark.

Once you have your customers email address, send that email address to our Create Sender Signature endpoint, and the user will get an email from Postmark asking them to click to verify their email address. You should let your customers know an email will be coming from Postmark and they can confirm their email address in that message.

If you’re new to Postmark’s API you can see how a call to create a sender signature works with the Postmark API Explorer. You’ll need an account token to see the create a sender signature endpoint in action. Paste in your account token, fill in the values for FromEmail, Name, and ReplyToEmail, and try it out.

Here’s an example of the response I got from Postmark’s API when creating a Sender Signature using my account:

{  "Domain": "example.com",  "EmailAddress": "john.doe@example.com",  "ReplyToEmailAddress": "reply@example.com",  "Name": "John Doe",  "Confirmed": false,  "SPFVerified": false,  "SPFHost": "example.com",  "SPFTextValue": "v=spf1 a mx include:spf.mtasv.net ~all",  "DKIMVerified": false,  "WeakDKIM": false,  "DKIMHost": "",  "DKIMTextValue": "",  "DKIMPendingHost": "20140220130148.pm._domainkey.example.com",  "DKIMPendingTextValue": "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCQ35xZciGB0g...",  "DKIMRevokedHost": "",  "DKIMRevokedTextValue": "",  "SafeToRemoveRevokedKeyFromDNS": false,  "DKIMUpdateStatus": "Pending",  "ReturnPathDomain": "pmbounces.wildbit.com",  "ReturnPathDomainVerified": true,  "ReturnPathDomainCNAMEValue": "pm.mtasv.net",  "ID": 1,  "ConfirmationPersonalNote": "This is an optional note visible to the recipient in the Sender Signature Confirmation email to provide context of what Postmark is." }

Using our Domains API, you can add a Domain to your Postmark account and get back the information you need to verify it. The API response when creating a Domain only slightly differs from the response you get when creating a Sender Signature using the API:

{  "Name": "newdomain.com",  "SPFVerified": false,  "SPFHost": "newdomain.com",  "SPFTextValue": "v=spf1 a mx include:spf.mtasv.net ~all",  "DKIMVerified": false,  "WeakDKIM": false,  "DKIMHost": "",  "DKIMTextValue": "",  "DKIMPendingHost": "20131031155228.pm._domainkey.newdomain.com",  "DKIMPendingTextValue": "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCFn...",  "DKIMRevokedHost": "",  "DKIMRevokedTextValue": "",  "SafeToRemoveRevokedKeyFromDNS": false,  "DKIMUpdateStatus": "Pending",  "ReturnPathDomain": "pmbounces.newdomain.com",  "ReturnPathDomainVerified": false,  "ReturnPathDomainCNAMEValue": "pm.mtasv.net",  "ID": 36736 }

When you create a Domain using the API, the values DKIMPendingHost and DKIMPendingTextValue are also created (same as when you add a Sender Signature using the API). Your customers will need to add this DKIM record to their DNS records using the DKIMPendingHost (for the TXT record’s host) and DKIMPendingTextValue (for the TXT record’s value) returned for the added Domain.

Once Postmark sees these DKIM values in the DNS records, your customer will be able to send from any email address on their domain.

Postmark Pro Tip #2: Use Servers and Streams to separate messages#

After you’ve determined your domain and branding approach, we recommend using Servers (which act like folders) and Streams (which help you separate different types of mail) to organize each customer’s sending activities within your account. 

Within each Server, you can have up to 30 Streams for transactional, inbound, and broadcast mail. For example: 

Server A - Client 1

  • Message Stream A - Receipts - Transactional
  • Message Stream B - Feature Updates - Broadcasts

Server B - Client 2

  • Message Stream A - Internal Alerts - Transactional 
  • Message Stream B - Terms of Service Updates - Broadcasts
  • Message Stream C - Booking Confirmations - Inbound 

Separating mail with Servers and streams helps you:

  • Isolate reputation issues: If there is an issue with Client 2, Stream B, sending can be paused on that specific Stream while allowing all other messages to continue flowing.
  • Manage risks like spam complaints, bounces, bots and form abuse, from affecting other customers/clients on your account. 
  • Report on unique stats for each customer/client (sent, bounces, complaints, opens, clicks, etc.)
  • Maintain separate unsubscribes and suppressions for each Stream

Use the Servers API to programmatically manage creating new servers.

For more tips review our guide: Best practices for sending on behalf you customers.

Last updated August 8th, 2023

Still need some help?

Our customer success team has your back!