Adskil postkassemigrering fra godkendelse
Proton Mail , tidligere almindeligvis kaldet ProtonMail, understøtter tilpassede domæneadresser på betalte planer. Dens brugerdefineret domæne guide adskiller domænebekræftelse, adresseoprettelse, MX ændringer og godkendelse. Planlæg disse som særskilte acceptelementer. Modtagelse af en besked i den nye postkasse beviser ikke, at udgående post har den tilsigtede signatur, og en DKIM check beviser ikke, at enhver virksomhedsadresse eksisterer efter en migrering.
Start med en adresseopgørelse: individuelle brugere, aliaser, delte forretningsdestinationer, automatiserede afsendere og svaradresser. Identificer enhver tjeneste, der sender med det samme domæne uden at gå gennem Proton. Tildel en person til postkasseafskæringen og en anden til at gennemgå DNS hvor det er praktisk. Registrer de eksisterende MX og autentificeringsposter, det godkendte ændringsvindue og den beslutningstager, der kan stoppe cutover.
Proton anbefaler specifikt at oprette tilsvarende adresser før flytning MX poster. Dette er vigtigt, fordi meddelelser om manglende adresser ikke fortsætter med at nå den tidligere tjeneste, når indgående routing er ændret. Brug migrationssekvens for kontoen, og verificer kritiske destinationer med kontrollerede meddelelser, før den modtagende side erklæres for komplet.
Registrer det nøjagtige domæne og udstedte værdier
Åbn det tilsigtede domæne i Protons domæneindstillinger, og behold godkendelsesinstruktionerne, der vises for det. Skelne domæneejerskabsbekræftelsesposten fra SPF, DKIM og DMARC. De besvarer forskellige spørgsmål og bør have separate bevisfelter. Erstat aldrig værdierne på kontoen med en anden organisations offentliggjorte poster.
DNS administratoren skal registrere det fulde ejernavn, posttype og forventet værdi for hver post. Sammenlign disse med DNS editorens suffikshåndtering, og undersøg derefter de offentliggjorte svar. En etiket kan være visuelt korrekt i et kontrolpanel, men vises med det forkerte fuldt kvalificerede navn. Hold urelateret TXT registreringer og registrere enhver eksisterende brug af de foreslåede DKIM ejere, før du foretager ændringer.
Hvis domænet allerede bruges af et CRM-system, et websted eller et faktureringssystem, skal du angive disse afsendere nu. Flytning af personalepost til Proton autentificerer ikke en separat applikations direkte levering. Enten skal den pågældende ansøgnings godkendte rute have sin egen gyldige godkendelse, eller også skal en eksplicit designet indsendelsesrute implementeres og testes. Behandl usikre afsendere som lagerhuller, ikke grunde til at svække domænets politik med det samme.
Bevar én sammenhængende SPF politik
Protons anti-spoofing dokumentation identificerer include:_spf.protonmail.ch som sin SPF autorisation og forklarer, hvordan den inkorporeres i en eksisterende politik. Brug kontoens anbefalede registrering og domænets komplette afsenderbeholdning til at forberede den endelige værdi. Udgiv ikke en anden politik for den samme ejer eller kasser godkendelsen til en anden legitim rute under en migrering.
Vurder hele politikken i forhold til SPF 's DNS-opslagsregler. Vælg den endelige kvalifikation bevidst i stedet for at behandle et kopieret eksempel som en organisationsdækkende politisk beslutning. Et SPF resultat er autentificeringsbevis; modtagende systemer træffer deres egne håndteringsbeslutninger. Hold den tidligere politik tilgængelig for en godkendt gendannelsesændring, og bemærk, hvornår cachelagrede versioner muligvis stadig er i brug.
Behold hele DKIM rotationsopsætningen
Proton bruger tre CNAME poster for automatisk DKIM rotation. Dens vejledning til domænegodkendelse instruerer kunderne i at beholde alle tre, matche guiden nøjagtigt og vente på registrering, før udgående signering af brugerdefineret domæne starter. En tilsyneladende ledig vælger kan kræves til en senere rotation. Fjern den ikke, fordi en enkelt testmeddelelse kun bruger én signaturvælger.
Hvis verifikationen mislykkes, skal du sammenligne hver ejer og målkarakter for karakter. Protons CNAME fejlfindingsvejledning identificerer forkerte værdier, registratorhåndtering af en efterfølgende periode og en gammel manuelt styret TXT post som mulige problemer. Undersøg den faktiske konflikt, før du sletter noget. En TXT post ved en anden vælger kan tilhøre en anden legitim afsender og er ikke automatisk forældet.
Hvor kontoen flytter fra Protons gamle manuelle nøgle-arrangement, planlæg den dokumenterede overgang omhyggeligt. Proton advarer om en signeringsafbrydelse, når den gamle TXT post fjernes. Forbered alle udskiftningsværdier og en kontrolleret test på forhånd, koordiner ændringsvinduet, og udgiv den nødvendige udskiftning omgående. Dette er ikke en anbefaling om at slette alle DKIM TXT poster i zonen.
Test personalemail og ansøgningsindsendelse separat
Send nye beskeder fra repræsentative tilpassede domæneadresser gennem de ruter, organisationen bruger. Optag klienten eller applikationen, Fra-adresse, tid og meddelelses-ID. På en kontrolleret ekstern modtager skal du fange de betroede SPF , DKIM og DMARC resultater, SMTP retur-sti og DKIM d= og s= værdierne. Signaturens domæne og vælger identificerer det offentlige nøgleopslag beskrevet af RFC 6376.
For en enhed eller forretningsapplikation dokumenterer Proton en separat SMTP-indsendelsesfunktion for betalte planer med tilpassede domæneadresser. Dens SMTP guide bruger adressespecifikke SMTP tokens, ikke den almindelige postkasseadgangskode, og forklarer, at SMTP-indsendt post ikke er ende-til-ende-krypteret. Bekræft funktionsberettigelse og den autoriserede adresse, før du konfigurerer en applikation. Oprettelse af legitimationsoplysninger og vedvarende adgang kræver deres egen sikkerhedsgodkendelse; ingen token bør vises i bevisprojektet.
Optag et separat resultat for hver applikation, selvom en webmail-test for personalet består. Et vellykket login til en indsendelsesserver beviser hverken den endelige synlige afsender eller modtagerens godkendelsesresultat. Hvis en printer eller CRM fejler før indsendelse, skal du løse det forbindelsesproblem, før du diagnosticerer DKIM . Hvis det afsendes med succes, skal du følge den resulterende meddelelse til den kontrollerede modtager.
Indstil DMARC politik fra observerede ruter
Gennemgå domænets eksisterende DMARC politik og rapporteringsdestination med dets ejer. Bevar en etableret politik, medmindre en separat godkendt ændring er nødvendig. Et justeret bestået SPF eller DKIM resultat kan opfylde DMARC , som defineret i RFC 9989. Tjek den faktiske justering tilstand i stedet for at antage, at hvert relaterede underdomæne er kvalificeret.
Før du øger håndhævelsen, skal du tage højde for direkte ansøgninger, videresendelsesordninger og brug af postlister, som virksomheden er afhængig af. En overvågningsperiode bør have en ejer og et revisionsresultat, ikke blive en ubestemt erstatning for undersøgelse. Samlede rapporter kan guide opdagelsen, men de erstatter ikke rutespecifikke overskrifter eller beviser indbakkeplacering for hver modtager.
Proton Mail accept arbejdsark
Opret en række for hver personalemail eller ansøgningsrute:
- Domæne-, lejer-ejer og adressebeholdningsrevision: ____.
- Domænebekræftelse, adresseoprettelse og MX cutover bevis: ____.
- Eksisterende afsendere bibeholdt i SPF gennemgangen: ____.
- Udstedt DKIM CNAME sæt og alle tre offentliggjorte ejerchecks: ____.
- Ældre manuel-nøglekonflikt og godkendt overgangsplan, hvis nogen: ____.
- Rute, klient eller enhed og autoriseret Fra-adresse: ____.
- Applikations- SMTP -adgangsgodkendelsesreference, eksklusive hemmeligheder: ____.
- Message-ID, UTC-tid, Return-Path og DKIM d=/s=: ____.
- Pålidelige godkendelsesresultater, justering og kontrol af forretningskvitteringer: ____.
- Gendannelsesejer, uafklarede undtagelser og revisionsbeslutning: ____.
Fiktiv diagnose efter en DNS oprydning
Kun fiktivt eksempel: Juniper Accounts fjerner to Proton CNAME'er, fordi dens seneste besked bruger den tredje vælger. Senere bliver godkendelsen inkonsekvent. Mailadministratoren sammenligner zonen med det komplette udstedte sæt i stedet for at tilføje en ny roddomæne- SPF politik. De manglende CNAME'er gendannes gennem den godkendte ændringsproces, Protons tilstand kontrolleres igen, og nye meddelelser fastslår, om signering er genoprettet.
Dette eksempel illustrerer, hvorfor rotationsafhængigheder hører hjemme i opgørelsen. Det er ikke en observeret proton-hændelse, og ingen Juniper-postkasse eller DNS zone blev tilgået.
Behold beviser for den næste ændring
Hold udstedte optegnelser, offentlige DNS tjek og redigerede modtagne overskrifter sammen. Genbekræft efter ændringer af DNS-vært, adressemigrering, nøgleovergangsarbejde eller nye applikationsruter. Live kontoinspektion, registreringsudgivelse, kontrolleret afsendelse, gengivet visuel gennemgang, menneskelig SMV-godkendelse og offentliggørelse er ikke blevet afsluttet af denne artikel. Disse porte forbliver afventende, selv når dokumentarproceduren er afsluttet.
Adskil sendeadgang fra indbakkeadgang
Proton beskriver SMTP indsendelse som kun afsendelse; at modtage gennem en tredjeparts desktop-klient er en separat Bridge-arbejdsgang. En vellykket ansøgningstest etablerer ikke indbakkesynkronisering. Behold et særskilt godkendt token pr. applikation, så en tilbagekaldt enhed ikke unødigt afbryder andre klienter. Dette er en anbefaling om adgangsdesign; ingen legitimationsoplysninger blev oprettet eller konfigureret.
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.