Behandle adressebekreftelse og autentisering separat
En bekreftet fra-adresse beviser tilgang til den postboksen; det beviser ikke i seg selv at et nyhetsbrev har vært på linje DKIM eller SPF. Start med et domene organisasjonen din kontrollerer, en godkjent avsenderadresse, DNS administrativ tilgang og en eier for kampanjen. Inventar andre tjenester som allerede sender for domenet før du endrer postene.
GetResponses dokumenterte domenearbeidsflyt er under Profil > E-poster og domener. Tilpasset DKIM bruker en nøkkel og identifikator generert i kontoen. Ikke bruk en generisk velger fra en opplæring eller en nøkkel eksportert fra en annen konto. Det relevante spørsmålet er hvilket domene som signerer selve meldingen, ikke om en avsenderadresse har blitt lagt til.
Hold dette e-postdomenearbeidet atskilt fra nettsteds- og landingssidedomenekonfigurasjonen. Omdirigerer navneservere eller å koble til et nettsted er ikke nødvendig bare for å publisere en autentiseringspost hos den eksisterende DNS verten.
Generer og publiser DKIM posten
I E-postadresser åpner du domenets Handlinger-meny, velger Vis TXT poster og autentiser domenet ditt med DKIM . Kopier den viste identifikatoren og nøkkelen. Dokumentasjonen tilbyr også en 2048-biters nøkkel alternativet og advarer om at bekreftelse av generering ugyldiggjør eksisterende nøkkel og identifikator. Planlegg den handlingen som en koordinert rotasjon, ikke som en harmløs visningspreferanse.
Før du roterer, registrer gjeldende velger og signeringsstatus, identifiser personen som kan publisere DNS umiddelbart, og avtal hvordan kampanjer skal settes på pause eller gjenopprettes hvis valideringen mislykkes. Ikke anta at en gammel nøkkel forblir brukbar etter at produktet ugyldiggjør den. Løs eventuell overlapping eller tilbakeføringsevne med leverandøren før du blir avhengig av den.
Publiser den returnerte TXT eieren og fullfør verdien på den autoritative DNS tjenesten. Sjekk redaktørens suffiksregler og lang TXT-håndtering. En avkortet nøkkel, manglende velgertegn eller duplisert domene-suffiks kan gjøre en tilsynelatende lagret post ubrukelig. Hvis brukergrensesnittet ikke kan bevare hele verdien, skaff deg støttet DNS-vertsveiledning i stedet for å dele opp nøkkelen i uavhengige poster.
Gå gjennom automatisk oppsett før du godkjenner det
GetResponse dokumenterer også en automatisk flyt ved hjelp av Entri. Etter at en avsenderadresse er lagt til og bekreftet, velg Autentiser fra domenemenyen. Flyten kan vise de foreslåtte tekstpostene før den fortsetter, oppdage DNS leverandøren og be om relevant pålogging og bekreftelse. Manuell oppsett er fortsatt et alternativ hvis integrasjonen ikke kan fullføre jobben.
Den automatiske prosessen er dokumentert for å legge til tilpasset DKIM , en SPF TXT post og en p=none DMARC policy når en korrekt policy ikke allerede eksisterer. Inspiser de foreslåtte endringene mot eksisterende poster før du godkjenner dem. Automatisering fjerner ikke behovet for å bevare en håndhevet policy, unngå duplikat SPF poster eller gjennomgå tillatelser gitt til en DNS integrasjon.
Ikke anta at en vellykket integrasjonsbekreftelse beviser at hver forespurte post ble publisert hos rett eier. Sammenlign autoritative svar etterpå og behold det nøyaktige endringssettet. Hvis prosessen mislykkes halvveis, inspiser det som allerede er endret før du prøver på nytt, slik at et nytt forsøk ikke skaper konflikter eller skjuler gjenoppretting.
Forstå den separate SPF vedtaket
GetResponses SPF -side sier at avsenderdomenet allerede har SPF og det legger til en rekord til kundens synlige-Fra-domene er ikke nødvendig bare å sende gjennom tjenesten. Den gir kontovist SPF informasjon for kunder som velger å konfigurere den. Bruk disse gjeldende verdiene i stedet for å gjette en universell inkluderer.
Protokollskillet er viktig: SPF evaluerer konvoluttavsender domene, ikke det synlige Fra header. En tillatelse lagt til example.com kan ikke produsere justering hvis meldingen faktisk bruker et urelatert konvoluttdomene. En gyldig tilpasset DKIM signatur på linje med example.com kan levere DMARC -banen uavhengig. Bekreft hva meldingen gjør før du behandler en rot- SPF -endring som reparasjonen.
Hvis det er nødvendig med en legitim SPF oppdatering, se gjennom den eksisterende policyen og kostnadene for DNS-oppslag. Behold en enkelt gyldig kandidat SPF post hos den eieren og bevar andre godkjente avsendere. Ikke slå sammen to fulle v=spf1 -policyer eller opprett en andre TXT policy ved siden av den første.
Bekreft den faktiske kampanjen
Spør hver autoritative server for den eksakte DKIM eieren og sammenlign den fullstendige offentlige verdien med kontoen. Gjenta produktvalidering etter behov, slik at tidligere bufrede svar etter autoritativ publisering er korrekt. Send deretter et kontrollert nyhetsbrev gjennom den tiltenkte GetResponse-arbeidsflyten til en autorisert mottaker med tilgang til rå mottatte overskrifter.
Registrer synlig fra, konvoluttdomene, hver DKIM d= og s=, og klarerte mottakerautentiseringsresultater. Syntetisk eksempel: en melding har Fra news@example.com , SPF passerer for en leverandøreid konvolutt, og DKIM passerer med d=example.com. Det leverandøreide SPF passet er ikke justert til example.com , men DKIM -passet for eksakt domene kan tilfredsstille DMARC . Hvis signeringsdomenet i stedet eies av leverandøren, må du ikke kalle det suksess med tilpasset domene bare fordi DKIM selv har bestått.
Test hver vesentlig forskjellig fra domene og sendingsarbeidsflyt. Et nyhetsbrev sendt fra en annen adresse enn aksepteksemplet kan ha en annen domenekonfigurasjon. En vellykket DNS test er ikke en erstatning for denne verifiseringen på rutenivå.
Diagnostiser og oppbevar en gjenopprettingsjournal
Hvis nøkkelen mangler i DNS , reparer den eksakte eieren eller verdien. Hvis nøkkelen er riktig, men signaturen mangler eller bruker et annet domene, kontrollerer du valgt avsender og produktoppsett. Hvis autentiseringen går gjennom, men plasseringen er dårlig, undersøk samtykke, omdømme, innhold og mottakerpolicy separat; DKIM garanterer ikke plassering av innboks.
Behold den gamle konfigurasjonen, foreslåtte endringer, faktiske endringer, valideringsresultat og meldingsbevis. Ikke svekk en DMARC policy for hele domenet for å skjule en mislykket rotasjon. Denne veiledningen er basert på beholdt førstepartsdokumentasjon og syntetisk tolkning, ikke en live GetResponse-leietaker eller levert kampanje. Godkjenning av produksjon krever administratorens nåværende bevis og menneskelig godkjenning.
Bestem hva gjenoppretting betyr etter ugyldiggjøring
For skriftlig rotasjonssak GR-01, anta at administratoren bekreftet generering av 2048-bits alternativet, den nye kontoidentifikatoren er demo-ny og sonen inneholder fortsatt bare demo-gammel. Ingen gjeldende offentlig nøkkel eller mottatt signatur er observert. Kampanjeeieren setter den berørte utgivelsen på pause mens DNS eieren henter og publiserer den eksakte nygenererte verdien hos den påkrevde eieren. Å publisere en gammel verdi på nytt er ikke en støttet gjenopprettingsantakelse etter den dokumenterte ugyldiggjøringen; spør leverandøren om en gjenopprettbar signeringstilstand før du stoler på den. Lukk kun etter autoritativ sammenligning og en kontrollert kampanje hvis faktiske d=/s= og pålitelige resultat møter aksept. Ingen nøkkelgenerering, DNS -redigering eller -sending skjedde for dette eksemplet.
Bevar håndhevingsgrensen
RFC 9989 Seksjon 7.4 krever gyldig DKIM , ikke SPF alene, for domener som publiserer p=reject, og advarer om interoperabilitet mellom indirekte e-post og e-postlister. En enkelt vellykket test med direktemeldinger er ikke et bevis på at alle legitime ruter er klare for sterkere politikk. Behold eksisterende godkjent beskyttelse mens du diagnostiserer det faktiske gapet; enhver politikkendring trenger sin egen beslutning.