Gainsight SPF, DKIM and DMARC setup, step by step

Direct answer: For Gainsight NXT, request sending-domain authentication from Gainsight Support with your intended sender domain and production tenant ID. Publish the exact CNAME records Support generates, confirm publication back to Support, and wait for Gainsight Operations to validate the domain. Then inspect a real Journey Orchestrator message for SPF, DKIM and DMARC alignment. Do not substitute a generic SendGrid include or copy another tenant's DKIM targets. Gainsight NXT Email Service Configuration

This is a configuration guide, not evidence that a tenant, DNS zone or delivered message has been tested.

Contents

• Scope: NXT email service, not every Gainsight product
• Prerequisites and support request
• Publish the CNAMEs Gainsight generates
• SPF: understand managed authorization and the actual envelope
• DMARC: preserve the domain policy and prove alignment
• Check DNS, then obtain the Operations result
• Test a real Journey Orchestrator message
• Troubleshooting without unnecessary provider changes
• SendGrid-to-Mailgun migration is a distinct change
• Frequently asked questions
• Review scope

Scope: NXT email service, not every Gainsight product

The primary source is explicitly for Gainsight NXT. This guide covers its support-assisted sender-domain authentication and Journey Orchestrator verification. Do not reuse its records or navigation for Gainsight PX, Customer Communities, Customer Education, an inbound Email-to-Timeline address, or a mailbox integration merely because the products share a brand.

The NXT guide identifies SendGrid as the default and recommended email service provider for CS tenants and documents Mailgun as another option. It distinguishes domain authentication from email-link branding. Branded tracking links do not establish SPF or DKIM alignment by themselves. NXT route and feature distinctions

This public source does not establish universal plan, regional or custom SMTP entitlements for every NXT contract. Ask Support to confirm the route actually provisioned. In particular, do not invent a customer-managed SMTP configuration screen or apply standalone SendGrid/Mailgun account instructions to a managed Gainsight tenant.

If a separate corporate mailbox service sends other mail, use its own instructions, such as the Microsoft 365 authentication guide. Those tenant controls do not replace Gainsight Support-generated NXT records.

Prerequisites and support request

Gainsight's documented prerequisites are an installed NXT environment with Matrix Data Architecture enabled and involvement from Gainsight Support. Find the production tenant ID under Administration > Application Settings. Your IT team also needs authority over the relevant DNS zone. Prerequisites and tenant ID

Prepare the following information for the support request, sharing only what is needed through your approved support channel:

• Intended sender domain or subdomain and production tenant ID.
• Current email provider for the tenant, if known, and whether the request changes it.
• Existing selector or CNAME-owner conflicts, plus security requirements for strict alignment.
• A request for every exact DNS owner, type and target, identifying authentication versus link-branding records.
• Expected envelope domain and DKIM signing domain, verification handoff, and cutover/rollback requirements.

Only sender domain and production tenant ID are listed as required generation inputs in the official guide. The additional questions above are an implementation checklist, not extra vendor-mandated fields. Do not include passwords, API keys or private signing keys in DNS or a diagnostic ticket.

Before publication, export the current DNS records and TTLs. Inventory other senders using the same domain. Identify a change owner and a rollback window. A new sender authentication request does not authorize deleting selectors used by another platform or changing the organization-wide DMARC policy.

Publish the CNAMEs Gainsight generates

Support returns domain and email-link records for the tenant. Use that response as the source of truth, not the example image in the public guide. The documented process is:

1. Obtain the generated records for the intended production tenant and domain.
2. Have IT publish the exact records in authoritative DNS.
3. Tell the Gainsight representative that publication is complete.
4. Have Gainsight Operations perform domain validation.
5. Resolve any failed checks jointly with Support and IT before relying on the configuration.

Gainsight support and Operations handoff

If the DNS editor appends your zone name, enter the relative owner portion it expects and verify the final fully qualified name. A DNS-only CNAME must remain a DNS alias; do not route it through a web proxy or flatten it into an address response. Cloudflare CNAME verification guidance A CNAME cannot coexist with other data at the same owner. If an owner is occupied, stop and request a supported alternative; do not erase an unrelated A, MX, TXT or CNAME record to force the setup.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits. For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Can I use custom DKIM selectors?

The NXT source says Gainsight uses gs and gs2 for SendGrid, rather than the standalone provider's usual s1 and s2, and permits requests for custom selectors up to three characters. These names are contextual clues, not values to hard-code. Ask Support for a conflict-free generated set and publish the exact response, including its targets. Do not rename a selector locally: the sending service must sign with the matching selector. NXT selector FAQ

SPF: understand managed authorization and the actual envelope

The NXT FAQ says SendGrid manages SPF under automated security and that this does not consume a lookup in your own SPF policy. That statement applies to the documented managed configuration; it does not mean SPF has no DNS lookups or that every possible Gainsight/Mailgun route is identical. Confirm the envelope domain from the actual message and Support's configuration. Automated security FAQ

SPF authenticates the SMTP MAIL FROM domain, often represented by the delivered Return-Path. It does not directly authenticate the visible From address. Do not automatically add include:sendgrid.net or a guessed Mailgun include to your corporate root domain. The proper managed CNAME workflow may already delegate the necessary envelope-domain authorization.

If Support explicitly requires an SPF TXT change for your confirmed route, reconcile it with the existing policy at that exact owner. Maintain one v=spf1 policy, preserve legitimate senders and the terminal policy, and evaluate the ten-term DNS-querying limit across nested includes and redirects. It is not a limit of ten vendors. A second SPF policy can produce a permanent error even when each record looks plausible by itself. SPF, RFC 7208

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

DMARC: preserve the domain policy and prove alignment

Gainsight's NXT article says it cannot set up DMARC for a bulk sender; the domain owner must publish and maintain the policy. Retain an existing policy, including quarantine or reject. Do not replace it with the vendor's p=none example. Where no policy exists, IT can approve a monitored initial policy after reviewing all legitimate senders. Gainsight DMARC responsibility

First inspect the direct TXT policy at _dmarc.YOUR-FROM-DOMAIN and any applicable inherited policy. Only absent both, with owner-approved monitoring, an illustrative first TXT value is v=DMARC1; p=none. It requests no reports unless an authorized monitored rua destination is added. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

A DMARC pass requires either SPF authentication plus alignment or DKIM authentication plus alignment with the visible From domain. Relaxed alignment permits an organizational-domain match; strict aspf=s and adkim=s require exact domain matches for their mechanisms. A subdomain envelope may align under relaxed SPF but not strict SPF. p=reject does not by itself require strict alignment. Do not weaken policy to accommodate the wrong sending route. DMARC, RFC 9989

Current DMARC guidance is RFC 9989, which supersedes the older base specification and makes pct obsolete. Plan any enforcement change around known senders and evidence, not a promised percentage rollout. Use aggregate reports under RFC 9990, with approved destinations and external-destination authorization where required. Failure reporting under RFC 9991 can reveal message information and merits separate privacy review. Aggregate reporting, failure reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Check DNS, then obtain the Operations result

The following are read-only query shapes, not actual Gainsight records. Replace every uppercase placeholder with the exact Support-provided owner or target before running them:

dig +short CNAME GENERATED-OWNER.example.com
dig +short CNAME GENERATED-SELECTOR._domainkey.example.com
dig +short TXT GENERATED-DKIM-TARGET.example.net
dig +short TXT _dmarc.example.com

Inspect all aliases through to their final published data. A CNAME lookup returning the expected destination shows delegation, not that the destination necessarily holds a valid current DKIM key. For managed SPF, inspect the actual envelope domain and its authorization chain. Compare authoritative responses with a recursive resolver if caching is suspected.

Success at this stage means every supplied record is public, exact and conflict-free, and Gainsight Operations has confirmed its validation. The public NXT guide does not give a universal propagation deadline; use your TTLs and Support's timing rather than inventing a fixed 24/48/72-hour guarantee. Preserve the support case and verification result for the tenant's change record.

Test a real Journey Orchestrator message

Gainsight explicitly recommends a test email from a Journey Orchestrator program. Its quick check looks for a mailed-by subdomain such as gsemail or gsnemail under your domain; if absent, it tells users to contact Support. Those patterns are diagnostic hints, not universal DNS templates or sufficient proof of DMARC. NXT sender-authentication test

For acceptance, use an authorized controlled recipient and inspect original headers. Trust Authentication-Results added by that receiving service, not arbitrary upstream headers. Capture the following:

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Accept the route only with the intended visible From, a trusted receiver DMARC pass and the expected branded DKIM signature passing and aligning; an SPF-only DMARC pass does not complete DKIM setup. Investigate SPF fail, permerror and temperror independently even if aligned DKIM carries DMARC.

At the actual observed envelope domain, diagnose SPF authorization fail or softfail separately from transient evaluation temperror (often DNS) and invalid-policy, duplicate-policy or lookup-budget permerror. Investigate each even when aligned DKIM supplies DMARC; do not add authorization at an unrelated apex to conceal the error. SPF result definitions.

Illustrative example: A From domain of example.com and an SPF-authenticated envelope under gsemail.example.com can meet relaxed alignment, but not strict SPF alignment. An aligned passing DKIM signature can independently satisfy DMARC. Check the real policy and signature rather than assuming that mailed-by or SPF pass alone is enough.

Repeat the check for materially different programs, From domains or message routes. A single verified program does not certify all NXT notifications, other Gainsight products, or future ESP migrations. Use EmailAuth aggregate reporting to monitor changes in this stream while retaining the receiver evidence that explains the initial acceptance decision.

Troubleshooting without unnecessary provider changes

Gainsight documents delayed/asynchronous bounces and cases where Sent does not establish actual delivery. It also describes bounce deny lists and unsubscribe handling. Do not resend indiscriminately or bypass suppression controls to test authentication. NXT delivery diagnostics

SendGrid-to-Mailgun migration is a distinct change

The NXT guide documents provider switching from release 6.42, with a warning that existing email analytics may be skewed and future engagement is processed by the chosen provider. Coordinate such a migration with Gainsight and IT, obtain the new record set, and repeat DNS and real-message acceptance. Keep old authentication records for queued mail and dependent routes until Support confirms retirement is safe. Do not switch providers simply because one CNAME was entered incorrectly. ESP switch warning

Review scope

No customer account configuration, DNS changes or real-message tests were performed. Validate the account-specific records and delivered-message evidence before treating your configuration as complete. Authentication does not guarantee delivery or inbox placement.