Vælg Dotdigital afsendelsesruten, før du trykker på DNS
Dotdigital autentificering bør omfattes af det nøjagtige produkt og afsenderidentitet. Denne vejledning omhandler brugerdefinerede fra adresser eller CFA'er i Dotdigital Marketing. Den etablerer ikke tilsvarende indstillinger for hver tilsluttet applikation, et andet Dotdigital-produkt eller en konto, hvis funktionsadgang ikke er blevet kontrolleret. Start med forretningsflowet, den foreslåede Fra-adresse og den person, der er ansvarlig for dets domæne.
Udbyderens nuværende branded domæne vejledning beskriver NS-delegerede og selv-hostede tilgange. Det kræver et dedikeret nyt underdomæne eller lookalike domæne og understøtter ikke samtidig brug af en CFA på en anden platform. Det gør domænevalg til en arkitektonisk beslutning, ikke et kosmetisk omdøbning af en kampagneadresse.
Inventar enhver eksisterende brug, før du godkender det foreslåede navn. Spørg, om det indeholder transaktionsmeddelelser, afvisningshåndtering, sporingslinks eller et ældre kampagnearkiv. En foreslået migrering kan påvirke mere end den næste meddelelse. Hold hver afhængigheds ejer og acceptable overgangstilstand synlige i stedet for at antage, at alle tjenester, der bruger et lignende domæne, tilhører den samme arbejdsgang.
Beslut hvem der skal administrere den afsendende DNS
Oprettelse af en CFA omfatter brug af et ejet underdomæne, køb af et afsendende domæne eller tilføjelse af et alias til et eksisterende afsendende domæne. Den dokumenterede underdomænemulighed kræver en DNS udbyder, der tillader den nødvendige delegering. Et køb eller kontogebyr er en separat godkendelsesbeslutning; dette manuskript gør ingen af dem.
For hosting-valget skal du bevare udbyderens DNSSEC kvalifikation. Dens branded-domæne-side siger, at en forælder, der bruger DNSSEC , skal bruge den selv-hostede tilgang i stedet for at uddelegere underdomænet til Dotdigital Marketing. Gør ikke denne kompatibilitetsbegrænsning til råd for at svække forældrenes sikkerhed. Bekræft organisationens påtænkte aftale med domæneejeren og det faktiske produktsupportomfang.
En intern overdragelse bør angive, hvem der vedligeholder hver post efter opsætning. En delegeret zone og en selv-hostet zone har forskellige ændringsansvar. Den nyttige leverance er en ansvarsgrænse og genopretningskontakt, ikke en antagelse om, at en grøn status fjerner behovet for fremtidigt ejerskab.
Følg den selvhostede verifikationssekvens nøjagtigt
For en selv-hostet CFA, den verifikationsvejledning kræver, at adressen findes i Marketing først. Den dokumenterede sti er Kontomenu, Indstillinger, E-mail, Fra-adresser og derefter Bekræft for den valgte adresse. Denne visning leverer DNS posterne for det afsendende domæne. Værdier skal komme fra den konto i stedet for fra et eksempel i denne artikel.
Når de godkendte poster er offentliggjort, vender det dokumenterede arbejdsforløb tilbage til Bekræft og inkluderer derefter et bekræftelsestrin. Læs den viste bekræftelse og indhent den nødvendige godkendelse, før du accepterer den. Kilden siger, at CAA-registreringer er valgfrie og udelukket fra denne verifikationskontrol; en vellykket status bør derfor ikke beskrives som udtømmende DNS validering.
Når verifikationen mislykkes, skal du bevare den nøjagtige fejl og sammenligne det forventede rekordsæt med det offentliggjorte. Udbyderen lister manglende poster, yderligere MX eller A-poster og formateringsproblemer blandt sine kontroller. Svar ikke ved at slette alle ukendte poster. Find først ud af, om det foreslåede afsendende domæne virkelig var dedikeret, og om en uventet registrering understøtter en aktiv afhængighed.
Skelne udbyderbekræftelse fra tilpasset post
Udbyderbekræftelse og en modtagers DMARC evaluering besvare forskellige spørgsmål. Den første vedrører tjenestens forventede opsætning; den anden vedrører en faktisk meddelelse og dens autentificerede identiteter. RFC 9989 afsnit 4.4 leverer justering rammer. Hold det synlige Fra-domæne, godkendt SPF identitet og alle relevante DKIM signering af domæne adskilt, indtil forholdet er etableret.
En forbigang DKIM signatur identificerer ikke nødvendigvis forfatter-domæneejeren. RFC 6376 afsnit 1.2 og 3.5 skelne mellem signatur- og signaturfelterne. Undersøg de faktiske d- og s-værdier og den betroede modtagers resultat i stedet for at oversætte et varemærket visningsnavn til bevis for kunde-domænesignering.
På samme måde evaluerer SPF en SMTP identitet i stedet for blot at læse den synlige Fra-adresse. RFC 7208 afsnit 2.4 forklarer den identitet. Tilføj ikke generisk godkendelse til det overordnede domæne, udelukkende fordi Dotdigital vises i en beholdning. Bestem, hvilken kuvertidentitet den konfigurerede rute bruger, og følg de relevante produktgenererede instruktioner.
Design beskedtjekket omkring forretningsflowet
Den foreslåede accepttest bør stamme fra den samme marketing-workflow, som sender den rigtige kampagne. En håndbygget besked fra et andet system fastslår ikke CFA's adfærd. Brug en ikke-følsom testmeddelelse og en godkendt modtagende postkasse, og behold derefter nok rå header-bevis til at rekonstruere identitetssammenligningen uden at oprette unødvendige kopier af beskedindhold.
Behold offentliggørelse, udbyderbekræftelse, meddelelsesgodkendelse, justering og endelig håndtering som separate rækker. For hver række skal du registrere det forventede resultat, faktisk observation, tidsstempel og korrekturlæser. Lad ikke-tilgængelige observationer udtrykkeligt stå tomme. En modtager, der ser mærkets navn, er ikke en erstatning for disse kontroller, og et indbakkeresultat er ikke et løfte om alle fremtidige kampagner.
Definer en stopbetingelse, før du ændrer noget: uforklarlige identitetsforskelle, en modstridende domæneafhængighed eller en verifikationsfejl, der ikke kan forenes med de tilsigtede poster. Eskalér det specifikke problem til den ansvarlige ejer. Undgå at løse usikkerhed ved at svække organisationens bredere DMARC politik eller flytte ikke-relaterede tjenester under samme ændring.
Fiktiv domæneudvælgelsesøvelse og frigivelsesport
I en fiktiv planlægningssession foreslår et team genbrug af et underdomæne, der allerede er tildelt transaktionspost. Dens gennemgang vælger i stedet et nyt dedikeret forslag til afsendende underdomæne og beder DNS ejeren om at evaluere det selv-hostede arrangement, fordi forælderen er underskrevet. Intet domæne er uddelegeret, ingen registreringer genereres, og ingen besked sendes. Øvelsen forklarer beslutningen, ikke dens udførelse.
Den originale bevisport forbliver: Aktuelt Dotdigital førstepartsopsætningsbevis og en identitetstabel med modtaget meddelelse fra det nøjagtige produkt og rute. Idriftsættelsesporten er: Bekræft den aktuelle produktidentitet og leverandørejet dokumentation; teste en rigtig besked eller offentliggjorte poster. Angiv ærligt ikke-understøttede brugerdefinerede domænefunktioner. Aktuel dokumentation bibeholdes, mens kontoanvendelse, originale observationer, menneskelig SMV-godkendelse, levende visuel gennemgang og udgivelsesgodkendelse forbliver åbne.