SOBOO: How to send DMARC compliant email on behalf of others

Technical Help
1

Sending other people’s email in a DMARC compliant manner can be accomplished in a number of different ways. This article is intended for Email Service Providers (ESPs) and any business that sends email using their own customer’s domains (examples: CRMs, talent management companies, billing systems, etc).

dmarcian maintains the DMARC Operation Resource Center which includes a directory of email sources and if the sources can send DMARC compliant email. If so, notes are included on how to configure the source to get into compliance with DMARC.

This directory saves a lot of time, for a whole bunch of people:

  • Domain owners can immediately discover if their CRM/talent-management/billing-system is capable of sending DMARC compliant email, and if so, how to do it. No need to spend hours scraping through Internet archives, on the phone with support, or trying to piece together a solution based on partial information.
  • Email sources avoid support requests from people that want to know if DMARC is available.
  • Product managers at an email source can learn exactly what people are asking for when they request DMARC support. This clarifies requirements, speeds up implementation, and results in a shipped feature that makes happy customers.

This article walks through how to get authorized to send on behalf of a domain, what capabilities are required to send DMARC compliant email, potential changes to a customer onboarding process, and what to do after DMARC is in place.

How To Send Using a Customer’s Domain

DMARC compliant email is easy to identify and works by creating a link between a customer’s domain and a piece of email. We pushed a short video about how DMARC works here.

There are several ways to get associated with a customer’s domain so that DMARC compliant email can be sent on behalf of a customer. NOTE: DMARC allows you to send authenticated email using a sub-domain (such as email.company.com ), and still be able to use the top-level domain in the From: header (e.g. From: offers@company.com ).

The best approaches are listed first followed by less efficient approaches:

Domain Delegation

When a customer delegates a sub-domain for you to manage (such as email.company.com ), you’ll be able to send email that authenticates back to the sub-domain, and in most cases be allowed to send email using the top-level domain in the From: header (e.g. From: Best Offers <offers@company.com> ). Everything involved in sending DMARC compliant email is now managed on behalf of the customer, as you control and operate the entire sub-domain. There are two ways to implement sub-domain delegation:

Full Delegation

The customer delegates an entire sub-domain for you to manage. By doing this, you become responsible for the sub-domain and everything under it (including sub-domains of the sub-domain). Delegating the sub-domain is the only thing your customer has to do, making this a preferred approach.

CNAMEs

The customer creates several CNAMEs that point back to your own domain. This is effectively a form of delegation except individual services are delegated by each CNAME. This is like full delegation, except the customer has to initially create more DNS entries, making this a close runner-up to the preferred full delegation approach.

CNAMEs are commonly created for:

  • SPF & bounce handling . For example, a customer creates a CNAME that points from marketing.customer-domain.org to bounces.email-service-provider.com . The email sent on behalf of the customer uses a bounce address of @marketing.customer-domain.org . Not only is the corresponding SPF record managed by you (as it’s really the SPF record for bounces.email-service-provider.com ), but any bounces will be sent back to you instead of to your customer. (We published a short SPF Overview video here.)
  • DKIM . The customer can create multiple CNAME records once that point to your own published public keys, and you can use those CNAME records to add DKIM signatures to the email your send on behalf of the customer. Having multiple CNAMEs in place allows you to rotate DKIM keys without requiring the customer to do anything. (We published a short DKIM Overview video here.)
  • Mapping links with email to the customer’s domain . Instead of embedding links that point to your own domain, you can add links into your customer’s email that use your customer’s domain. When someone clicks a link in the email, the CNAME resolves back to your own services for tracking, etc.

Relaying

Relaying is sometimes an option if only a small amount of email is being sent on behalf of the customer. Allowing a customer to configure their email to be relayed through a different email server is one way to get DMARC compliance into place… if the relay itself is capable of sending DMARC compliant email.

Two ways to allow this:

SMTP Relay

Allow customers to configure an SMTP relay for all of the email you’re sending on their behalf. (We have a short video overview video on SMTP, but it does not cover relaying.) Whoever manages the relay then becomes responsible for DMARC compliance. Drawbacks:

  • Bounce handling goes away unless the relay is able to forward bounces back to you for handling.
  • Email delivery becomes the responsibility of the relay operator, meaning your email service now depends on something operated by your customer.

Configure User Credentials

Allow customers to configure user credentials. This requires the customer to provision an account for your service, and then configure your service to use the new user’s credentials. You would then send any email as if you were the user. Drawbacks:

  • You have to manage user-level access to a multitude of email platforms, as your own customer could be using Gmail, Yahoo, Microsoft, Lotus, Exchange, etc.
  • You’re using your customers resources to send email on behalf of the customer.

Manual Configuration

Instead of operating a delegated sub-domain (or using CNAMEs), you can ask customers to configure their domain so that you can send DMARC compliant email:

SPF

You can ask your customer to add your own netblocks into the customer’s SPF record. This is common thing to ask for, but is often done for the wrong reason. Doing so will allow you to send authorized email on behalf of the customer but only if the customer’s domain is used in the bounce address of email you send . Drawbacks:

  • Bounced messages will be routed to your customer instead of back to you. You’ll have zero visibility into issues that impact your performance as an email sender, and your customer will get a bad user experience.
  • Your customer has to think of you while maintaining their SPF record. This is annoying for your customers that have to manage a bunch of other senders that have asked to be included in their SPF record for the wrong reasons.

DKIM

You can have customers add DKIM related keys into their domain. Drawbacks:

  • Your customer has to cut and paste big strings into their domain management software. Errors often occur in doing so, annoying users and yourself.
  • You cannot rotate DKIM keys without asking your customer to perform a task. This is tedious at best. At worst, a DKIM key has to be rotated due to an emergency (during a holiday!), and this is the likely the worst possible customer interaction: “Your key is being used to send fraudulent email. Can you drop everything right now to help us fix this?”

We’ll add more approaches as we discover them. Feel free to let us know if you’ve uncovered a new way that is worth sharing.

Required Capabilities

As described above, sending DMARC compliant email on behalf of your own customers can be accomplished through a variety of approaches. Each approach ends up being a tradeoff in capability between “easy for me” vs “easy for my customer”. As there is a fixed amount of configuration and operational work to perform, you can:

  • Do this work on behalf of your customer,
  • split the work between yourself and your customer, or
  • have your customer do the work.

Regardless of the approach, there is always some amount of work involved to allow you to send on behalf of your customer:

Sub-domain Delegation

Customer

One time domain configuration to implement sub-domain/CNAMEs.

You

  • Operation of domain system to handle/verify/monitor sub-domain delegation/CNAMEs.
  • Email server features to use customer’s sub-domain in bounce address and in DKIM signatures.
  • Maintenance of SPF record.

Relaying

Customer

  • Customer must bring their own relay resource.
  • One time configuration to add relay information to your system.

You

  • Email server features to use customer’s relay and – if you’re serious about sending email – to deal with bounce processing. Since pretty much every email server supports the ability to relay email, the work here involves exposing this functionality to customers to take advantage of.

Manual Configuration

Customer

  • One time domain configuration to add SPF records and DKIM signing keys.
  • Additional configuration if SPF records need to be updated or DKIM signing keys need to be replaced.

You

  • Email server features to use customer’s domain in bounce address and in DKIM signatures.
  • Maintenance of SPF record, and making sure customers update their SPF record when you change your infrastructure around. This is either easy if your customers include: your infrastructure via SPF, or hard if you have customers add things like ip4: into their SPF records.

The astute reader will note that some changes have to be made regardless of which approach is taken. Email server features are required in all cases.

There is a great deal of common “required capability” between the non-relay approaches, with the main differences involving different ways the customer can configure their domain to allow you to send on their behalf. Based on this insight, it is well worth making it easy for your customers if you’re already committed to sending email on their behalf.

Onboarding of Customers

The 1st approach (sub-domain delegation) is efficient from the perspective of minimizing how much a customer must implement before you’re able to send DMARC compliant email on their behalf.

The 2nd approach (relaying) essentially offloads the sending of DMARC compliant email onto your customer. This approach might be preferred if you send very little email on behalf of your customers and the investment required to send DMARC compliant email doesn’t add up.

The 3rd approach (manual configuration) requires the same amount of customer implementation as the sub-domain delegation approach, except more specific changes are required to get started.

Additionally, the 3rd approach can be considered brittle: changes in your own infrastructure might require your customer to make corresponding domain configuration changes. Coordinating this type of change can be cumbersome, expensive, and prone to errors.

Sending Email on Behalf of Customers

Sending DMARC compliant email provides a lot of benefit for yourself and your customer, and goes a long way to making your email easy to identify. If you’re interested in sending best-in-class email (or even just email that gets delivered!), consider going the extra mile and using your customer’s domain in everything related to an email:

  • Email links can appear to be from your customer’s domain, but when someone clicks on a link, it can be serviced by your own infrastructure.
  • Same for images and other objects: they appear to come from your customer’s domain, but are served up by your own infrastructure.
  • Server names related to the delivery of email can be changed to reflect your customer’s domain.

The above changes are possible if the sub-domain approach is used. Doing so makes the email you send on behalf of your customers incredibly easy to identify and deliver.

If you’re interested in being listed on the directory of email sources, contact us at support@dmarcian.com.

If you have questions/comments, feel free to comment below or drop us a line at support@dmarcian.com