Skille systempost fra markedsføringspost
Spektrix sin system-e-postautentiseringsdokumentasjon dekker driftsmeldinger som ordrebekreftelser, print-at-home-billetter, tilbakestilling av passord og medlemsmeldinger. Det skiller disse fra markedsførings-e-post som håndteres av Dotdigital. Et markedsføringsdomene som autentiseres er derfor ikke tilstrekkelig bevis på at systemvarslinger bruker den tiltenkte identiteten.
Inventar Spektrix-systemet, meldingskategorier, tiltenkt avsender og ansvarlig team. Inkluder planlagte rapporter eller lister bare der de er en del av det faktiske omfanget; ikke anta at alle mulige funksjoner er aktivert for organisasjonen. Kundestøtte- og billettkontorteamene bør bli enige om hvilken synlig adresse mottakere vil se og hvilken postboks som vil motta svar.
Dokumentasjonen støtter en konfigurasjonsplan, ikke en påstand om at en leietaker er konfigurert. Dette manuskriptet utfører ingen støttekommunikasjon, DNS spørring, postendring eller testsending. De opprinnelige kravene til implementering og kontoanvendelse forblir åpne. System e-postgodkjenning
Velg det dedikerte sendeunderdomenet med vilje
Spektrix instruerer klienter til å bruke et underdomene for systempost og plassere den relevante konfigurasjonen der i stedet for ved roten. Den fraråder også å bruke det samme underdomenet som en Spektrix-tilpasset domene-nettintegrering. Registrer den valgte grensen og sjekk om det navnet allerede tjener et annet formål.
Et dedikert underdomene kan hjelpe å skille operasjonelle avhengigheter, men det er ingen garanti for at omdømme eller sikkerhetseffekter aldri kan nå den bredere organisasjonen. Den praktiske fordelen er tydeligere eierskap og redusert overlapping med rotdomeneinfrastruktur. Bevar det skillet i stedet for å love fullstendig isolasjon.
Før du foreslår poster, identifiser den eksisterende autoritative sonen, gjeldende MX bruk og arvet eller eksplisitt DMARC politikk. Et navn som vises ubrukt i et regneark, kan fortsatt støtte en tjeneste. Ikke erstatt produksjonsnettsted eller postboksposter bare for å passe til et praktisk eksempel. Bekreft det tiltenkte underdomenet med den autoriserte domeneeieren og Spektrixs dokumenterte støttearbeidsflyt. Sender underdomene
Gjennomgå SPF , DKIM og MX som forskjellige avhengigheter
System-e-postguidenavnene SPF, DKIM og MX poster for det valgte avsendende underdomenet. SPF eksemplet inkluderer mailgun.org . Hvis en SPF policy allerede eksisterer med det navnet, kan du gå gjennom én fullstendig policy i stedet for å legge til en ny post eller lime inn en hel prøve i den eksisterende verdien. Ta vare på legitime kilder og gjennomgå DNS-avhengige evalueringsgrenser.
DKIM er støtteassistert: guiden ber klienter om å bekrefte avsenderdomenet med Spektrix Support, som hjelper til med å generere domenenøkkelen. Den beskriver 2048-bit nøkler. Behold det faktisk utstedte nøkkelnavnet og offentlig verdi; ikke oppfinn en velger eller gjenbruk en annen organisasjons nøkkel.
MX -poster gjelder e-postruting, ikke en erstatning for en DKIM signatur. Guiden gir forskjellige Mailgun MX destinasjoner for kunder i Storbritannia/Irland/Canada og USA. Bruk den leverandørbekreftede kontoregionen og fullstendige instruksjoner, inkludert eventuelle verdier som ikke er etablert av et kopiert utdrag. Endre aldri rotdomenets eksisterende e-posttjeneste bare fordi system-e-post-underdomenet trenger MX konfigurasjon. Sette opp SPF , DKIM og MX Records; RFC 7208 , avsnitt 3.2; RFC 7208 , avsnitt 4.6.4
Fortsett logging og svarruting atskilt fra autentisering
Veiledningen beskriver en valgfri e-postloggingsavhengighet ved å bruke en e-postetikett under det avsendende underdomenet og en egnet region CNAME. Den sier at klienter ikke har direkte tilgang til den resulterende loggingen og at det hjelper med å undersøke levering. Dette er ikke det samme som en DKIM nøkkel eller bevis på at en mottaker har lest en melding.
Se gjennom sporings- eller loggingsfunksjoner under organisasjonens personvern- og kommunikasjonskrav før du aktiverer dem. Dette manuskriptet oppretter ikke sporingsposten eller samler inn mottakerinteraksjonsdata. En foreslått bevispakke kan identifisere om funksjonen er innenfor omfanget uten å anta at åpninger eller klikk på en pålitelig måte måler menneskelig oppmerksomhet.
Leverandøren beskriver også å angi en svar-til-adresse gjennom støtte når avsenderadressen ikke har noen overvåket postboks. Se gjennom den destinasjonen med billettkontoret. Et vellykket svar beviser et arbeidsflytutfall, ikke justering av den opprinnelige meldingen. Logging av e-post; Svar til adresse
Bevar DMARC -intensjon for overordnet domene
Spektrix advarer om at et grunnleggende underdomene DMARC rekord kan komme i konflikt med organisasjonens eksisterende konfigurasjon for overordnet domene. Behandle alle oppgitte overvåkingspolicyer som en foreslått policybeslutning, ikke et ufarlig verifikasjonstoken. Å publisere en eksplisitt underdomenepolicy kan endre gjeldende policyforhold, så domeneeieren må gjennomgå den før godkjenning.
Bruk gjeldende DMARC semantikk i stedet for brede utsagn om at autentisering alltid sikrer levering eller at en policyverdi bestemmer hver mottakers utfall. DMARC evaluerer justering med en bestått autentiseringsidentitet, mens mottakere beholder sine egne håndteringspolicyer. Et reserve-sendedomene kan ikke antas å autentisere et ikke-relatert forfatterdomene bare fordi e-post fortsetter å forlate et program.
Den foreslåtte sluttkontrollen er en autorisert representativ systemmelding med forfatterdomene, signeringsidentitet, velger, relevant konvoluttidentitet og klarerte mottakerresultater. Hold markedsføringsmeldingsbevis atskilt. Ikke senk policyen for å skjule en uløst systemrute eller påstå at en grønn DNS sjekk beviser at kunden har mottatt en billett. DMARC ; Konflikter; Reservedomene; RFC 9989 , avsnitt 4.4; RFC 9989 , avsnitt 5.3
Akseptarbeidsark for billettkontor og IT-team
Bruk dette originale foreslåtte regnearket til å koordinere operativ post uten å erstatte bevis med antagelser.
- Meldingsomfang: systemidentifikator, driftskategorier og separate Dotdigital-markedsføringsansvar.
- Sendegrense: godkjent underdomene, eksisterende DNS bruk og forskjell fra egendefinerte nettintegrasjoner.
- Leverandørforespørsel: støttebekreftet region, utstedte DKIM nøkkeldetaljer og fullstendige registreringsinstruksjoner.
- Retningslinjegjennomgang: én sammenhengende SPF policy, eksplisitt eller nedarvet DMARC intensjon og domeneeierens godkjenning.
- E-postruting: MX konfigurasjon av underdomene og bekreftelse på at rotdomenepostkassetjenesten forblir upåvirket.
- Valgfrie funksjoner: logging eller sporingsavgjørelse, personverneier og overvåket svar-til-destinasjon.
- Aksept: leverandørstatus der det er tilgjengelig, autoriserte mottatte meldingsidentiteter og klarerte autentiseringsresultater.
- Kontinuitet: tilbakeføringseier, planlagte meldingsavhengigheter og uløste spørsmål om produksjonsutgivelse.
Arbeidsarket er tomt. Den registrerer ingen faktiske kundeadresser, billettkjøp, private nøkler, DNS endringer eller støttehandlinger.
Fiktiv diagnose: et markedsføringsdomene ble forvekslet med systempost
Et fiktivt teater lanserer en autentisert Dotdigital-kampanje og antar at billettbekreftelsene dekkes av samme oppsett. Et senere eksempel på systemmeldinger viser en annen sendebane. Boxoffice-teamet foreslår å endre rotdomenets MX poster fordi system-e-postguiden nevner MX .
Den foreslåtte gjennomgangen stopper den urelaterte endringen. Den skiller markedsførings- og driftsrutene, identifiserer det dedikerte system-e-post-underdomenet og ber om de riktige konto-regioninstruksjonene og støtteutstedt nøkkel. Den eksisterende bedriftens postboksinfrastruktur bevares mens det nye avhengighetssettet gjennomgås.
Teateret sjekker også retningslinjene for foreldredomene før de godtar en foreslått underdomenepost. Det kreves ingen suksess før det foreligger passende operative bevis. Dette scenariet er fiktivt og beskriver ikke en faktisk Spektrix-hendelse, kundemelding eller utført test.