Scope and preparation
This guide covers Taguchi sending-domain setup. It is a documentary procedure, not a report of a live tenant test. Obtain an administrator, DNS access and a campaign owner. Save the existing records and decide which From domain the campaign is authorized to use. Reserve a separate return-path name that does not already carry another service.
Configure the sending domain
In Settings > Domain, add the From domain and return-path component, choose a selector, then save. Publish the CNAME and TXT entries generated in the DNS Records column, using your own configuration rather than the examples in the documentation. Taguchi distinguishes Pending, Authorized and Configured. After DNS authorization, support must complete configuration; then select the domain in the template theme. The provider describes a 24-hour authorization window. Check record accuracy before escalating a persistent Pending state. See the Taguchi setup source below.
Original campaign acceptance design
Prepare two harmless versions of the same campaign: one before changing its theme and one after. Record theme, From domain, envelope domain, each signing domain and trusted receiver outcomes for both. This isolates a configuration change that exists in DNS but is not yet used by the campaign. Do not interpret an Authorized label as evidence that the campaign has switched.
For a fictional From domain notices.example.org, an envelope under bounce.notices.example.org illustrates why relaxed SPF alignment and strict SPF alignment may differ. These are teaching identities, not Taguchi-issued values or observed results. Test the selected alignment mode explicitly and prefer evidence from the actual message over assumptions about a dashboard label. The acceptance design below has no observed-result rows; it is guidance rather than an attached measurement worksheet.
Prove the identity at the receiver
Use a controlled external mailbox and send through the production workflow, with harmless content and no customer data. Save the raw message, timestamp and the receiving system's Authentication-Results. Ignore authentication assertions inserted by an untrusted sender. Record the visible From domain, Return-Path or authenticated envelope identity, and every DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identity.
SPF pass authorizes the connecting server for the evaluated envelope identity. DKIM pass validates a signature for its signing domain. DMARC needs a passing method whose domain aligns with the visible From: strict alignment requires the same domain; relaxed alignment permits the applicable organizational-domain relationship. A provider-owned signature can pass without authenticating your visible From. One passing aligned DKIM signature can satisfy DMARC even when another signature fails. These protocol rules come from RFC 7208, RFC 6376 and RFC 9989, listed below.
Check authoritative DNS before diagnosing caches. Ask an authoritative server for the exact name and type, then compare a recursive resolver after its cached lifetime. For DKIM, follow any CNAME to its public-key TXT response. Never publish a private key. Keep one SPF policy at each evaluated name and check the ten DNS-lookup-causing-term limit across nested includes. Do not replace a shared SPF policy with a provider example.
Recovery and acceptance
Pause the affected workflow if tests show a new regression. Compare the changed record with the saved version and undo only that change after checking other senders. Recheck DNS and resend after recovery; reverting a value does not flush every resolver immediately. Keep old DKIM verification records available while previously signed messages may still be in transit, unless a security incident requires revocation.
Accept the change only when DNS, application state and a real received message agree. Record the flow owner, evidence timestamp and next review trigger. Inbox placement alone is not proof of authentication, and successful authentication does not guarantee inbox placement. Do not tighten a shared domain's DMARC policy on the strength of one provider's test. Inventory the other legitimate sources first.
Use a state ledger before the campaign release
Written case TG-01 assumes the new domain is notices.example.org, the chosen return-path component is bounce, and the selector is the actual account-issued value, not supplied in this example. DNS authorization is stipulated complete, but status is Authorized rather than Configured, and the campaign theme still selects the old domain. The support owner must complete provider activation, then the campaign owner selects the approved domain in the theme and performs a controlled test. Until then, actual From, envelope and DKIM results for the changed campaign are unknown. Do not mark it ready from DNS alone. No support request, template edit, DNS query or campaign send occurred.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.