How do we send DMARC-compliant email on behalf of our customers?

Sending DMARC-compliant mail for customers

You need SPF or DKIM to authenticate as your customer's domain, aligned with whatever domain appears in the From header — not just permission to use their name. There are three workable patterns: a per-customer Return-Path subdomain your customer CNAMEs to your infrastructure, a CNAME-delegated DKIM selector so you sign with d=customer.com, or sending from your own domain with the customer only in the friendly-From and Reply-To. Putting the customer's bare domain in From without one of these breaks DMARC for every customer who enforces a policy.

This one is for platforms sending mail as their customers: an ESP, a helpdesk, a billing system, anything where the customer wants From: [email protected] and expects it to land reliably in inboxes that enforce DMARC.

Why the obvious approach fails

The obvious approach is: put the customer’s domain in the friendly From, send from your own infrastructure, and rely on your platform-wide SPF and DKIM setup. That setup authenticates your sending domain, not the customer’s. If the customer’s domain has any DMARC policy stronger than p=none, this fails outright — neither SPF nor DKIM aligns with a From domain your infrastructure has no relationship to. It doesn’t matter that the customer authorized you to send on their behalf; DMARC has no mechanism for expressing that authorization unless one of the patterns below is in place.

Pattern 1: a per-customer Return-Path subdomain

Have each customer add a CNAME from a subdomain they control to your bounce infrastructure:

bounce.customer.com.  CNAME  bounce.yourplatform.com.

You then send using bounce.customer.com as the envelope sender (RFC5321.MailFrom). Your platform’s SPF record, published on bounce.yourplatform.com, authorizes your sending IPs, and the CNAME lets that authorization apply to bounce.customer.com too. SPF now authenticates a subdomain of customer.com — which aligns (under relaxed mode, the default) with a From header of [email protected].

This fixes SPF alignment only, and on its own that makes the message depend entirely on SPF surviving every hop between you and the inbox. Any hop that breaks SPF — forwarding being the common one — then takes the whole message down with it, because there is no aligned DKIM signature left to fall back on. Pair it with Pattern 2 rather than relying on it alone.

Pattern 2: CNAME-delegated DKIM selectors

Have each customer publish a CNAME for a DKIM selector pointing at a key you control:

yourplatform._domainkey.customer.com.  CNAME  yourplatform._domainkey.yourplatform.com.

You sign outgoing mail with d=customer.com; s=yourplatform. The verifier looks up yourplatform._domainkey.customer.com, follows the CNAME to your published key, and validates the signature — against d=customer.com. That’s DKIM alignment achieved without the customer ever handling a private key, and without you needing per-customer keys beyond the selector name.

This is the more robust of the two mechanisms in practice, since DKIM survives forwarding and most in-transit modification that breaks SPF. Most established ESPs implement this pattern rather than relying on Return-Path subdomains alone.

Pattern 3: your own domain, customer in friendly-From and Reply-To

Send from a domain you fully control — [email protected] — and put the customer’s brand only in the display name and Reply-To:

From: "Customer Co. Billing" <[email protected]>
Reply-To: [email protected]

SPF and DKIM authenticate yourplatform.com, and the From header is yourplatform.com — everything aligns trivially, because there’s no cross-domain claim being made in the first place. The tradeoff is cosmetic: the visible sending address isn’t the customer’s domain, which some customers or their recipients will notice.

What ARC does and doesn’t solve

ARC (Authenticated Received Chain) preserves a record of the original authentication results through intermediaries that modify or forward messages — mailing lists, security gateways — so a receiver can consider “this passed SPF/DKIM/DMARC before that intermediary touched it.” It’s useful for forwarding through infrastructure you don’t control, where the original signals would otherwise be lost.

It does not solve the on-behalf-of-others problem described here. ARC doesn’t grant your domain permission to claim alignment with a customer’s domain — it only carries forward authentication results that already existed. If you never had SPF or DKIM alignment with the customer’s domain in the first place, ARC has nothing valid to preserve. The three patterns above are what create that alignment; ARC is a separate mechanism for a separate problem.

Checking your delegation

Use the DKIM Inspector against a customer domain and your chosen selector to confirm the CNAME resolves and the key parses correctly before relying on it in production.