Velg et avsenderdomene med en eksplisitt grense
Copernica dokumenterer avsenderdomener som en nødvendig del av sendeoppsettet. Hurtigguiden bruker Marketing Suite til å velge et e-postdomene og få en generert liste over DNS poster. Start med den nøyaktige kontoen og postruten, ikke en generisk liste over poster knyttet til leverandørens navn. Dokumentasjonen forklarer også at Marketing Suite sender-domeneinnstillinger prioriteres når Publisher brukes, så teamet bør identifisere hvilken konfigurasjon som styrer den tiltenkte e-posten.
Bestem om ruten skal bruke organisasjonens hoveddomene eller et dedikert underdomene. Den avanserte sender-domeneveiledningen diskuterer begge valgene og fremhever den ekstra omsorgen som trengs rundt eksisterende hoveddomeneinnstillinger. Et underdomene kan redusere overlapping med etablert infrastruktur, men det er ikke automatisk ubrukt, risikofritt eller unntatt fra nedarvet policy. Sjekk eksisterende avhengigheter før du behandler det som en ren grense. Rask veiledning for avsender-domene; Avsenderdomener
Les den genererte DNS planen etter funksjon
Når et avsenderdomene opprettes, dokumenterer Copernica generering av poster på sin infrastruktur og viser den nødvendige DNS konfigurasjonen på kundesiden i Marketing Suite. Veiledningen beskriver funksjoner inkludert klikk- og åpen sporing, håndtering av sprett, DKIM signaturer, SPF autorisasjon og DMARC rapportering. Dette er distinkte avhengigheter, selv når grensesnittet presenterer dem sammen.
For hver foreslåtte post beholder du eiernavnet, typen, målet eller verdien, og dens tiltenkte funksjon. Identifiser hvilke verdier som er aliaser til leverandøradministrerte poster og hvilke som er TXT policyinnhold. Ikke utlede at hver oppført funksjon bruker en identisk posttype. Den separate SPF dokumentasjonen er viktig fordi den beskriver en TXT -inkluderingsmekanisme i stedet for å behandle SPF som bare et annet utskiftbart alias.
Unngå å kopiere verdier fra en annen avsenderdomene eller konto. Den genererte planen skal forbli tilknyttet kildekontoen og gjennomgangsdatoen. Den offentlige dokumentasjonen støtter arbeidsflyten, men den er ikke en erstatning for den spesifikke planen organisasjonen faktisk vil godkjenne. DNS postene; SPF
Forstå den leverandøradministrerte avhengigheten
Copernica forklarer at aliaser på kundesiden peker på poster den administrerer, og tillater endringer på leverandørsiden som DKIM rotasjon eller sending av infrastrukturoppdateringer uten at hver kunde må endre det tilsvarende aliaset. Dette er en avhengighetsmodell, ikke en overføring av kontroll over hele kundesonen. Registrer nøyaktig hvilke DNS navn som avhenger av leverandøren og hvem som eier livssyklusen deres.
Den praktiske fordelen kommer med et løpende ansvar: inventar aliasene, behold kontoforholdet og gjennomgå dem når tjenesten erstattes eller avsenderdomenet blir trukket tilbake. Ikke fjern et DKIM alias bare fordi en kampanje er satt på pause. aktive ruter eller e-post i kø kan fortsatt avhenge av konfigurasjonen. Omvendt, ikke la uadministrerte leverandøravhengigheter være på ubestemt tid etter offboarding.
Et leverandøradministrert mål garanterer ikke at alle fremtidige DNS tilstander forblir korrekte. Overvåking, endringsgjennomgang og en dokumentert pensjonsplan er fortsatt organisasjonsansvar. Dette manuskriptet foreslår disse kontrollene uten å hevde at noen kundes poster ble inspisert eller modifisert. Leverandøradministrert DNS forklaring
Plasser SPF ved riktig identitet
SPF dokumentasjonen skiller sprett-underdomenet brukt av Copernica fra organisasjonens hoveddomene. Den beskriver bruk av en inkludering i en TXT SPF policy for den relevante konfigurasjonen. Ikke flette automatisk en antatt Copernica-mekanisme inn i rotdomenet bare fordi den synlige Fra-adressen bruker dette domenet. Identifiser først den faktiske konvoluttidentiteten og den kontoutstedte DNS planen.
SPF evaluerer SMTP identiteter under sine egne regler. En inkluderingsmekanisme påkaller en annen SPF policy under evaluering; en CNAME er et DNS alias. De er ikke den samme protokolloperasjonen, selv om begge skaper en ekstern avhengighet. Skillet har betydning for feilsøking, rekordsameksistens og SPF evalueringsgrenser.
Hvis en policy allerede eksisterer ved det relevante eiernavnet, kan du se gjennom den som én fullstendig policy i stedet for å legge til en andre konkurrerende SPF rekord. Ta vare på andre autoriserte kilder og evaluer gjeldende DNS-avhengige vilkår. Den beholdte leverandørsiden inneholder illustrative navn, så bruk faktisk genererte verdier i stedet for å utlede en kopierbar konfigurasjon fra et eksempel. Copernica SPF; RFC 7208 , avsnitt 2.4; RFC 7208 , avsnitt 3.2; RFC 7208 , avsnitt 4.6.4
Gå gjennom DMARC før du godtar en samlet endring
Den avanserte veiledningen trekker spesifikt oppmerksomhet til mulige DMARC konflikter når et hoveddomene allerede har e-postinfrastruktur. Behandle en eksisterende DMARC policy og rapporteringsordning som en organisasjonsomfattende avhengighet. En ny avsender-domenepakke skal ikke stille erstatte etablerte rapporteringsdestinasjoner eller endre policy for ikke-relaterte avsendere.
Den foreslåtte gjennomgangen er å sammenligne det tiltenkte synlige Fra-domenet, forventet signeringsdomene og konvoluttidentiteten med gjeldende justering innstillinger. En leverandøradministrert nøkkel kan valideres på en vellykket måte, mens et Fra-domene med en annen merkevare ikke justeres. En fungerende DKIM bane beviser heller ikke at en nylig introdusert SPF -bane er konfigurert med riktig eiernavn.
Hvis den genererte planen og eksisterende policy ikke kan forenes trygt, hold endringen for domeneeieren og leverandøren å avklare. Ikke løs konflikten ved å svekke politikken uten et godkjent vedtak. Autentiseringsresultater etablerer heller ikke meldingslegitimitet, mottakers samtykke eller garantert levering. Subdomene eller hoveddomenet?; RFC 9989 , avsnitt 4.4
Godkjenningsregneark for det administrerte avsenderdomenet
Bruk dette foreslåtte regnearket for å holde den genererte konfigurasjonen ansvarlig gjennom hele livssyklusen.
- Omfang: identifiser Marketing Suite-kontoen, utgiveravhengighet hvis relevant, avsenderdomene og e-postkategorier.
- Eksisterende bruk: Registrer nåværende DNS eiere, aktive e-postruter og eventuelle delte domenepolicyer før du foreslår endringer.
- Generert plan: behold hver eksakt post med dens funksjon, kontotilknytning og leverandøradministrert avhengighet.
- SPF identitet: Registrer det tiltenkte konvolutt- eller returdomenet og den fullstendige gjennomgangen av retningslinjene ved det navnet.
- DMARC kompatibilitet: identifiser den eksisterende policyeieren, rapporteringsavhengigheter og justeringsforutsetninger.
- Bekreftelse: behold leverandørstatusen atskilt fra autoritative DNS bevis og et autorisert utvalg av mottatte meldinger.
- Pensjon: navngi tjenesteeieren som er ansvarlig for gjennomgang av e-post i kø, fjerning av alias og validering etter offboarding.
Dette arbeidsarket er et originalt driftsforslag. Det er ikke en utført DNS inspeksjon, en fullført avsender-domenekonfigurasjon eller bevis på at en generert post har blitt akseptert.
Fiktiv diagnose: en rotpolitisk endring som ikke hjalp
En fiktiv forhandler oppretter et avsenderdomene for nyhetsbrev i Marketing Suite. Dens DNS administrator ser en SPF referanse i dokumentasjonen og foreslår å endre rotdomenet, selv om den genererte planen identifiserer et eget returunderdomene. I mellomtiden støtter rotdomenet allerede flere urelaterte forretningsapplikasjoner.
Kontrolløren setter rotendringen på pause og tilordner hver genererte post til funksjonen. Den foreslåtte undersøkelsen sjekker den faktiske konvoluttidentiteten og den relevante TXT policyen i stedet for å behandle den synlige Fra-adressen som SPF oppslagsnavnet. Den bevarer også den eksisterende DMARC -rapporteringsordningen mens den vurderer den nye rutens justering. Teamet har ikke bevist suksess bare ved å korrigere planen; den trenger fortsatt autorisert publisering og meldingsbevis. Dette fiktive eksemplet illustrerer en grensefeil og rapporterer ikke en ekte Copernica-hendelse.