Separate authentication for marketing and transactional subdomains

Transactional marketing subdomain authentication is best handled as a bounded evidence problem, not a guess based on one dashboard label. Stream-specific subdomains is the useful starting point: collect the exact identity, record, header, or SMTP exchange involved, then compare it with what the receiver actually evaluated.

The short answer

Include a stream inventory and alignment test; make clear that subdomain separation does not itself guarantee placement. The safe workflow is to inventory the current state, test the real sending path, make one reversible change, and verify the result with fresh evidence. This page focuses on that task rather than repeating a general SPF, DKIM, or DMARC introduction.

Decision table

Practical workflow

1. Define the question in terms of stream-specific subdomains. Write down the sending stream, domain or selector, provider, owner, and time window. If the question came from a dashboard, keep the raw message, DNS answer, SMTP reply, or report that supports it.
2. Collect evidence before editing configuration: test each stream’s identities and policy inheritance. Compare authoritative and recursive DNS where relevant, and compare a real received message with the configured values. A single local lookup or vendor status page is not a complete test.
3. Make the smallest controlled change that addresses the observed failure. Preserve the prior value, approval, exact diff, and rollback owner. Keep SPF, DKIM, DMARC, DNS, transport, and placement observations in separate fields so one pass does not mask another failure.
4. Re-test the same path and at least one representative edge case. Interpret the result conservatively: subdomain separation does not guarantee placement. Record what remains unknown, who owns the next check, and when the configuration should be reviewed again.

Edge cases and limits

The most important boundary is this: Subdomain separation does not guarantee placement. Resolver caches, forwarding, multiple sending streams, provider-specific processing, and delayed messages can make two apparently similar tests disagree. Label an outcome as observed, inferred, or unknown. Do not turn an unmeasured demand signal or one successful test into a guarantee about delivery, placement, or receiver behavior.

RepMail relevance

For a RepMail sending stream, use the same evidence discipline before changing domain authentication: preserve the raw header or DNS answer, identify the stream owner, and keep a rollback record. The email authentication hub provides the broader map; the links below are the closest task-specific references.

Further reading

Email Infrastructure Explained · Authentication Multiple Sending Services · What Is Dmarc

Diagnostic worksheet: keep the streams separate

Marketing and transactional mail can share an organizational domain without sharing the same operational identity. Treat each subdomain as a separate authentication boundary until the evidence proves otherwise. Start with a row for every real stream, not every vendor contract.

For each row, save the raw received headers, the authoritative DNS answer, the recursive answer from the relevant resolver, and the timestamp. DMARC evaluates the visible From domain against an authenticated SPF identifier or a valid DKIM signature; an SPF pass for a different envelope domain is not, by itself, an aligned DMARC pass. Compare the exact domains rather than assuming that a common parent makes every stream equivalent. The DMARC alignment explanation and read-authentication-results guide are useful adjacent checks.

A practical stop condition is an incomplete row. Do not move a marketing stream to a transactional subdomain, or publish a parent-domain record as a substitute, while the sending service, envelope domain, or DKIM d= value is unknown. Also stop if the same subdomain has more than one SPF TXT record, if a vendor asks for a CNAME that conflicts with an existing host, or if the received message still shows the old identity after the stated DNS and message-cache window. A provider dashboard saying “verified” is evidence about that provider's check, not proof that every receiver will evaluate the message identically.

Controlled change and rollback

Before changing a record, export the current RRset and record the DNS owner name, type, TTL, exact value, change ticket, approver, and rollback owner. Change one stream at a time. Send a representative marketing message and a representative transactional message through their normal paths; do not use a test path that bypasses the production signing or envelope configuration. Verify the raw Authentication-Results fields, the DKIM signature's d= domain, SPF's evaluated smtp.mailfrom, and the DMARC result at the receiving mailbox.

Rollback when the intended stream loses a valid SPF or DKIM result, when DMARC alignment fails on a known-good path, when the wrong stream signs with the subdomain, or when a provider's verification change would break an unrelated stream. Restore the saved RRset and sender configuration, then stop further edits until the original evidence is reproduced. RepMail can help organize the sending task and evidence; it does not change your registrar, DNS answers, provider verification, or receiver policy on your behalf. Re-run the email authentication hub and authentication rollback plan after the incident.

References

1. RFC 7489 — DMARC
2. Google Workspace Admin Help — sender authentication