Bruk kontokonfigurasjonen som utgangspunkt
Sendloop gir en kontoarbeidsflyt for autentisering av sender-domene, mens veiviseren for offentlig autentisering også nevner dedikerte DKIM og justering innstillinger. Disse sidene fastslår at autentisering er tilgjengelig, men de etablerer ikke nøyaktig postsett, signeringsidentitet eller konvoluttkontroller for en bestemt konto. Denne veiledningen tar deg gjennom den dokumenterte kontoarbeidsflyten og en kontrollert verifiseringsplan. Et dedikert DKIM arrangement eller tilpasset konvoluttkrav forblir et leverandørbekreftelseselement. Sendloop-autentiseringsveiviser, DKIM og innstillinger for domenejustering.
Identifiser først kontoen, godkjente Fra-domener og kampanjene eller automatiseringene som bruker hver enkelt. Registrer om kontoen har en dedikert leveringsordning og hvem som kan bekrefte det. Ikke utlede dedikert infrastruktur fra en prisetikett, en gammel onboarding-e-post eller en tredjeparts liste over sende-IP-er. Tildel en Sendloop-administrator, en DNS eier og en anmelder for organisasjonens DMARC politikk.
Før du gjør endringer, eksporter gjeldende DNS oppføringer for de relevante eierne. Behold én representant mottatt melding fra den eksisterende godkjente ruten hvis tilgjengelig. En oversikt over hva som allerede fungerer forhindrer at et nytt autentiseringsprosjekt ved et uhell deaktiverer en annen avsender. Målet er en autentisert og justert Sendloop-rute, ikke en grossisterstatning av domenets e-postkonfigurasjon.
Åpne avsenderens domenekontrollpanel
Leverandørens guide leder deg gjennom Innstillinger > Avsenderdomeneautentisering > Autentiser avsenderdomene, deretter Legg til domene. Det resulterende domenekontrollpanelet gir kontorelevante verdier og en Check DNS Records-handling. Ta opp det utdata før du redigerer DNS . Hvis gjeldende grensesnitt er forskjellig, bruk gjeldende leverandørinstruksjoner eller støtte i stedet for å gjette tilsvarende knapper. Sendloop-guide, bruk av e-postautorisasjonsveiviseren og sjekk autentiseringsoppsettet ditt.
Registrer hver full eier, DNS type, verdi og TTL med dens formål. Hold det viste postsettet knyttet til endringsbilletten. Hvis panelet viser en manglende post, avgjør om den er fraværende, publisert hos feil eier eller tilstede med en annen verdi. Et domene som allerede er konfigurert for en annen Sendloop-konto kan trenge leverandørkoordinering i stedet for erstatning.
Den offentlige veilederen har en SPF eksempel og en eksisterende rekord endring som ikke liste identiske inkluderer. Den beskriver også klargjøring av tekstfiler. Ikke gjør noen av detaljene til en automatisk produksjonsoppskrift. DNS må inneholde gjeldende, gjeldende policy; en tekstfil lagret på en arbeidsstasjon publiserer den ikke. Løs eventuelle avvik mellom kontopanelet og den offentlige siden før implementering. Sendloop-guide, Sett opp SPF posten.
Gjennomgå SPF uten å utvide urelaterte tillatelser
Bestem hvilket konvoluttdomene den virkelige Sendloop-meldingen bruker. Det er identiteten som skal undersøkes for SPF , i stedet for å anta at det synlige From-domenet må være evalueringseieren. Hvis det finnes en autorisert tilpasset konvoluttordning, ta opp de utstedte innstillingene og omfanget. Hvis den ikke gjør det, registrer den observerte leverandørens konvoluttidentitet og evaluer DKIM justeringen separat.
Ved enhver eier som endres, behold én enkelt SPF policy og bevar autorisasjoner som kreves av andre aktive avsendere. Gjennomgå nestede DNS oppslag før du legger til nye termer. SPF ti-tidsgrense gjelder for mekanismer og modifikatorer som forårsaker DNS oppslag under evaluering, ikke for antall ord som er synlige i posten. Eksisterende permissive mekanismer er også verdt å vurdere, men å fjerne dem er en egen avhengighetsbeslutning. RFC 7208 , avsnitt 4.5 og 4.6.4.
Ikke kopier en bred prøvepolicy som erstatning for den eksisterende posten. Å gjøre det kan autorisere uønskede verter, endre feilkvalifiseringen eller fjerne en annen leverandør. Når den nødvendige autorisasjonen ikke kan passe trygt, stopp og be e-posteieren velge et støttet design. Ikke løs problemet ved å publisere en annen SPF policy eller slette tjenester som tilfeldigvis er ukjente.
Publiser kun det utstedte offentlige DKIM materialet
Bruk eieren og den offentlige verdien som er oppgitt for denne kontoen. Den offentlige veiledningen viser et DKIM TXT oppsett, men demonstrasjonsnøkkelen er ikke kundens nøkkel. Hvis panelet eller støtten leverer et annet støttet postskjema, behold instruksjonen i stedet for å konvertere den uten bevis. Sendloop-guide, Sett opp DKIM posten.
Bare den offentlige bekreftelsesnøkkelen hører hjemme i DNS . DKIM lager en kryptografisk signatur med en privat nøkkel; den legger ikke inn den private nøkkelen i den utgående meldingen. Den offentlige veilederens uformelle forklaring skal ikke leses som en forespørsel om å dele signeringshemmeligheter. Meldingen har en signatur, og verifikatoren bruker den offentlige nøkkelen identifisert av signeringsdomenet og velger. RFC 6376 , avsnitt 3.5 og 6.1.
Sjekk den foreslåtte eieren for en aktiv nøkkel som tilhører en annen rute. En kollisjon krever koordinering; det er ikke trygt å overskrive en fungerende velger bare for å fjerne en rød status. Bekreft det fullstendige navnet etter publisering, inkludert domene-suffikset lagt til av DNS editoren. Behold tidsstempler og søkeresultater slik at senere rapporter kan skille en gammel cache fra en feil eier eller nøkkel.
Hold koblingsmerking utenfor konklusjonen om justering
Leverandørveiledningen beskriver en valgfri CNAME for aliasede meldingskoblinger. Hensikten er link branding, ikke bevis på at SPF eller DKIM stemmer overens. Implementer det bare hvis den relevante sporingsendringen er godkjent og kontoen oppgir det nøyaktige målet. Sendloop-guide, VALGFRITT: Sett opp CNAME posten.
Sjekk eksisterende nettside eller spor bruk før du gjør krav på den foreslåtte eieren. Ikke pek rotnettstedet eller et live-applikasjonsvertsnavn mot et sporingsmål. Hold en harmløs testkobling i den kontrollerte kampanjen slik at anmelderen kan bekrefte både destinasjonen og vertsnavnet som vises. Autentisering og lenkefunksjon er separate akseptkontroller; en merket lenke som fungerer, etablerer ikke en gyldig signatur.
Gå tilbake til kontoens DNS sjekk etter publisering. Sammenlign hvert viste resultat med et uavhengig offentlig oppslag. Registrer ventende stater ærlig talt. Hvis en konto vises bekreftet mens den eksterne testen fortsatt mislykkes, la endringen være åpen og bruk meldingsbeviset for å finne den gjenværende grensen.
Samle en mottatt meldingsidentitetspost
Send gjennom selve kampanjearbeidsflyten til kontrollerte eksterne postkasser uten kundedata. Gjenta for vesentlig forskjellige From-domener eller leveringskonfigurasjoner. Ta vare på den opprinnelige meldingen og pålitelige mottakerresultater, sammen med en meldings-ID og UTC-tidsstempel. Registrer alle DKIM signaturer i stedet for å stoppe ved den første signaturen som passerer.
Bevisposten skal inneholde den synlige Fra-domenet, autentisert konvoluttidentitet, Return-Path, DKIM d= og s= verdier, SPF og DKIM utfall og mottakerens DMARC resultat. Fastslå hvilken overføringsmekanisme som stemmer overens med Fra-domenet. Avslappet og streng justering påtvinger forskjellige domenesammenlikninger; registrere modusen som er i bruk. RFC 9989 , Identifikatorjustering forklart.
Hvis den eneste beståtte signaturen bruker et ikke-relatert leverandørdomene, be om det støttede kundedomene-signeringsalternativet og aktiveringsbetingelsene. Den offentlige veiviserens dedikerte DKIM-kontaktnotat beviser ikke at alternativet er aktivert, gratis, tilgjengelig på alle planer eller konfigurert automatisk. Få disse svarene for den nøyaktige kontoen. Ikke representer et sporingsalias som et alternativt konvoluttdomene.
Bruk feilen til å velge neste kontroll
For en savnet DKIM signatur, bekreft kontoen, velg Fra identitet og leverandøraktivering. For en signaturfeil, sammenligne den observerte velgeren og den offentlige nøkkelen før du undersøker nedstrømsendringer av signert innhold. En test med en annen avsenderadresse kan lykkes mens den berørte kampanjen fortsatt mislykkes, så hold arbeidsflyten konstant under diagnosen.
For SPF feil, identifiser det evaluerte domenet og den endelige sendekilden. For SPF bestått med DMARC feil, inspiser justeringen i stedet for å legge til flere SPF inkluderer. Hvis leverandøren ikke kan dokumentere nødvendig identitetsalternativ, hold dette kravet blokkert og vurder en annen støttet rute med bedriftseieren. Ikke senk policyen for et helt domene bare for å få en leverandørs test til å slutte å mislykkes.
Forbered en støttepakke som inneholder kontoidentifikasjon, det berørte domenet, utstedte offentlige registre, observerte DNS svar, meldings-ID, tid og relevante mottakerresultater. Ekskluder passord, API-nøkler, mottakerlister og ikke-relatert meldingsinnhold. En kortfattet reproduserbar feil er mer nyttig enn flere ukorrelerte skjermbilder av DNS redigeringer.
Gjenoppretting og aksept av arbeidsark
Bruk Sendloop-autentiseringsarbeidsarket (opprett en egen gjennomgangspost med feltene beskrevet her) for å spore postavviksgjennomgangen, bekreftelse av dedikerte funksjoner og endelig identitetssammenligning. Et manglende konvoluttfunksjonssvar kan forbli eksplisitt uløst selv når vanlig justert DKIM fungerer. Definer aksept mot forretningskravet i stedet for å fylle alle tomrom med en antagelse.
Hvis endringen mislykkes, pause berørte sendinger og gjenopprett den tidligere godkjente konfigurasjonen gjennom den registrerte endringsplanen. Koordinere DKIM endringer med leverandøraktivering; sletting av en offentlig nøkkel mens tjenesten fortsatt signerer med den, skaper en ny feil. Når du avbryter Sendloop, må du bekrefte at alle kampanjer og automatiseringer har stoppet og gjennomgå delte SPF avhengigheter før du fjerner tillits- eller sporingsposter.
Fiktivt utført eksempel på et SPF avvik
Kun fiktiv skriftlig sak: SLP-01 antar tiltenkt Fra offers@workshop.example . Det offentlige eksemplet inneholder to leverandørinkluderinger, mens den eksisterende policyinstruksjonen heter én; nåværende kontoautorisasjon, konvoluttidentitet og DKIM / SPF resultater er ukjente. DNS eieren holder endringen og ber kontoeieren om å få rutespesifikk bekreftelse. En tekstfil og en merkevarekobling etablerer ikke autentisering. Etter avklaring, ville teamet gjennomgå én policy og samle inn en kontrollert kampanjemelding. Ingen konto-, DNS eller sendetest ble utført.
Dokumentar dekning og gjenværende porter
Dette utkastet dekker arbeidsflyten for offentlige kontoer og sikker verifisering. Den etablerer ikke et universelt dedikert DKIM eller tilpasset Return-Path , og det hevder ikke at en direktejustert Sendloop-melding har blitt inspisert. Disse kontoavhengige detaljene, live DNS og header-bevis, uavhengig gjennomgang, visuell gjennomgang og menneskelig SMB-godkjenning forblir påvente. Hold det opprinnelige fulle implementeringsomfanget på vent til det nødvendige kontobeviset lukker hullene.
Skille en bestått melding fra håndhevingsberedskap
RFC 9989 Avsnitt 7.4 krever gyldig DKIM for en domenepublisering p=reject og advarsler om interoperabilitet med indirekte e-post. Et enkelt justert SPF resultat rettferdiggjør ikke i seg selv en utrulling av avvisningspolicy. Gå gjennom alle legitime ruter og policyeierskap separat fra dette leverandøroppsettet.