Omfattning av arbetet till Gainsight NXT
Den här guiden täcker Gainsight NXTs arbetsflöde för e-posttjänster som beskrivs i dokumentationen för kundframgång. Återanvänd inte proceduren utan att kontrollera omfattningen för Gainsight PX, Community eller en annan produkt. Ett gemensamt företagsvarumärke etablerar inte en gemensam posttransport.
Spela in produktionshyresgästen, avsändardomän, synlig från-adress, Journey Orchestrator-program och DNS ägare innan du börjar. Fastställ om den aktuella transporten är SendGrid eller Mailgun . Gainsight dokumenterar båda och varnar för att byte av en befintlig organisations e-postleverantör kan förvränga e-postanalys. En transportväxel är inte ett rutinmässigt DNS felsökningssteg.
Målet är inte att ta bort en varumärkesetikett ensam. Det är för att koppla ett specifikt affärsmeddelande till en auktoriserad sändande identitet och bevara tillräckligt med bevis för att diagnostisera framtida misslyckanden. Se över befintlig användning av de föreslagna namnen och organisationens DMARC inriktning inställningar innan du begär nya poster.
Begär den konfiguration som stöds
Gainsights NXT-procedur börjar med Gainsight installerat och MDA aktiverat. Administratören förser Support med den begärda avsändardomänen och produktionshyresgäst-ID, som finns under Administration > Applikationsinställningar. Support returnerar relevant CNAME uppgifter. DNS teamet publicerar dem, sedan validerar support och drift domänen.
Använd den returnerade uppsättningen som en ändringsbegäran, inte som ett förslag för att kopiera värden från skärmdumpar. Bekräfta exakt hyresgäst, domän och leverantör med biljettägaren. Separera domänautentiseringsposter från varumärkesposter för e-postlänkar. Spårningslänkar kan vara operativt nödvändiga men en fungerande varumärkeslänk bevisar inte SPF, DKIM eller DMARC justering.
Före publicering, skriv en liten inventering för varje begärd post: fullständigt ägarens namn, typ, mål, syfte, befintlig användning och återställningsvärde. DNS gränssnitt skiljer sig åt i om de accepterar en relativ etikett eller ett fullständigt namn. Lös den skillnaden innan du sparar. Ändra inte en befintlig väljare som tillhör en annan avsändare bara för att det nya värdet visas i supportsvaret.
Uppfinn inte en SPF eller väljargenväg
NXT-källan beskriver SendGrid-hanterad SPF för dess automatiska säkerhetsrutt och tillåter förfrågningar om anpassade DKIM väljare på upp till tre tecken. Dessa fakta identifierar inte uppgifterna för varje hyresgäst eller för Mailgun . Få exakta värden genom den process som stöds i stället för att lägga till en generisk rot SPF -inkludering.
SPF utvärderas mot SMTP kuvertidentiteten. En ny rotdomänbehörighet kan vara irrelevant om tjänsten använder en annan avvisningsdomän. Omvänt kan en annan legitim avsändare ta bort en befintlig rotbehörighet. Behandla hela SPF policyn och dess beroenden som en separat förändring på domännivå när en sådan faktiskt är nödvändig. Flera SPF kandidater hos samma ägare är inte ett giltigt sätt att kombinera tjänster.
Väljarkollisioner förtjänar en tydlig lösning. Begär en lämplig väljare som stöds innan publicering och behåll den gamla tjänstens register tills dess användning har avslutats. Enbart DNS publicering bevisar inte att Gainsight har aktiverat den nya signeringskonfigurationen.
Verifiera supportöverlämningen och det riktiga programmet
Bekräfta först att auktoritativ DNS har de exakta returnerade CNAME:erna och att målen löser sig som avsett. Få sedan leverantörens valideringsresultat. En supportbekräftelse stänger installationsöverlämningen, men acceptans kräver också ett riktigt Journey Orchestrator-meddelande skickat till en auktoriserad testmottagare.
Gainsight rekommenderar att du undersöker ett testmeddelandes domän som skickats av e-post och dokumenterar gsemail- eller gsnemail-underdomäner i dess autentiseringskontroll. Behandla den displayen som en användbar ledtråd, inte ett fullständigt DMARC bevis. Bevara råmeddelandet och det betrodda mottagande systemets autentiseringsresultat. Fånga från, kuvertdomän, varje DKIM -signeringsdomän och väljare, och resultatet som är kopplat till varje identitet.
Syntetiskt diagnostiskt fall: Från-domänen är example.com , SPF passerar för gsemail.example.com och DKIM passerar för example.com . DKIM ger exakt justering. Under strikt SPF justering matchar underdomänen inte exakt example.com , även om den kan anpassas i avslappnat läge. Om ett senare prov använder ett leverantörsägt kuvert och saknar anpassad DKIM , visar inte ett allmänt SPF pass att det varumärkesbaserade meddelandet passerar DMARC .
Upprepa acceptans för varje materiellt distinkt arbetsflöde. Ett lyckat isolerat test från ett program bevisar inte att en annan konfigurerad avsändare, region eller transport använder samma identiteter. Inkludera företagsägaren i beslutet om vilka arbetsflöden som kräver separata prover.
Diagnostisera utan att byta leverantör i förtid
Om auktoritativ DNS är fel, fixa namn, typer eller värden och upprepa valideringen. Om DNS är korrekt men signering saknas, returnera den exakta hyresgästen och meddelandebeviset till supportägaren för aktivering eller ruttgranskning. Om autentiseringen är giltig men programmet säger Skickat utan en leveranshändelse, undersök händelsen och mottagningssystemet istället för att behandla Skickat som ett kvitto på inkorgen.
Försvaga inte en domänomfattande DMARC policy för att dölja ett misslyckat program. Pausa eller omdirigera det berörda arbetsflödet enligt ett godkänt återställningsbeslut. Bevara tidigare rekorduppsättningar och transportkonfigurationen före ändring. Håll kvar bevarade meddelandebevis åtkomstkontrollerade eftersom kundinnehåll och mottagaradresser kan finnas.
Fullständighets- och bevisgränser
Slutförande innebär en avstämd supportförfrågan, godkända DNS ändringar, leverantörsvalidering och observerad mottagarautentisering för det avsedda programmet. Registrera det distinkta tillståndet för varje steg. Detta manuskript använder aktuell bevarad förstapartsdokumentation och protokollresonemang; identitetsexemplet är syntetiskt. Ingen Gainsight-hyresgäst, supportärende, DNS ändring eller levererat meddelande nåddes eller kördes. En mänsklig ägare måste tillhandahålla och granska livebevisen innan den behandlar rutten som produktionsverifierad.
Jämför supportresultatet med det faktiska programmet
Skriftligt fall GS-01 förutsätter att supporten validerade den godkända example.com -konfigurationen, men ett andra Journey Orchestrator-program har inte samplats. Dess avsedda Från är success@example.com ; kuvertdomän, DKIM d=/s= och mottagarresultat är alla okända. En fungerande varumärkeslänk från det programmet kan inte fylla dessa luckor. Programägaren måste bekräfta sin avsändare och transport och sedan samla in ett auktoriserat kontrollerat meddelande innan utbyggnaden utökas. Byt inte SendGrid och Mailgun bara för att felsöka ett oobserverat resultat. Ingen biljett, klientinställning, meddelande eller DNS åtgärd utfördes.
Bevara verkställighetsgränsen
RFC 9989 Avsnitt 7.4 kräver giltig DKIM , inte enbart SPF , för domänpublicering p=reject, och varnar för interoperabilitet med indirekt e-post och e-postlistor. Ett enda framgångsrikt test för direktmeddelanden är inte ett bevis på att varje legitim väg är redo för en starkare politik. Behåll befintligt godkänt skydd medan du diagnostiserar det faktiska gapet; varje policyändring behöver ett eget beslut.