Bekräfta CMS-distributionen innan du väljer instruktioner
Optimera CMS skapar programmeddelanden, men den konfigurerade transporten skickar dem. Börja med att spela in CMS-version, värdmodell, miljö och e-postintegration som hanterar det berörda arbetsflödet. Ett CMS som körs på DXP, en installation med egen värd och en applikation med ett eget tredjepartsrelä kan inte antas dela en SPF eller DKIM konfiguration. Optimizely Campaign är en separat produkt och dess domänposter för marknadsföringsmail får inte lånas för CMS-aviseringar.
Förstapartens DXP e-postserversida som hämtas för den här guiden är märkt DXP för CMS 12 och Commerce 14. Den dokumenterar ett moln transaktionsmail tjänst, en SendGrid-stödd SMTP konfiguration och en supportassisterad domänautentiseringsprocess. Den här artikeln använder den vägen som sin konkreta implementeringsgren. Tillämplighet på en annan CMS-version, värdnivå eller anpassad integration kräver motsvarande aktuell dokumentation och distributionsbevis. Den allmänna katalogetiketten Optimizely CMS är bredare än det etablerade konfigurationsomfånget här. DXP e-postserverkonfiguration
Innan du redigerar konfigurationen, namnge programägaren, distributionsoperatören, e-postadministratören och DNS ägaren. Kom överens om vilket arbetsflöde som kommer att visa framgång: ett projektmeddelande, ett meddelande om innehållsgodkännande eller annan explicit konfigurerad applikations-e-post. Använd syntetiskt innehåll och en kontrollerad mottagare. Ett marknadsföringsnyhetsbrev är inte en lämplig ersättning för ett CMS-aviseringstest bara för att båda produkterna bär samma leverantörsnamn.
Spåra meddelandet från applikationshändelse till relä
Dela upp rutten i händelseskapande, applikationsutskick, SMTP inlämning, leverantörsleverans och mottagarautentisering. Registrera vilka bevis som finns tillgängliga i varje steg. Om programmet aldrig producerar eller skickar ett meddelande, kan redigering av SPF inte skapa det. Om SMTP avvisar autentiseringsuppgifter har meddelandet ännu inte nått det stadium där mottagaren utvärderar DMARC.
Optimizelys CMS 13 Projects-dokumentation beskriver separat utskick av meddelanden och säger att SMTP inställningar måste konfigureras för e-postmeddelanden. Detta stöder kontroll av trigger- och leveransstadiet när den faktiska installationen är CMS 13; det fastställer inte att en CMS 12-distribution har identiska jobbstandarder eller att DXP SMTP exemplet gäller oförändrat. Matcha konfigurationsinstruktionerna till den installerade versionen i stället för att blanda versionsutdrag. CMS 13 projektmeddelanden
För varje miljö, särskilj den effektiva körtidskonfigurationen från en källfil som kan åsidosättas under distributionen. En iscensättningsframgång kan samexistera med ett produktionsfel orsakat av en saknad inställning eller en annan Från-adress. Samla in sanerade inställningar och applikationsloggar genom den normala teknikprocessen. Avslöja inte SMTP uppgifter, API-nycklar eller orelaterade produktionshemligheter i bevispaketet.
Konfigurera den dokumenterade DXP-transporten genom en kontrollerad distribution
DXP-guiden säger att e-postkonfigurationen inte tillämpas automatiskt av standardkonfigurationstransformeringar. Den beskriver hur man skaffar e-posttjänstens autentiseringsuppgifter via DXP-hanteringsportalen och tillhandahåller SMTP inställningar till applikationen. Dess exempel inkluderar identitetsinställningar för applikationsaviseringar samt transportinställningar. Använd den konfigurationsmekanism som stöds för den distribuerade versionen och miljön och granska de resulterande effektiva värdena. DXP e-postserverkonfiguration
Behandla autentiseringsskapande, lagring och rotation som en separat kontrollerad säkerhetsoperation. Den här guiden kräver inte en ny legitimation om en godkänd arbetsuppgifter redan finns. Klistra aldrig in en hemlighet i en offentlig artikel, arkivexempel, DNS post eller supportskärmdump. Referera istället till godkänd hemlig butik och ansvarig operatör. Bekräfta att distributionsloggar och felrapportering inte skriver ut autentiseringsuppgifterna vid testning.
Den dokumenterade DXP-tjänsten är för automatiserad transaktionskommunikation på webbplatsen. Guiden riktar kunder som behöver andra SendGrid funktioner, såsom sin egen anpassade HTML-mallsanvändning, mot ett separat prenumererat konto eller en annan SMTP leverantör. Bekräfta den avsedda användningen istället för att anta att åtkomst till DXP SMTP är obegränsad åtkomst till ett kundhanterat SendGrid konto. Ett separat konto har sin egen procedur för ägande och domänautentisering.
Begär autentisering för varje sändande domän
För den dokumenterade DXP-rutten, kontakta Optimizely med den sändande domänen för hjälp med att aktivera avsändarautentisering. Samma guide säger att DKIM måste begäras för varje mail-send-domän och kräver ytterligare DNS poster. Skaffa det exakta rekordet och aktiveringsplanen för miljön innan du publicerar något. Ingen universell väljare, CNAME mål eller privat nyckel kan härledas från produktnamnet. DXP-domän och DKIM -konfiguration
Lista alla synliga Från-domäner som används av relevanta meddelanden. Om flerplatsapplikationer eller separat konfigurerade arbetsflöden använder olika domäner, fråga support vilken autentiseringskonfiguration som täcker var och en. Anta inte att verifiering av den primära företagsdomänen automatiskt aktiverar varje underdomän eller alternativt varumärke. Registrera vem som måste bekräfta aktivering på avsändarsidan efter DNS publicering.
DXP-sidan innehåller exempel på SPF policyer. Behandla dem som dokumentationsexempel, inte kompletta recept för en produktionsdomän. Bestäm den faktiska kuvertägaren, bevara andra auktoriserade avsändare och upprätthåll en giltig SPF policy där. Utvärdera rekursiva uppslagsgränser innan auktorisering slås samman. Om den konfigurerade transporten skiljer sig från den dokumenterade DXP-tjänsten, skaffa den transportens egna aktuella instruktioner istället. SPF RFC 7208
Publicera varje tillhandahållen DKIM -post hos den exakta ägaren med den medföljande typen. Bevara aktiva väljare under en planerad övergång, lös CNAME konflikter innan du sparar och behåll privata nycklar utanför DNS . Fråga de auktoritativa servrarna för att verifiera det resulterande namnet och värdet; Det räcker inte med en förhandsvisning av DNS -redigeraren. En offentlig post stöder validering endast när det faktiska utgående meddelandet använder sin motsvarande signeringsidentitet. DKIM RFC 6376
Håll avsändarens identitet och DMARC -policy samordnade
Kom överens om den avsedda synliga från-adressen före testet. Ett korrekt SMTP värdnamn och arbetsuppgifter bevisar inte att programmet använder den godkända From-domänen. Registrera den effektiva aviseringsidentiteten och eventuell åsidosättning på applikationsnivå separat från transportkonfigurationen. Granska svarshanteringen så att mottagare inte hänvisas till en obevakad brevlåda utan ett affärsbeslut.
Inspektera den aktuella DMARC policyn för den synliga domänen och behåll dess godkända tillämpning, inriktning och rapporteringskonfiguration. DMARC lyckas när minst en godkänd SPF eller DKIM identitet anpassas under det tillämpliga läget. En leverantörsägd signeringsdomän kan passera kryptografisk validering utan att anpassa sig till organisationens synliga Från-domän. Svara inte genom att försvaga hela domänens policy innan du undersöker den avsändarautentiseringsrutt som stöds. DMARC RFC 9989
Applikationsanslutning, leverantörsautentisering och placering av inkorgen är separata acceptansresultat. En CMS-logg som säger att ett meddelande har skickats är inte ett kvitto från den slutliga brevlådan. Ett mottaget meddelande med godkänd DMARC kan fortfarande filtreras av andra skäl. Behåll dessa distinktioner i ändringsrapporten så att ett framgångsrikt lager inte döljer ett olöst problem någon annanstans.
Återanvändbart CMS och DXP rutt arbetsblad
Fyll i en separat kopia för varje distributionsmiljö och väsentligt olika sändningsidentitet.
- CMS-version, värdmodell, projekt och miljö: ______.
- Exakt arbetsflöde, syntetisk trigger och förväntad mottagare: ______.
- Konfigurationskälla, implementeringsrevision och effektiva körtidsinställningar: ______.
- Endast transportleverantör, kontoägare och godkänd hemlig referens: ______.
- Synlig från, visningsnamn, svarsdestination och kuvertförväntning: ______.
- Supportärende som bekräftar DXP-tillämpning och varje sändande domän: ______.
- Utfärdade DNS ägare, typer, värden och aktiveringskrav: ______.
- Befintliga SPF och DMARC -policyer och godkänd ändringsuppsättning: ______.
- Auktoritativa svar, frågetider och leverantörsverifieringsstatus: ______.
- Utskick, SMTP inlämning och leverantörsbevis: ______.
- Mottaget-meddelande Från, kuvert, alla DKIM d=/s= -par och betrodda resultat: ______.
- Återställningsdistribution, DNS återställningsplan och mänsklig acceptans: väntar.
Fiktiv diagnos av ett produktionsaviseringsfel
Detta exempel är fiktivt. Ett team testar framgångsrikt ett godkännandemeddelande i staging och distribuerar applikationen. Produktionsmeddelanden använder en annan synlig Från-domän. SMTP inlämning lyckas, men en oberoende mottagare rapporterar en giltig leverantörssignatur som inte överensstämmer med den produktionsdomänen. Teamet föreslår att ett DKIM mål för kampanj kopieras till DNS eftersom det också tillhör Optimizely.
Den föreslagna diagnosen jämför den effektiva produktionsidentiteten med de domäner som täcks av DXP-supportbegäran. I det här scenariot inkluderades endast iscensättningsidentiteten. Den korrigerande planen är att begära den stödda autentiseringskonfigurationen för produktionssändningsdomänen, publicera de utfärdade posterna och testa om det faktiska godkännandearbetsflödet. Att låna en kampanjpost skulle inte fastställa att DXP-undertecknaren använder den. Detta är ett fungerande exempel, inte ett livetest eller ett påstående om någon kunddistribution.
Återställ vid lagret som ändrades
Om programmet slutar skicka meddelanden, jämför distributions- och transportinställningarna innan du återställer DNS . Om domänverifieringen misslyckas, jämför de supportutfärdade ägarna med auktoritativa svar. Om autentiseringen går igenom men leveransen misslyckas, inspektera leverantörens och mottagarens svar utan att utöka avsändarbehörigheterna i onödan. Bevara bevis innan återförsök så att dubbla aviseringar kan identifieras.
Återställning bör återställa den snävt påverkade distributionen eller DNS ändringen, inte rotera alla autentiseringsuppgifter eller återställa hela zonen. Återgå ersatta väljare först efter att e-postägaren har bekräftat att ingen aktiv eller köad rutt behöver dem. Den dokumenterade DXP-grenen är etablerad, men bredare CMS-versionstillämpning, hyresgästspecifika inställningar, supportutfärdade värden, live- DNS , mottagna meddelanden, visuell granskning och mänskligt SME-godkännande kvarstår. Ingen programkonfiguration, autentiseringsuppgifter, DNS post eller live-arbetsflöde ändrades för den här guiden.
Håll transportsäkerhet borta från kopierade exempel
Den offentliga sidan blandar konfigurationsfilexempel och inkluderar en SSL-inaktiverad kodinställning. Den här artikeln godkänner inte den inställningen eller ett kodavsnitt som inte matchar versionen. Låt driftsättningsägaren bekräfta transporten och TLS -beteendet som stöds för den faktiska körtiden utan att avslöja autentiseringsuppgifter. I det fiktiva fallet bestämmer inte leverantörens signatur ensam det ospecificerade SPF resultatet.
Separat meddelandeacceptans från policyimplementering
Ett passande justerat SPF resultat kan tillfredsställa en meddelandeutvärdering, men motiverar inte ensamt att flytta en hel domän för att avvisa. RFC 9989 Avsnitt 7.4 kräver giltig DKIM för domänpublicering p=reject och varnar för interoperabilitet med indirekt e-post. Inventera alla legitima avsändare och indirekta rutter innan policyägaren godkänner verkställighet. Ingen DNS ändring, klientdrift eller test av mottagna meddelanden utfördes för den här artikeln.