Start med rejsen og udsend identiteter
En Rejoiner-konto kan sende gennem automatiske rejser og planlagte udsendelser. Identificer de arbejdsgange, der er i brug, før du anmoder om DNS ændringer. Registrer mærket, kontoejeren, påtænkt fra-adresse, overvåget svarpostkasse og en kontrolleret test for hver sti. Brug en testkunde og harmløst indhold i stedet for at tilmelde rigtige kunder eller generere rigtige køb til diagnostiske formål.
Rejoiner's Dokumentation for e-mailindstillinger placerer standardafsenderoplysninger under Indstillinger og fanen E-mail. Den skelner mellem visningsnavnet, afsender fra adresse og svar-til-adresse. Kontroller disse standardindstillinger i forhold til den faktiske besked, der skal testes. Et velkendt visningsnavn fastslår ikke, hvilket domæne der skal godkendes.
Svarpostkassen tjener et andet formål end signerings- og konvolutdomænerne. Bekræft, at svar når det tilsigtede team, men behandl ikke et fungerende svar til som autentificeringsbevis. Hold brandingbeslutningen og den tekniske identitetstabel sammen, så marketingejeren kan se, hvad modtagerne vil støde på.
Få det aktuelle kontospecifikke rekordsæt
Rejoiner's autentificeringsressource beskriver assistance med klientgodkendelsessundhed. Dets offentlige materiale er nyttig baggrund, men de gennemgåede kilder giver ikke en fuldstændig lejerspecifik vælger, nøgle, SPF autorisation, tilpasset kuvertprocedure eller aktuel aktiveringssekvens. Disse oplysninger forbliver afventende, indtil de leveres for den faktiske konto.
Spørg kontoteamet om det godkendte afsendende domæne, nøjagtige DNS postejere og -typer, offentlige værdier, forventet DKIM d=, envelope-domain behavior and any activation requirement. Confirm whether journeys and broadcasts use the same configuration. Request an explicit answer about custom envelope justering i stedet for at antage, at valget af en mærkevare fra automatisk ændrer Return-Path.
Generer ikke en tilfældig DKIM nøgle fra en generisk vejledning og udgiv den til Rejoiner. Tjenesten skal have den matchende signeringsnøgle og være konfigureret til at bruge den tilsigtede identitet. Du må ikke kopiere en anden kundes vælger eller udlede en SPF inkludering fra en observeret upstream-udbyder. Konfigurationsautoriteten skal komme fra de understøttede kontoinstruktioner.
Vælg og dokumenter grænsen for afsendende domæne
Rejoiner's Guide til Google Postmaster Tools siger, at afsenderdomænet normalt er et underdomæne, der er reserveret til Rejoiner eller marketingmail. Behandl det som et dokumenteret mønster, ikke et obligatorisk værtsnavn eller bevis for den aktuelle lejers opsætning. Få virksomheden og DNS ejere til at godkende det domæne, der faktisk er tildelt dette program.
Skriv ned, hvordan det synlige Fra-, signeringsdomæne og konvolutdomæne hænger sammen. Under afslappet justering kan relaterede domæner kvalificere sig anderledes end under streng justering. Gå ikke ud fra, at oprettelse af et marketingunderdomæne garanterer kompatibilitet med en eksisterende streng politik. Løs identitetsdesignet, før du konfigurerer en ny kampagneadresse.
Hold webstedssporingsnavne og overvågnings-verifikationsposter adskilt fra e-mailgodkendelse. Rejoiner's Postmaster-instruktioner beskriver en Google-udstedt TXT post at bevise domæneejerskab for den pågældende overvågningstjeneste. Udgivelse af dette token aktiverer hverken Rejoiner DKIM eller giver SPF autorisation. Registrer formålet med hver DNS indgang, så fremtidig oprydning ikke forveksler analyseadgang med afsendelsestilladelse.
Offentliggør kun de godkendte godkendelsesposter
Gem en basislinje af relevante DNS poster, deres komplette navne, typer, værdier og TTL'er. Inkluder eksisterende SPF , DKIM og DMARC afhængigheder for medarbejdermail og andre marketingværktøjer. Bekræft, hvilken zone der indeholder det tilsigtede afsenderunderdomæne, og om editoren automatisk tilføjer sit suffiks.
Anvend hver udstedt post på den nøjagtige ejer og type. Sammenlign det resulterende offentlige svar med udbyderens instruktion, ikke kun med DNS editorens visning. Hvis en vælger eller et alias er i konflikt med en anden tjeneste, skal du søge efter et understøttet alternativ i stedet for lydløst at erstatte den anden udbyders registrering. Behold aktiveringstrinnet og dets tidsstempel med ændringen.
SPF under RFC 7208 evaluerer SMTP identiteten i stedet for den synlige From alene. Hvor en SPF politik er påkrævet, skal du beholde en enkelt politik hos den pågældende ejer og gennemgå de komplette DNS-forespørgselsomkostninger, inklusive indlejrede afhængigheder. Udvid ikke roddomænets godkendelse, blot fordi en generisk godkendelsesartikel anbefaler SPF .
Bevar organisationens eksisterende DMARC politik, justeringsmetoder og rapportdestinationer, medmindre en separat godkendt ændring er berettiget. Et nyt marketingprogram skal passe til domænets autentificeringsdesign. Det bør ikke lydløst svække beskyttelsen af medarbejderpost eller ikke-relaterede transaktionstjenester.
Udelukke en besked, der aldrig blev sendt
Før du diagnosticerer manglende DKIM , skal du fastslå, at testen producerede en e-mail. De Vejledning til e-mailindstillinger dokumenterer domæneundertrykkelse og en kontodækkende frekvensgrænse på tværs af rejser og udsendelser. Disse kontroller kan forhindre en bestemt testmodtager i at modtage en ny besked. Gennemgå de relevante kontobeviser, før du ændrer DNS eller gentagne gange udløser den samme kundehændelse.
Den samme vejledning siger, at konto BCC gælder for rejsebeskeder, ikke udsendelser, og advarer om, at BCC-engagement kan forvride rapporteringen. Brug ikke en manglende BCC-udsendelse som bevis på leveringsfejl. Send til en kontrolleret modtager gennem den faktiske rute og bevar leveringsbeviset uden unødigt at klikke på sporingslinks.
Hvis en arbejdsgang er undertrykt, begrænset eller aldrig udløst, skal du løse denne testtilstand gennem den relevante ejer. Autentificering evalueres på mail, der når frem til en modtager; en beslutning på applikationssiden om ikke at sende kan ikke repareres ved at tilføje en DNS record. Hold denne skelnen synlig i problemloggen.
Læs overskrifterne for begge arbejdsgange
Når konfigurationen er klar, skal du sende en kontrolleret rejse-e-mail og en kontrolleret udsendelse, hvor begge er i omfang. Capture Message-ID, UTC-tid, From, Return-Path , hver DKIM d= og s=, og det endelige modtagende systems betroede godkendelsesresultater. Registrer rejsen eller udsendelsesidentifikationen, så beviserne kan gengives.
DKIM 's specifikation definerer signeringsdomænet og vælgeren. Undersøg hver signatur, og identificer hvilken, hvis nogen, der både passerer og flugter med den synlige Fra. Under RFC 9989, DMARC kræver en tilpasset passerende SPF eller DKIM -sti. Et ikke-relateret udbyder-domænepas er utilstrækkeligt i sig selv.
Gem godkendelsesresultatet adskilt fra placering og engagement. En lav åbningsrate beviser ikke en DKIM fejl, og én indbakkeplacering certificerer ikke hele programmet. Når en ny meddelelse mislykkes, skal du sammenligne dens observerede identiteter med den kontoudstedte konfiguration, før du eskalerer med en redigeret overskrift og nøjagtig UTC-tid.
Arbejdsark til accept af rejoiner
Komplet uafhængige poster til rejser og udsendelser:
- Konto, brand, rute og virksomhedsejer: ____.
- Tiltænkt Fra, svarpostkasse og godkendt afsendende domæne: ____.
- Udbyder rekordsæt og understøttet signering/konvolutadfærd: ____.
- Præcise DNS ejere, typer, værdireferencer og aktiveringstid: ____.
- Eksisterende DMARC -politik og anvendelige justeringsmetoder: ____.
- Kontrolleret modtager-, trigger-, undertrykkelses- og frekvenstjek: ____.
- Besked-id, UTC-tid og workflow-id: ____.
- Return-Path , alle DKIM d= og s=, pålidelige resultater: ____.
- Faktisk justeret mekanisme og placeringsobservation: ____.
- Spørgsmål til gendannelse, anmelder og udestående kapacitet: ____.
Hold Postmaster ejerskabsbekræftelse i en separat overvågningsrække. Det kan understøtte senere omdømmearbejde, men kan ikke udfylde felterne for godkendelsesaccept.
Fiktiv diagnose af en fraværende udsendelseskopi
Kun fiktivt eksempel: Juniper Outfitters modtager BCC-rejse-kopier, men ingen broadcast-BCC, og foreslår derefter at erstatte sin DKIM rekord. Administratoren kontrollerer den dokumenterede BCC-grænse og tester udsendelsen ved hjælp af en kontrolleret faktisk modtager. Denne kopi viser tilpasset DKIM og et DMARC -pas.
Teamet efterlader DNS uændret og retter sin bevisindsamlingsmetode. Den kontrollerer separat frekvens- og undertrykkelseskontroller for testmodtagere, der ikke modtager noget. Ingen Juniper-konto eller besked blev inspiceret; eksemplet viser, hvorfor workflow-bevis skal gå forud for en godkendelsesreparation.
Lad uløste egenskaber være synlige
Tjek igen efter afsenderændringer, nye arbejdsgange, DNS migrering eller opdatering af udbydernøgle. Kontospecifikke DNS værdier, kundetilpasset konvolutsupport, bekræftelse af live lejer og header, visuel gennemgang, godkendelse af menneskelige SMV'er og offentliggørelse afventer stadig. Offentlig dokumentation understøtter indstillingerne ovenfor, men lukker ikke disse implementeringsporte.
Brug produktvejledning uden at bruge brede protokolgenveje
Den generelle godkendelsesressource er baggrunden, ikke en kontoudstedt nøgle eller bevis på, at autentificeret post er sikker. Brug protokolstandarder til identitetsevaluering og udbyderudstedte instruktioner til konfiguration. Den fiktive forbigående udsendelse er kun et illustrativt fastsat resultat, ikke en Rejoiner-lejertest udført til denne anmeldelse.
Adskil meddelelsesaccept fra politikudrulning
Et bestået justeret SPF resultat kan tilfredsstille en meddelelsesevaluering, men retfærdiggør ikke alene at flytte et helt domæne for at afvise. RFC 9989 Afsnit 7.4 kræver gyldig DKIM for domæneudgivelse p=reject og advarer om interoperabilitet med indirekte mail. Inventar alle legitime afsendere og indirekte ruter, før policeindehaveren godkender håndhævelse. Ingen DNS ændring, lejerdrift eller test af modtaget meddelelse blev udført for denne artikel.