Taguchi authentication requires more than adding DNS records. An administrator adds the From domain, return-path component and DKIM selector in Settings → Domain, publishes the generated records, waits for Authorized, and asks Taguchi Support to complete Configured status. Then select the domain in the template theme and verify a real message. The intended branded DKIM signature must pass and align with the visible From domain. Taguchi sending-domain instructions.
What this guide covers
This is the Taguchi sending-domain workflow for email delivered through Taguchi's servers. It covers the return-path delegation, DKIM, DMARC and the campaign-theme dependency. It does not configure your employee mailboxes, an unrelated SMTP service, or SMS authentication.
Taguchi distinguishes sending domains from tracking domains. The latter support tracked links and related browser activity; setting one up does not complete email authentication. The Domain area requires administrator rights. Taguchi user guide, Domains.
Before beginning, identify the administrator, DNS owner, campaign owner and Taguchi support contact. Record the intended From domain, a dedicated return-path subdomain and the theme that will use them. Save the current DNS records and the currently working campaign configuration. Do not reuse a return-path owner already occupied by a website, another sender or an MX record.
1. Add the From domain, return path and selector
In Settings → Domain → Sending Domains, choose Add Sending Domain. Enter the domain used by the visible From address. Enter the return-path component, select the DKIM selector and save. For example, a From domain of news.example.com and component bounce produce bounce.news.example.com, not bounce.example.com. Taguchi configuration.
The selector options distinguish tagXXXX and dkimXXXX naming, and 1024- or 2048-bit RSA keys. Choose a supported 2048-bit option unless a documented compatibility constraint requires otherwise: the DKIM cryptographic update recommends RSA keys of at least 2048 bits. Selecting a familiar name does not authorize reusing another account's public key. Taguchi selector choices, DKIM key-size guidance.
After saving, capture the complete DNS Records column. Separate the return-path record from the DKIM record, including their full owner names, types and values.
2. Publish the generated records, not a generic recipe
The current official example shows a return-path CNAME to an account-specific hostname under mail.taguchimail.com, and a DKIM TXT record at the chosen selector. The public article also mentions clients.taguchimail.com. Use the actual DNS Records column for your domain rather than substituting either a generic hostname or the example account's target. Official Taguchi DNS example.
For a generated DKIM TXT record, publish the complete public value, including the complete p= key. Do not paste a hostname into a TXT value expecting it to behave like a CNAME. If your current account instead supplies a CNAME, follow that explicit record type and target. Never publish a private key or generate a replacement key independently of the signing service.
These owner examples assume the selected selector is tag2048; they are not account-issued values:
| From domain and DNS zone | Full owner | Relative host/name field |
|---|---|---|
example.com in zone example.com |
tag2048._domainkey.example.com |
tag2048._domainkey |
news.example.com in parent zone example.com |
tag2048._domainkey.news.example.com |
tag2048._domainkey.news |
news.example.com in delegated zone news.example.com |
tag2048._domainkey.news.example.com |
tag2048._domainkey in the child zone |
Return path for news.example.com, parent zone |
bounce.news.example.com |
bounce.news |
| Same return path, delegated child zone | bounce.news.example.com |
bounce |
If the editor requires full names, use the full owner instead. Inspect the final answer to catch an accidentally doubled domain suffix. Keep a return-path CNAME DNS-only where an HTTP proxy option exists. A CNAME cannot share its owner with incompatible TXT, A or MX records; choose a free name rather than deleting an unrelated service. DNS alias rules.
If _domainkey.news.example.com itself is delegated, the full tag2048._domainkey.news.example.com owner belongs there with relative name tag2048; in delegated _domainkey.example.com, the apex key tag2048._domainkey.example.com likewise uses tag2048. Substitute the actual selected selector, preserve NS authority and do not publish a non-authoritative parent copy. DNS zone delegation.
A long DKIM TXT answer can contain several quoted strings belonging to one record. That is different from publishing competing independent key records. Use your DNS host's long-TXT handling, preserve the full value and check the concatenated public key. Do not change the root MX records, other DKIM selectors or unrelated TXT records.
For the return-path CNAME, and a DKIM CNAME only if explicitly issued, require the exact literal CNAME/target at authoritative and recursive resolvers. Keep it DNS-only. On Cloudflare turn the record’s Flatten off where available and ensure whole-zone flattening does not hide the alias, coordinating shared changes with the DNS owner first. Apex CNAME flattening is automatic and same-zone targets flatten regardless of the setting. If mandatory behavior cannot preserve the required answer, stop and agree a supported configuration with the DNS host and Taguchi; do not invent a switch or remove delegation. Native DKIM TXT is not subject to these CNAME controls. Cloudflare verification and flattening behavior.
3. Complete support activation and select the right theme
Taguchi's documented states have different meanings:
| State | What remains |
|---|---|
| Pending | DNS authorization has not completed; compare the generated records with public DNS. |
| Authorized | DNS authorization completed, but Taguchi Support still needs to finish configuration. |
| Configured | The domain becomes available for selection in a template theme; actual campaign use still needs checking. |
Taguchi describes authorization occurring within 24 hours after record creation. If Pending persists, check record names, types and values before treating the delay as normal propagation. Once Authorized, contact Support for Configured status. Activation sequence and timing.
After activation, select the approved domain in the theme. For existing activities, re-apply an updated theme so its changes take effect, then review the activity's selected sender under deployment settings. Taguchi's user guide explicitly warns that theme changes need re-application. Preserve the activity first, and do not casually replace its layout: a layout change can overwrite content. Themes, activity selection and deployment settings.
A useful release check is to compare the intended theme with a harmless message produced by the actual activity. If DNS is correct but the activity still uses an old sender, more DNS editing will not correct the selection.
4. Understand SPF and return-path alignment
SPF evaluates the domain in SMTP MAIL FROM, typically reflected in the delivered message's Return-Path and smtp.mailfrom result. The visible From domain is a different identity. Taguchi's documented return-path subdomain therefore matters directly to SPF, not merely to branding. SPF identity rules.
For the documented delegation route, publish the return-path CNAME exactly as generated. Do not place an additional SPF TXT record at that CNAME owner. Verify the SPF data reachable through the delegation and the result seen for the actual envelope domain.
Taguchi's Activity Check documentation also contains guidance about including clients.taguchimail.com. Treat that as context for the specific reported check, not permission to overwrite the root SPF policy. Establish which owner the check evaluated and whether the account is using the generated custom-return-path route. If the current account instructions call for an SPF TXT change, merge only the required authorization into the one policy at that owner. Taguchi Activity Check SPF messages.
Preserve other legitimate senders and the intended final qualifier. Multiple SPF policies at one owner cause an error; the complete evaluated path must remain within ten DNS-lookup-causing terms, including nested includes and redirects. Do not flatten a managed include into a snapshot of IP addresses simply to silence a warning. SPF limits, repairing duplicate SPF records.
For a direct SPF edit, any all mechanism makes redirect= ignored regardless of position. Preserve legitimate authorization provided by an existing redirect and the approved policy ending through a reviewed design; do not append all blindly. This is not permission to add TXT beside the generated return-path CNAME. SPF precedence.
For an ordinary organizational domain example.com, From news.example.com and envelope bounce.news.example.com can align under relaxed SPF alignment. They do not match under strict aspf=s. A correctly signed d=news.example.com can supply exact DKIM alignment instead. Check the receiver's result and applicable policy, not just the visual resemblance of names. DMARC alignment.
5. Preserve DMARC and establish reporting
Do not replace an existing DMARC policy or publish a duplicate because a setup screen shows an example. Review the policy applicable to the actual From domain, including organizational-domain inheritance. A new explicit child policy can change the protection already inherited from its parent.
Only if no direct or applicable inherited policy exists and the domain owner approves an appropriate monitoring plan, begin a monitored rollout using an approved reporting mailbox. This is an illustrative record, not a recommendation to downgrade existing enforcement:
Owner: _dmarc.news.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
The relative owner is _dmarc.news in an example.com zone or _dmarc in a delegated news.example.com zone. For mail directly From example.com, use _dmarc.example.com instead, entered as _dmarc in a zone-relative editor for the example.com zone.
DMARC needs at least one authenticated and aligned SPF or DKIM identity. Relaxed alignment uses the applicable organizational-domain relationship; strict alignment requires identical domains. For this Taguchi implementation, require the intended branded DKIM signature to pass and align, even when SPF already makes DMARC pass. In particular, a domain publishing p=reject must not depend solely on SPF. DMARC deployment considerations.
p=none requests no DMARC enforcement. rua requests aggregate reporting, and a reporting destination outside the relevant organizational domain needs the required external authorization. Review reports by source, From domain, envelope domain and DKIM identity, not just an overall percentage. Missing reports do not prove the absence of traffic. Aggregate reporting and external authorization, missing-report investigation.
For report authorization, compare the destination host’s Organizational Domain with the Organizational Domain of the domain where the policy was found, not automatically the visible From domain. A different Organizational Domain requires the receiver generating reports to check DNS authorization; a destination within the same Organizational Domain is excepted. A different hostname alone is not external. Obtain separate owner approval for recipient, data sharing and retention. RFC 9990 section 4.
Before stronger policy, inventory all legitimate senders and indirect paths. Taguchi working correctly does not establish that payroll, employee mail, website notifications or forwarded messages are ready.
6. Validate public DNS and a real delivered message
Query the published records
The commands below illustrate news.example.com, return-path component bounce and selector tag2048. Replace them with the actual generated values. Replace the example nameserver with your authoritative server; these commands have not been run against a customer domain for this guide.
dig +short NS example.com
dig +short NS news.example.com
dig @ns1.dns-host.example bounce.news.example.com CNAME +noall +answer
dig @1.1.1.1 bounce.news.example.com CNAME +noall +answer
dig @1.1.1.1 bounce.news.example.com TXT +noall +answer
dig @1.1.1.1 tag2048._domainkey.news.example.com TXT +noall +answer
dig @1.1.1.1 _dmarc.news.example.com TXT +noall +answer
dig @1.1.1.1 _dmarc.example.com TXT +noall +answer
If the child is not separately delegated, use the parent zone's authoritative nameservers. Check both the authoritative and recursive answer for every generated owner, not just the return path shown above. For a DKIM CNAME route, inspect that CNAME and follow its target to the TXT key; for a TXT route, compare the entire published public key with Taguchi's instruction.
Expected observations are the exact return-path target, the correct DKIM public data at the selected owner, and one applicable valid DMARC policy. Distinguish missing records, wrong-zone publication, SERVFAIL and DNS timeouts. Cached answers may differ temporarily; authoritative errors need correction rather than waiting indefinitely.
Require the branded DKIM signature to pass and align
After Configured status and theme selection, have the authorized owner send a harmless campaign through the intended activity route to a controlled external mailbox. Inspect the original message and the authentication results added by the trusted receiver. Interpreting Authentication-Results.
Establish the actual receiving service’s known processing boundary from its documentation or mail administrator, including how externally supplied Authentication-Results are removed, ignored or distinguished from its own evaluation. Ignore attacker-supplied results; a matching authserv-id or header position alone is not proof. If provenance remains uncertain, leave acceptance open and obtain receiver-controlled diagnostics or an administrator-confirmed trace. Forged authentication results.
Keep a separate evidence row for each activity/theme and each materially different workflow:
| Evidence | What must be established |
|---|---|
| Visible From | Uses the approved domain rather than an old theme's sender. |
| SPF identity and result | smtp.mailfrom matches the intended envelope route; any real SPF failure/error has been investigated. |
| Branded DKIM | The intended d= has dkim=pass; its s= locates the expected public record; it aligns with From under adkim. |
| DMARC | Receiver reports dmarc=pass for the intended header.from; identify the aligned path. |
| Application state | The tested domain is Configured and the intended theme is applied to the activity. |
A provider-owned signature passing by itself is insufficient for the branded-DKIM acceptance check. A DMARC pass supplied solely by SPF also does not finish this DKIM setup. When multiple signatures are present, correlate each result with its own domain and selector using the DKIM selector investigation guide.
Record the timestamp and redacted raw-header evidence. Check a representative triggered workflow separately if you use one. A normal proof/test route may not establish the behavior of every live activity. Authentication success is necessary evidence, not an inbox-placement guarantee.
Troubleshooting Taguchi SPF and DKIM
| Problem | Diagnostic action |
|---|---|
| Domain stays Pending | Compare every generated record with authoritative DNS, including child-zone placement and doubled suffixes. If correct after the documented window, raise the exact evidence with Support. |
| Authorized but unavailable in a theme | Request Taguchi's Configured activation; do not repeatedly recreate working records. |
| Configured but wrong From or return path | Check the theme actually applied, re-application to existing activities and the activity's selected sender. |
| DKIM key exists, signature fails | Compare the message's d=/s= with the published owner and key. Investigate a wrong key, stale selector or content modification after signing. |
| Multiple SPF TXT records | Review and merge legitimate authorizations into one policy at the evaluated owner, not another temporary policy. |
| SPF DNS timeout | Check authoritative availability. Taguchi suggests retrying Activity Check after 30 minutes; persistent errors need the DNS administrator. |
| Invalid included domain or excess lookups | Inspect the dependency chain. Missing SPF at an include target and malformed syntax are different causes; count nested lookup-causing terms. |
| SPF discourages the sending host | Establish the actual sending IP and envelope owner; compare account instructions with the Activity Check's evaluated identity before adding an include. |
| SPF passes but is unaligned | Check relaxed versus strict alignment and the actual envelope domain. Require the intended aligned DKIM path. |
The provider documents the Activity Check warnings and retry interval in its troubleshooting table. An Activity Check not preventing broadcast does not mean a recipient will accept the mail. Investigate fail, softfail, neutral, none, permerror and temperror rather than dismissing all SPF problems because DKIM passed. Forwarding can change the SPF outcome; compare a direct delivery before changing sender authorization.
If a change introduces a regression, pause the affected activity, compare the saved configuration and undo only the approved affected change. Recheck DNS and send a new controlled sample. Preserve old DKIM verification records while queued mail may still need them, unless a security incident requires revocation.
Documentation and verification limits
No Taguchi account configuration, support activation, DNS mutation or test send was performed. Account-issued values, public DNS and actual recipient-side results remain implementation checks.