DMARC emails

Learning to Send DMARC-Compliant Emails on Behalf of Others

DMARCReport podcast
DMARC Report
Learning to Send DMARC-Compliant Emails on Behalf of Others

This guide is intended for email service providers and businesses involved in sending emails using their own customer’s domains for marketing, PR, billing, talent management, etc. 

Sending DMARC-compliant emails is beneficial for both parties, significantly optimizing email identification. If you aim to get the best of the best email delivery and visibility, consider the following practices-

  • Ensure email links appear to originate from your customer’s domain while still being serviceable by your own infrastructure.
  • Modify server names associated with email delivery to align with your customer’s domain.
  • Ensure images and other objects appear to originate from your customer’s domain while still being serviceable by your infrastructure.

There are a few ways that allow you to send DMARC-compliant emails on behalf of others so that legitimate conversations don’t get marked as spam or bounce back.  

How to Send an Email Using  Your Customer’s Domain?

Domain Delegation

When your customer delegates a subdomain for your part of the job, you can send emails from that, and they will be authenticated back to the subdomain. So, in such a case, you will have the control to manage the subdomain on behalf of your customer

There are two ways to implement subdomain delegation-

SMTP relay

Full Delegation

You get an entire subdomain delegated to you, making you responsible for the subdomain and everything associated with it. In this scenario, your customer only has to delegate a subdomain to you, and you have to take care of the rest; probably that’s why it’s the most preferred approach


The customer creates multiple CNAMEs pointing back to your own domain, and individual services are delegated by each CNAME. The only factor that makes it different from full delegation is that the customer has to create more DNS entries in the beginning. 

You will notice that CNAMEs are usually created for SPF and bounce handling, DKIM, and mapping links in an email to the customer’s domain.


Relaying is a preferred approach when only a few emails have to be sent on behalf of the customer. This is done by letting customers configure emails to be relayed through a different email server. This can be done in two ways-

SMTP Relay

For this, you simply have to allow your customer to set up an SMTP relay for all the emails you send on their behalf. In this case, whoever manages the relay will also be responsible for DMARC compliance

Its drawbacks are-

  1. Bounce handling doesn’t take place unless the relay forwards bounce back to you for management.
  2. The relay operator is responsible for email delivery, which means your customers now have access to your email service.
email bounce

Image sourced from

User Credential Configuration

Let your customers configure user credentials. They must provide you with an account for your service. After this, they must configure your services so that you can use the new user’s credentials to send emails as if you were the user

Its drawbacks are-

  1. You will be managing user-level access to other email platforms as well.
  2. You have to use your customer’s resource to send an email on their behalf.

Manual Configuration

If you want to ditch the delegation approach, then the process can be done manually, too. 


Ask your customer to add your netblocks to their SPF record. However, ensure the customer’s domain is used in the bounce address of emails you sent.

Its drawbacks are:

  1. Bounced emails will be routed to your customer rather than you, leaving you with zero visibility into performance and delivery issues.
  2. Your customers always have to consider the impact on your work whenever they have to make some changes to their SPF record. And if they have multiple third-party senders, it becomes more challenging for them.


Just ask your customer to add your DKIM-related keys to their domain.

Its drawbacks are-

  1. There can be errors when cutting and pasting long strings of DKIM keys.
  2. It can be burdensome and annoying for customers when DKIM keys have to be rotated, as the process requires some action from their sides.

Required Capabilities

Some of the approaches shared above will be easier for you and some for the customers. Since there is a certain amount of configuration and operational work to perform, you can take responsibility on behalf of your customers, split the work between both parties or have the customers take care of everything.

Here’s how the responsibilities will be split between you and your customers in the above-shared approaches-

Subdomain Delegation


They just have to perform single-time domain configuration to implement subdomains or CNAMEs.

email delivery


  • Managing the domain system, involving overseeing, validating, and monitoring subdomain delegation and CNAMEs.
  • Utilizing email server functionalities to incorporate the customer’s subdomain in bounce addresses and DKIM signatures.
  • Regular upkeep of SPF records.



They have to provide their relay source and perform a one-time configuration to add relay details to your system.


You have to handle email server features and bounce processing

Manual Configuration


Customers will be taking care of the one-time domain configuration process to add SPF records and DKIM signing keys.

Apart from this, they are responsible for additional configurations if SPF records have to be updated or DKIM keys need to be rotated or replaced.


You will manage email server functions for adding the customer’s domain to bounce addresses and DKIM signatures. You also have to regularly maintain SPF records while ensuring the customer updates their SPF records when infrastructure changes happen. This process can vary in complexity depending on whether customers include your infrastructure via SPF or manually add elements like ip4: to their records. Regardless of the approach taken, email server features are necessary in all scenarios.

However, there is an overlap in the required capabilities among non-relay approaches, with differences specifically lying in the way customers set their domains to authorize sending emails on their behalf. Therefore, we emphasize that you prioritize making this easier for customers, especially if you are committed to sending emails on their behalf.

If all this sounds like a complicated deal for you, our team of email security experts can make things simpler for you. Click here to book yourself a demo!

Similar Posts