Omfattning och förutsättningar
Denna procedur är för den anpassade domänrutten för recensioner och lojalitet som beskrivs i Yotpos CNAME autentiseringsguide. Det är inte ett påstående att varje Yotpo-produkt, inklusive SMS och e-post, använder samma inställning. Den dokumenterade rutten använder SendGrid bakom Yotpo och kräver domänspecifika poster som tillhandahålls av support. Låt ägaren av recensioner eller lojalitet bekräfta den exakta domänen som visas i produktens e-postinställningar innan du begär uppgifter.
Konfigurera den dokumenterade rutten
- Steg 1. Registrera produkten, kontot, avsedd synlig från domänen och befintligt DNS ägande. Identifiera alla andra program som redan använder SendGrid för den domänen.
- Steg 2. Begär domänens CNAME uppsättning från Yotpo Reviews Support eller Yotpo Loyalty Support. Ange den exakta domänen för e-postinställningar och avslöja en befintlig SendGrid integration så att support kan tillhandahålla en icke-konfliktstruktur.
- Steg 3. Kopiera alla tillhandahållna värdar och mål till den auktoritativa DNS zonen. Yotpos illustration inkluderar ett kuvertrelaterat CNAME och två DKIM CNAMEs, men dess värd- och värdesträngar är unika per domän. Illustrationen är inte en konfiguration för ditt konto.
- Steg 4. Bevara posttyper. Ersätt inte en begärd CNAME med en TXT post eller skriv över en väljare delegeras till en annan avsändare. Hos en CNAME ägare måste motstridiga vanliga poster lösas innan den nya delegeringen publiceras.
- Steg 5. Be Yotpo-supporten att validera de publicerade posterna och slutföra aktiveringen. Enbart DNS publicering är inte det sista dokumenterade steget.
- Steg 6. Utlösa ett representantrecensioner- eller lojalitetsmeddelande efter att supporten har bekräftat slutförandet. Fånga de resulterande identiteterna innan du rullar ut konfigurationen till en annan produkt eller skyltfönster.
Produktspecifika risker
Om domänen fortfarande misslyckas med valideringen, jämför DNS ägaren och CNAME -målet med den senaste supportuppsättningen, inte en gammal skärmdump. Om en befintlig SendGrid väljare är upptagen, återgå till stöd för den korrekta alternativa strukturen istället för att ta bort en fungerande integration. En fungerande spårningslänk eller varumärkesvisningsnamn kan inte etablera DKIM inriktning. Behåll supportärendets identifierare med ändringsposten så att senare nyckel- eller domänfrågor kan kopplas till den ursprungliga delegeringen.
Bevisa rutten i den mottagande änden
Använd en godkänd extern brevlåda och spara hela råmeddelandet med dess tidsstämpel och meddelandeidentifierare. Inget levande hyresgästtest görs anspråk på i denna guide. Följande är ett godkännande arbetsblad att fylla i under implementeringen, inte ett rekord av observerade resultat.
- Bevisfält: Synlig från; Vad som ska registreras: Faktisk adress och domän; Acceptansfråga: Är detta den avsedda avsändarens identitet?
- Bevisfält: Kuvert; Vad som ska spelas in: Return-Path och mottagaren rapporteras SPF domän; Acceptansfråga: Vilken domän autentiserade SPF egentligen?
- Bevisfält: SPF ; Vad som ska spelas in: Resultat av betrodd mottagare och utvärderad identitet; Acceptansfråga: Gick det igenom och stämmer den identiteten överens?
- Bevisfält: DKIM ; Vad som ska spelas in: Varje d= domän, s= väljare och mottagarresultat; Godkännandefråga: Stämmer minst en godkänd signatur?
- Bevisfält: DMARC; Vad som ska spelas in: Mottagarens resultat och tillämplig policy; Acceptansfråga: Finns det en anpassad passeringsväg?
- Bevisfält: Rutt; Vad som ska registreras: Produkt, konto och meddelandetyp; Acceptansfråga: Använde testet produktionsvägen?
DMARC behöver minst en anpassad, passerande SPF eller DKIM sökväg. En passerande signatur från en icke-relaterad tjänstedomän räcker inte. Strikt anpassning kräver exakt domänlikhet; avslappnad anpassning använder den tillämpliga organisation-domän-relationen. Kontrollera domänens faktiska anpassningsinställningar innan du förklarar framgång. En underdomän är inte en automatisk strikt matchning. SPF använder SMTP identiteten, inte visningsnamnet eller Reply-To. Konsultera justering ordlista vid protokollföring av beslutet.
Använda Authentication-Results från det mottagande systemet du litar på, inte en rubrik som tillhandahålls av en godtycklig avsändare. Fånga alla signaturer istället för att sluta vid det första misslyckandet. För vidarebefordrad e-post, jämför ett direkttest med en vidarebefordrad kopia: vidarebefordran kan ändra SPF utvärderingen eller ändra signerat innehåll. Diagnostisera inte dessa effekter genom att lägga till speditörens adress till din leverantörsbehörighet.
Diagnostisera fel utan att utöka åtkomsten
Jämför auktoritativ DNS med de exakt konfigurerade postnamnen först, kontrollera sedan rekursiv synlighet och tjänstevalidering. Ett felaktigt namn, trunkerad nyckel eller konflikt CNAME åtgärdas inte genom att vänta på cacher. Behåll endast en SPF policy hos en ägare och kontrollera gränsen för tio DNS-uppslagsperioder för utvärderade inkluderar och omdirigeringar innan du slår samman en annan avsändare. DKIM väljare tillhör individuella signeringskonfigurationer; skriv inte över ett annat programs post för att tvinga fram ett valideringsresultat.
Om autentiseringen godkänns men leveransen är dålig, inspektera mottagarens svar, rykte, innehåll och sändningsbehörigheter separat. DMARC pass lovar inte acceptans eller placering i inkorgen. Om ingen av vägarna är i linje, stoppa expansionen och korrigera den faktiska avsändarkonfigurationen. Försvaga inte hela domänens DMARC policy för att dölja ett enskilt produktfel.
Överlämning och återhämtning
Spara den godkända DNS differensen, offentliga uppslagningsresultat, tjänststatus och redigerat kalkylblad för mottagna meddelanden med en namngiven ägare. Håll inloggningsuppgifter och privata nycklar borta från biljetter. Vid fel, pausa det berörda sändningsjobbet eller använd en tidigare testad rutt under tjänsteägarens kontroll. Återställ endast de ändrade poster som hör till denna integration; behålla offentliga nycklar som behövs för meddelanden under flygning. Testa om efter återställning, nyckelrotation, domänmigrering eller en förändring av utgående relä. Stäng ändringen endast när produktägaren och e-postadministratören kan förklara den observerade identitetskedjan.
Bekräfta leverantörsgränsen
Källans CNAME illustration är domänspecifik och dess produktmetadata inkluderar oavslutade platshållare för andra Yotpo-produkter. Behandla endast explicita recensioner/lojalitetsinstruktioner som stöds här. Domänautentisering delegerar en sändande roll; det fastställer inte att en enskild författare är betrodd eller att varje meddelande är säkert.
Arbeta igenom ett fiktivt diagnostiskt fall
Endast fiktivt skriftligt fall: YO-01 antar att recensioner behöver reviews@shop.example men s1._domainkey.shop.example redan delegerar till en annan godkänd SendGrid applikation. Inget Yotpo-meddelande har fångats, så kuvert- och DKIM resultat är okända. Recensionsägaren måste avslöja kollisionen för Support, skaffa den domänspecifika alternativuppsättningen och bevara den andra applikationen innan testning. Ett lojalitets- eller icke-relaterat SendGrid exempel kan inte stänga denna rutt. Ingen hyresgäst, DNS , serverkommando eller meddelande utövades för detta fall.
Separera ett passerande meddelande från verkställighetsberedskap
RFC 9989 Avsnitt 7.4 kräver giltig DKIM för en domänpublicering p=reject och varningar om interoperabilitet med indirekt e-post. Ett enda anpassat SPF resultat motiverar inte i sig en utrullning av avvisningspolicy. Granska alla legitima rutter och policyägande separat från denna leverantörskonfiguration.