Scope the work to Gainsight NXT
This guide covers the Gainsight NXT email-service workflow described in its Customer Success documentation. Do not reuse the procedure without checking scope for Gainsight PX, Community or a different product. A common corporate brand does not establish a common mail transport.
Record the production tenant, sender domain, visible From address, Journey Orchestrator program and DNS owner before beginning. Establish whether the current transport is SendGrid or Mailgun. Gainsight documents both and warns that switching an existing organization's email provider can skew Email Analytics. A transport switch is not a routine DNS troubleshooting step.
The objective is not to remove a branding label alone. It is to connect a specific business message to an authorized sending identity and preserve enough evidence to diagnose future failures. Review existing use of the proposed names and the organization's DMARC alignment settings before requesting new records.
Request the supported configuration
Gainsight's NXT procedure starts with Gainsight installed and MDA enabled. The administrator supplies Support with the requested sender domain and the production Tenant ID, found under Administration > Application Settings. Support returns the relevant CNAME records. The DNS team publishes them, then Support and Operations validate the domain.
Use that returned set as a change request, not as a suggestion to copy values from screenshots. Confirm the exact tenant, domain and provider with the ticket owner. Separate domain authentication records from branded email-link records. Tracking links can be operationally necessary but a working branded link does not prove SPF, DKIM or DMARC alignment.
Before publication, write a small inventory for each requested record: complete owner name, type, target, purpose, existing use and recovery value. DNS interfaces differ in whether they accept a relative label or a complete name. Resolve that difference before saving. Do not change an existing selector that belongs to another sender merely because the new value appears in the support response.
Do not invent an SPF or selector shortcut
The NXT source describes SendGrid-managed SPF for its automated-security route and allows requests for custom DKIM selectors of up to three characters. Those facts do not identify the records for every tenant or for Mailgun. Obtain exact values through the supported process rather than adding a generic root SPF include.
SPF is evaluated against the SMTP envelope identity. A new root-domain permission may be irrelevant if the service uses a different bounce domain. Conversely, deleting an existing root permission could break another legitimate sender. Treat the whole SPF policy and its dependencies as a separate domain-level change when one is actually necessary. Multiple candidate SPF policies at the same owner are not a valid way to combine services.
Selector collisions deserve an explicit resolution. Request an appropriate supported selector before publication, and keep the old service's records until its use has ended. DNS publication alone does not prove that Gainsight has activated the new signing configuration.
Verify the support handoff and real program
First confirm authoritative DNS has the exact returned CNAMEs and that targets resolve as intended. Then obtain the provider's validation outcome. A support confirmation closes the setup handoff, but acceptance also needs a real Journey Orchestrator message sent to an authorized test recipient.
Gainsight recommends examining a test message's mailed-by domain and documents gsemail or gsnemail subdomains in its authentication check. Treat that display as a useful clue, not a full DMARC proof. Preserve the raw message and the trusted receiving system's authentication results. Capture From, envelope domain, every DKIM signing domain and selector, and the result associated with each identity.
Synthetic diagnostic case: the From domain is example.com, SPF passes for gsemail.example.com, and DKIM passes for example.com. DKIM provides exact alignment. Under strict SPF alignment the subdomain does not exactly match example.com, although it can align in relaxed mode. If a later sample uses a provider-owned envelope and lacks aligned DKIM, a general SPF pass does not demonstrate that the branded message passes DMARC.
Repeat acceptance for each materially distinct workflow. A successful isolated test from one program does not prove another configured sender, region or transport uses the same identities. Include the business owner in deciding which workflows require separate samples.
Diagnose without changing providers prematurely
If authoritative DNS is wrong, fix names, types or values and repeat validation. If DNS is correct but signing is absent, return the exact tenant and message evidence to the support owner for activation or route review. If authentication is valid but the application says Sent without a delivery event, investigate the event and receiving system rather than treating Sent as proof of inbox receipt.
Do not weaken a domain-wide DMARC policy to conceal one failing program. Pause or reroute the affected workflow under an approved recovery decision. Preserve previous record sets and the pre-change transport configuration. Keep retained message evidence access-controlled because customer content and recipient addresses may be present.
Completion and evidence limits
Completion means a reconciled support request, approved DNS changes, provider validation and observed receiver authentication for the intended program. Record the distinct state of each step. This manuscript uses current retained first-party documentation and protocol reasoning; the identity example is synthetic. No Gainsight tenant, support ticket, DNS change or delivered message was accessed or executed. A human owner must supply and review the live evidence before treating the route as production-verified.
Compare the support outcome with the actual program
Written case GS-01 assumes Support validated the approved example.com configuration, but a second Journey Orchestrator program has not been sampled. Its intended From is success@example.com; envelope domain, DKIM d=/s= and receiver results are all unknown. A working branded link from that program cannot fill those gaps. The program owner must confirm its sender and transport, then collect an authorized controlled message before expanding the rollout. Do not switch SendGrid and Mailgun just to troubleshoot an unobserved result. No ticket, tenant setting, message or DNS operation was executed.
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.