Lagerdomener etter server og applikasjon
SocketLabs-autentisering bør gjennomgås for serveren eller underkontoen som faktisk sender meldingen. Start med en liste over applikasjoner, synlig fra domener og SocketLabs-konfigurasjonen hver applikasjon bruker. Inkluder forskjellige fra underdomener, kundemerker og reserveruter. Ett fungerende merke er utilstrekkelig bevis for en server som sender på vegne av flere organisasjoner.
Leverandøren krever verifiserte sendedomener og dokumenterer en feil når en adresse ikke er tillatt. Den støtter eierskapsverifisering gjennom en adressebekreftelsesprosess eller kvalifiserte DNS autentiseringsfunksjoner, samtidig som den legger merke til at kontokonfigurasjon og plan påvirker bruken av sendingsdomenekontroller. SocketLabs sender domener, legger til og bekrefter et sendedomene.
Separat tillatelse til å sende fra autentisering hos mottakeren. Et domene kan få lov til å sende uten ønsket kundedomene DKIM eller konvoluttidentitet som brukes. Registrer disse som uavhengige sjekker og innhent domeneeierens tillatelse før du godkjenner en kunde- eller partneridentitet.
Velg DKIM -metoden med nøkkeleieren
SocketLabs dokumenterer tre metoder: en kundelevert TXT nøkkel, en leverandørgenerert TXT nøkkel og en leverandøradministrert CNAME. Valget endrer hvem som administrerer nøklene og hvordan de vedlikeholdes på tvers av servere. Den nåværende oversikten sier at signering krever samsvar med From-identiteten. SocketLabs DKIM oversikt, de tre signeringsmetodene.
Registrer beslutningen før DNS arbeidet starter. For en leverandøradministrert metode, identifiser hvem som kan endre signeringskonfigurasjonen. For en kundekontrollert metode, identifiser den private nøkkeldepotmannen og godkjent rotasjonsprosess. Et regneark fullt av nøkler er ikke en akseptabel eierskapspost. Arbeidsarket skal inneholde en bevisreferanse og ansvarlig person, ikke hemmelig materiale.
Ikke velg den mest komplekse metoden automatisk fordi den viser flere kontroller. Foretrekk den støttede tilnærmingen som oppfyller organisasjonens krav og kan vedlikeholdes av dens faktiske operatører. Hvis policyen krever en spesiell nøkkelhåndteringsordning eller uvanlig signeringsidentitet, innhent leverandørbekreftelse før du presenterer konfigurasjonen som støttet.
Konfigurer den valgte signeringsmetoden
For CNAME signering beskriver den offisielle veiledningen én delegert DNS post og verifisering på kontosiden før funksjonen aktiveres. CNAME guiden viser dkim. _domainkey under avsenderdomenet som peker til dkim._domainkey.email-od.com . Sammenlign det offentlige dokumenterte paret med gjeldende kontoinstruksjoner; ikke overskriv en okkupert velger bare fordi eksemplet samsvarer med navnet. Hvis DNS verten ikke kan støtte den nødvendige understrekingen i CNAME eieren, leder veiledningen brukerne mot TXT tilnærmingen i stedet for en oppfunnet stavemåte. SocketLabs CNAME signeringsveiledning.
Sjekk om den tiltenkte velgereieren allerede er brukt av en annen tjeneste. En CNAME kan ikke limes inn over en ikke-relatert velger. Be om et støttet alternativ eller en godkjent migrering i stedet. Bevar den eksisterende posten, dens avhengige tjenester og endringsbeslutningen i implementeringsbilletten.
TXT guiden skiller genererende nøkler i plattformen fra å ta med et nøkkelpar. Den krever den offentlige nøkkelen i DNS og verifiserer denne nøkkelen før du lagrer de relevante innstillingene. Den genererte nøkkelflyten beholder sin private komponent på kontoen. SocketLabs TXT signeringsveiledning.
Bruk en godkjent arbeidsflyt for hemmelig håndtering hvis den valgte metoden innebærer import av privat materiale. Publiser bare den offentlige nøkkelen. Registrer det nøyaktige domenet og velgeren og inspiser den resulterende logiske TXT verdien etter en eventuell DNS-editor-strengdeling. Den genererte nøkkelguiden sier at den offentlige nøkkelen ikke lenger er tilgjengelig i portalen etter vellykket DNS publisering og lagring. Ta vare på den offentlige posten og dens opprinnelse før du lukker oppsettsbilletten, uten å beholde den private nøkkelen i anmeldelsespakken.
Konfigurer returdomenet som en separat kartlegging
SocketLabs implementerer kundedomene SPF gjennom sin egendefinerte bounce-domene-modell uten å kreve et tillegg til den eksisterende synlige-Fra SPF rekord. Guiden spesifiserer en CNAME fra det valgte avvisningsunderdomenet til tracking.socketlabs.com . Flere returoppføringer kan konfigureres; umatchet e-post bruker den valgte standarden eller reserveleverandøren. SocketLabs egendefinerte returguide, oppsett og flere tilpassede sprettdomener.
Velg et ubrukt navn med DNS administratoren og bekreft den støttede tilordningen på den faktiske serveren. Hold domenets vanlige konfigurasjon for inngående e-post intakt. Et returvertsnavn er en applikasjonsleveringsidentitet og må ikke forveksles med en brukers svarpostboks eller nettstedets sporingsendepunkt.
Registrer det tiltenkte treffet for hvert From-domene, og registrer deretter standardoppførselen. Standardverdier fortjener eksplisitt forretningsgjennomgang på en server med flere merker: vellykket levering kan fortsatt avsløre en uventet merkevare eller leverandøridentitet. Ikke utlede den aktive tilordningen fra navnene i konfigurasjonen alene. Den utgitte Return-Path er beviset for å sammenligne senere.
Publiser og sammenlign de offentlige registrene
Eksporter de relevante DNS postene før du gjør den godkjente endringen. Bekreft den autoritative tjenesten og DNS redaktørens håndtering av pårørende navn. Inspiser hver publisert eier uavhengig, inkludert CNAME kjeden eller TXT svaret. En korrekt DKIM post beviser ikke at avvisningsnavnet er konfigurert, og en korrekt avvisningspost beviser ikke at DKIM signering er aktiv.
SPF evalueres ved hjelp av SMTP -konvoluttidentiteten, ikke bare den synlige Fra. Hvis en annen tjeneste fortsatt trenger rotdomenets SPF policy, bevar den. Ved enhver eier der det kreves en SPF policy, oppretthold én policy og kontroller protokollens grense for DNS-spørring. RFC 7208 , avsnitt 2.4, 4.5 og 4.6.4.
Vent på konsistente autoritative og rekursive svar der cacher er involvert. Hvis leverandøren ikke kan bekrefte en rekord, lagre den utstedte verdien og tidsbestemte DNS observasjoner for støtte i stedet for å endre navnet gjentatte ganger. En DNS-vertsbegrensning bør håndteres gjennom en dokumentert støttet metode.
Test hvert eksakt From-domene og returtreff
Send harmløst innhold gjennom hver materialapplikasjon og server til kontrollerte eksterne mottakere. Ta vare på tid, meldings-ID og leverandørens eller applikasjonshendelsesreferansen. Test fra underdomener separat i stedet for å anta at en oppføring for det overordnede domenet dekker dem.
Den eldre CNAME siden nevner PRA og Sender i sin anvendelighetsbeskrivelse, mens gjeldende oversikt og TXT side beskriver et eksakt From-treff. Hvis applikasjonen bruker en egen avsenderoverskrift eller annen uvanlig identitet, få avklaring og test det eksakte skjemaet. Ikke oversett de forskjellige uttalelsene til en universell regel.
Registrer synlig fra, Return-Path , pålitelig SPF identitet og resultat, hver DKIM -d og s, og DMARC resultat. DKIM verifisering bruker domenet og velgeren i selve signaturen for å finne den offentlige nøkkelen. RFC 6376 , avsnitt 3.5 og 6.1.
Sammenlign hver forbipasserende identitet med den synlige From under den aktuelle justering modus. Et tilpasset sprett-underdomene kan møte en avslappet SPF justering uten å oppfylle streng likhet. En justert pasning DKIM signatur kan uavhengig tilfredsstille DMARC . Verken vellykket domeneverifisering eller et leverandør-domenegodkjenningspass er nok til å utlede hele resultatet. RFC 9989 , Identifier Alignment Explained og DMARC -evaluering.
Diagnostiser det sviktende laget
For en avsender-ikke-tillatt-feil, inspiser verifiseringen og de riktige serverens domenekontroller før du endrer DNS nøkler. For et uventet signeringsdomene, sammenligne den eksakte From med den konfigurerte DKIM oppføringen. For en uventet Return-Path , inspiser avvisningsmatchen og standard. Hold disse sjekkene adskilt slik at en reparasjon på en ikke skjuler et problem i en annen.
Hvis kryptografisk verifisering mislykkes til tross for riktig DNS , undersøk endringer i signert innhold eller overskrifter langs banen. Hvis autentisering og justering passerer, men innboksplasseringen er dårlig, undersøk mottakerens filtrering, omdømme og meldingens formål. Autentisering lover ikke levering eller gjør enhver bruk av en autorisert konto legitim.
Registrer gjenoppretting før utgivelse
Fullfør SocketLabs-domene- og serverarbeidsarket (opprett en egen gjennomgangspost med feltene beskrevet her). Ta vare på en rute-for-rute-matrise med tillatelse, signeringsmetode, avvisningskartlegging og mottatt bevis. Identifiser hvem som kan sette programmet på pause eller gjenopprette en tidligere godkjent serverkonfigurasjon hvis testing mislykkes.
Ikke slett gamle offentlige nøkler eller returposter mens meldinger i kø eller andre servere er avhengige av dem. Planlegg pensjonering med applikasjonseieren og test på nytt etter endringer i Fra-domenet, serveren, nøkkelmetoden, returstandarden eller DNS leverandøren.
Fiktivt diagnostisk tilfelle som involverer en standard returoppføring
Kun fiktiv skriftlig sak: SOCK-01 forutsetter at én server sender fra news@alpha.example med konvolutt bounces.alpha.example og et bestått SPF resultat. En andre rute bruker From news@beta.example , men faller tilbake til bounces.alpha.example , også med SPF pass. Under avslappet justering justeres den første angitte konvolutten; den andre ikke. Begge DKIM resultatene er ukjente, så det kreves verken en fullstendig feil med andre melding eller en vellykket reparasjon. Servereieren må godkjenne og bekrefte betaens tilordning, og deretter inspisere dens utsendte Return-Path og DKIM . Ingen server-, DNS eller meldingstest ble utført.
Godkjenning gjenstår
Godta ruten når den tiltenkte serveren tillater domenet, den valgte signeringsmetoden verifiserer, hver avvisningskartlegging oppfører seg som godkjent og mottakerbevis etablerer det nødvendige justerte passet. Godkjenning av originalomfang, levende leietaker- og DNS kontroller, uavhengig teknisk gjennomgang, visuell gjennomgang og menneskelig SMB-godkjenning gjenstår for dette upubliserte utkastet.
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.