Learning to Send DMARC-Compliant Emails on Behalf of Others

Email authentication isn’t just about preventing spoofing - it’s about trust, says Vasile Diaconu, Operations Lead at DuoCircle. Every email your organization sends either builds trust or erodes it. SPF, DKIM, and DMARC are the foundation of that trust. Without them, receivers have no way to distinguish your legitimate email from an attacker’s.

DMARC (RFC 7489) ties SPF and DKIM together by requiring alignment between the envelope sender and the visible From header. According to Google’s February 2024 bulk sender requirements, a DMARC policy of at least p=none is now mandatory for any domain sending 5,000+ messages per day to Gmail users. DMARC Report

Learning to Send DMARC-Compliant Emails on Behalf of Others

					<button title="Play" aria-label="Play Episode" aria-pressed="false" class="play-btn">
						

Play Episode

					</button>
					<button title="Pause" aria-label="Pause Episode" aria-pressed="false" class="pause-btn hide">
						

Pause Episode

					</button>
					


				

				

					<audio preload="none" class="clip clip-12037">
						<source src="https://media.mailhop.org/dmarcreport/images/2024/03/Send-DMARC-Compliant-Emails-on-Behalf-of-Others.mp3">
					</audio>
					

						

					

					

						

							<button class="player-btn player-btn__volume" title="Mute/Unmute">
								

Mute/Unmute Episode

							</button>
							<button data-skip="-10" class="player-btn player-btn__rwd" title="Rewind 10 seconds">
								

Rewind 10 Seconds

							</button>
							<button data-speed="1" class="player-btn player-btn__speed" title="Playback Speed" aria-label="Playback Speed">1x</button>
							<button data-skip="30" class="player-btn player-btn__fwd" title="Fast Forward 30 seconds">
								

Fast Forward 30 seconds

							</button>
						

						

							<time class="ssp-timer">00:00</time>
							

/

							<!-- We need actual duration here from the server -->
							<time class="ssp-duration" datetime="PT0H2M18S">2:18</time>
						

					

				

			

								<nav class="player-panels-nav">
												<button class="subscribe-btn" id="subscribe-btn-12037" title="Subscribe">Subscribe</button>
																		<button class="share-btn" id="share-btn-12037" title="Share">Share</button>
										</nav>
						

	



		

						

				

					

					

				

				

					

																																																																								

					

						

RSS Feed

							<input value="https://dmarcreport.com/feed/podcast/dmarc-report" class="input-rss input-rss-12037" title="RSS Feed URL" readonly />
						

						<button class="copy-rss copy-rss-12037" title="Copy RSS Feed URL" aria-label="Copy RSS Feed URL"></button>
					

				

			

									

				

					

					

				

				

					

						Share						

					

						<a href="https://www.facebook.com/sharer/sharer.php?u=https://dmarcreport.com/blog/podcast/learning-to-send-dmarc-compliant-emails-on-behalf-of-others/&t=Learning to Send DMARC-Compliant Emails on Behalf of Others" target="blank" rel="noopener noreferrer" class="share-icon facebook" title="Share on Facebook">
							

						</a>
						<a href="https://twitter.com/intent/tweet?text=https://dmarcreport.com/blog/podcast/learning-to-send-dmarc-compliant-emails-on-behalf-of-others/&url=Learning to Send DMARC-Compliant Emails on Behalf of Others" target="blank" rel="noopener noreferrer" class="share-icon twitter" title="Share on Twitter">
							

						</a>
						<a href="https://media.mailhop.org/dmarcreport/images/2024/03/Send-DMARC-Compliant-Emails-on-Behalf-of-Others.mp3" target="blank" rel="noopener noreferrer" class="share-icon download" title="Download" download>
							

						</a>
					

				

				

					

						Link						

					

						<input value="https://dmarcreport.com/blog/podcast/learning-to-send-dmarc-compliant-emails-on-behalf-of-others/" class="input-link input-link-12037" title="Episode URL" readonly />
					

					<button class="copy-link copy-link-12037" title="Copy Episode URL" aria-label="Copy Episode URL" readonly=""></button>
				

				

					

						Embed						

					

/*! This file is auto-generated */ ’ title=“Embed Code” class=“input-embed input-embed-12037” readonly/>

					<button class="copy-embed copy-embed-12037" title="Copy Embed Code" aria-label="Copy Embed Code"></button>
				

			

				

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?

As of 2025, DMARC is mandatory under multiple compliance frameworks. CISA BOD 18-01 requires p=reject for US federal domains. PCI DSS v4.0 mandates DMARC for organizations processing payment card data as of March 2025. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and Microsoft began rejecting non-compliant email in May 2025. The UK NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

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-

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.

CNAMEs

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

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-

• Bounce handling doesn’t take place unless the relay forwards bounce back to you for management.

• The relay operator is responsible for email delivery, which means your customers now have access to your email service.

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-

• You will be managing user-level access to other email platforms as well.

• 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.

SPF

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:

• Bounced emails will be routed to your customer rather than you, leaving you with zero visibility into performance and delivery issues.

• 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.

DKIM

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

Its drawbacks are-

• There can be errors when cutting and pasting long strings of DKIM keys.

• 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

Customers

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

You

• 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.

Relaying

Customers

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

You

You have to handle email server features and bounce processing.

Manual Configuration

Customers

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

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!

Sources

• CISA Binding Operational Directive 18-01
• Microsoft Outlook DMARC Enforcement May 2025 (2025)
• PCI DSS v4.0 - DMARC Requirement (2025)
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)