White label email sending domains: SPF, DKIM and DMARC alignment

A white label email sending domain means your product sends the mail, but the From address belongs to your customer. Their invoices and notifications arrive from billing@theirbrand.com, not from an address on your platform. Making that land in an inbox comes down to three record types on the customer's domain (SPF, DKIM and DMARC) and one idea that ties them together: alignment.

We make CustomDomain™, a product of EverJust Company in Minneapolis. We are not an email sending service, and this post is on our blog, so weigh it accordingly. The records below are what a customer's DNS needs for any sender, whether you run your own mail servers or use a provider. The wider white label picture is in our white label domain guide; this post stays on the mail side.

Why the customer's domain, or a subdomain of it

A receiving server compares the domain in the visible From address with the domains that actually authenticated the message. If you send as noreply@yourplatform.com, authentication is easy, but the customer's brand never appears. If the From address is billing@theirbrand.com, the message has to authenticate as theirbrand.com, or as something DMARC treats as the same domain. Hence the records in the customer's zone.

A common choice is a subdomain such as mail.theirbrand.com instead of the root. That keeps your records away from whatever the customer already runs on the root for their own staff mail. Whether the subdomain counts as aligned is what the next section decides.

What alignment means

Passing SPF or DKIM is not enough for DMARC. The domain that passed has to line up with the From domain. RFC 9989 defines two modes. Under relaxed alignment (section 3.2.10.1) the two domains need the same Organizational Domain. Under strict alignment (section 3.2.10.2) they must match exactly.

The rule that matters most for a platform is in section 5.3.5 of the same RFC: DMARC passes if SPF aligns or DKIM aligns. One is enough, so you can pick whichever is easier to get a customer through and make that one reliable.

Take a message with From billing@theirbrand.com. Signed with a DKIM key published under theirbrand.com, DKIM aligns in both modes. Signed under mail.theirbrand.com, it aligns in relaxed mode but not strict. Signed only under yourplatform.com, DKIM can pass without aligning at all, and DMARC then depends on SPF. That last case is the one that bites. The sender's dashboard shows authenticated mail, and DMARC still fails.

SPF: one record, ten lookups

SPF is a TXT record on a domain listing which servers may send for it. It is checked against the envelope sender (the MAIL FROM address), which recipients never see, not the From header. Two rules from RFC 7208 cause most of the grief.

First, a name must not have more than one SPF record (section 3.2: "MUST NOT have multiple records"). If a customer already has an SPF record for their office mail and your onboarding tells them to add another, they now have two. The fix is one merged record, which means someone edits an existing value instead of adding a new one. Putting your sender on a subdomain with its own record avoids most of this.

Second, evaluating a record may trigger at most 10 DNS lookups, a MUST in section 4.6.4. Every include: counts, so a customer who has stacked a few providers can be near the limit before you add yours. The same section says implementations SHOULD limit "void lookups", which are lookups that return nothing, to two. We have not verified how strictly individual receivers enforce either limit.

SPF alignment needs a MAIL FROM on the customer's domain

SPF only helps DMARC if the MAIL FROM domain aligns with the From domain. Amazon SES documents how it handles this: with a custom MAIL FROM domain you publish an MX record and an SPF TXT record for it, because the domain in the From address must match the MAIL FROM domain for SPF alignment. The details are in the SES custom MAIL FROM documentation. We have read only the SES version for this post, so check your own sender's documentation.

DKIM: selectors and the 255-byte string

DKIM signs each message with a private key and publishes the matching public key in DNS. RFC 6376 (section 3.6.2.1) stores that key as a TXT record in a subdomain named _domainkey, so the full name is selector._domainkey.theirbrand.com. The selector is a label, so a domain can publish several keys side by side, and yours can sit beside the customer's other mail provider's key.

RFC 8301 says rsa-sha1 must not be used for signing or verifying (section 3.1) and sets a minimum RSA key size of 1024 bits (section 3.2).

The practical trap is TXT string length. A single string holds 255 data bytes; RFC 1035 section 3.3 describes it as up to 256 characters including the length octet. A 2048-bit public key encodes to roughly 410 characters, which is our own arithmetic and not a figure from the RFC, so it cannot fit in one string. RFC 6376 section 3.6.2.2 says the strings in a TXT record must be concatenated, so the key goes in as two strings and a verifier reads them back as one. We would expect failures when a customer pastes the full value into an editor that does not split it, but we have not tested how any particular DNS provider's editor behaves. Check before you promise customers a paste-and-go flow.

The CNAME alternative

Some senders sidestep the length problem with CNAME records that point at keys the sender hosts. Amazon SES Easy DKIM uses three CNAME records, per the SES identity documentation. We have not verified how other providers do it.

Record, location, and what breaks

What changed with the new DMARC RFC

The original DMARC specification, RFC 7489, was published as Informational in March 2015. In May 2026 it was obsoleted by RFC 9989 (DMARCbis), a Proposed Standard, together with RFC 9990 and RFC 9991 on reporting. We have confirmed the month and no more precise date.

We have not catalogued every difference between the two documents and will not guess at them. This post relies only on the alignment definitions and the either-or pass rule, both read from RFC 9989. If older internal documentation cites RFC 7489, update the citation before you hand it to customers.

What Google and Yahoo require

Google's sender guidelines define a bulk sender as one sending close to 5,000 messages or more within a 24-hour period. Bulk senders need SPF, DKIM and DMARC, and a DMARC policy of p=none is allowed. The From domain must align with either the SPF domain or the DKIM domain, the same either-or rule as above. Messages need one-click unsubscribe, and the spam rate must stay below 0.10% and never reach 0.30% or higher.

On dates, Yahoo's sender guidance says its enforcement began in February 2024, and Google's FAQ dates stricter enforcement to November 2025. We have not verified what changed on either date beyond what those pages say, or how Google counts mail sent for many customers through one platform.

A workable setup for a platform

From the sources above, the least fragile arrangement we can describe is this. Have the customer delegate a sending subdomain instead of editing root records. Sign with DKIM under the customer's domain so DKIM aligns. Add a custom MAIL FROM on the same subdomain so SPF can align too, if your sender supports one. Publish a DMARC record, starting at p=none if the customer is nervous. Then send a real message to a mailbox you control and read the authentication results, rather than trusting a green tick in a dashboard.

If you are chasing a similar problem on the web side, our posts on which hostname each customer should use and on branded link domains follow the same subdomain logic. Our white label domain not working page covers hostnames that fail, and the how it works page describes the widget. This post does not claim the widget writes email records for you. For the rest of the picture, go back to the pillar guide.