Bekreft at TransIP er autoritativ
Dette er en DNS -publiseringsveiledning, ikke en onboarding-guide for TransIP-posttjenester. Et domene kan registreres hos TransIP mens det er autoritativt navneservere er andre steder. Sjekk domenets offentlige delegering og identifiser den autoritative sonen før redigering. Ikke bytt navneserver bare for å gjøre et DNS skjema tilgjengelig. Få avsenderens eksakte postnavn, typer og verdier, sammen med eksisterende soneeksport og et godkjent endringsomfang.
Skriv inn navn og verdier riktig
Velg domenet i kontrollpanelet og åpne DNS innstillinger. Tilpasset redigering krever at de automatiske TransIP-innstillingene er av. Å aktivere disse innstillingene på nytt kan overskrive egendefinerte poster og navneservere. Navn-feltet bruker @ for sonespissen og relative navn for underdomener. En ekstern CNAME målet trenger fullt navn og etterfølgende prikk. Disse grensesnittreglene er dokumentert i TransIP-kontrollpanelkilden nedenfor.
For en TXT DKIM nøkkel, instruerer DKIM kilden brukere om å utelate omkringliggende anførselstegn og unødvendige skråstreker. Bruk avsenderens offentlige nøkkel, aldri en generert prøve. EN velger på et avsendende underdomene trenger det underdomenet i det relative eiernavnet. Bruk bare CNAME når avsenderen faktisk utstedte en CNAME delegasjon. Å publisere en nøkkel får ikke en sendetjeneste til å begynne å signere.
Originalt regneark for registreringskartlegging
Følgende er en fiktiv kartleggingsøvelse for sonen example.org , ikke en produksjonskonfigurasjon. En fullstendig DKIM review._domainkey.news.example.org -kart å vurdere. _domainkey.news i Navn-feltet. EN DMARC eier _dmarc.news.example.org kart til _dmarc.news. De SPF eier news.example.org tilordner nyheter. Merk det forventede fulle navnet på endringsbilletten slik at en anmelder kan oppdage et utilsiktet suffiks example.org.example.org .
Behold SPF og DMARC som TXT policyer ved de riktige eiernavnene. Ikke legg inn en fullstendig sonefillinje, inkludert klasse og type, i Verdi-feltet. Flere TXT poster kan eksistere side om side for ikke-relaterte formål, men to SPF policyer ved ett evaluert navn er ikke gyldige. Lange DKIM verdier krever forsiktig håndtering: de hentede TransIP-sidene etablerer ikke en universell langstrengsdelingsprosedyre. Hvis panelet avviser leverandørens fulle verdi, stopp og innhent gjeldende TransIP-veiledning i stedet for å avkorte den.
Bekreft publikasjonen før du tester e-post
Spør hver autoritative server for de fullstendige SPF , DMARC og velgernavnene. Sammenlign fullstendige verdier, inkludert sammenkoblede TXT strenger der de returneres. For en delegert nøkkel, verifiser CNAME målet og det endelige TXT svaret. Gjenta gjennom en rekursiv resolver og behold TTL-observasjoner. En korrekt kontrollpanelskjerm med et fraværende offentlig svar kan indikere feil autoritet eller ulagrede data, ikke bare langsom forplantning.
Først da utløses en kontrollert melding gjennom avsendertjenesten. Tilbakerulling på DNS-siden bør gjenopprette de endrede postene, ikke aktivere automatiske innstillinger på nytt eller gjenopprette en hel gammel sone uten å sammenligne urelaterte endringer.
Bevis identiteten hos mottakeren
Bruk en kontrollert ekstern postkasse og send gjennom produksjonsarbeidsflyten, med harmløst innhold og uten kundedata. Lagre råmeldingen, tidsstemplet og mottakssystemets Authentication-Results. Ignorer autentiseringspåstander satt inn av en ikke-klarert avsender. Ta opp det synlige Fra-domenet, Return-Path eller autentisert konvoluttidentitet, og hvert DKIM d= og s= par. Et visningsnavn eller svar-til-adresse er ikke DMARC identiteten.
SPF pass autoriserer tilkoblingsserveren for den evaluerte konvoluttidentiteten. DKIM pass validerer en signatur for signeringsdomenet. DMARC trenger en bestått metode hvis domene er på linje med den synlige Fra: streng justering krever samme domene; avslappet justering tillater det aktuelle organisasjonsdomene-forholdet. En leverandøreid signatur kan passere uten å autentisere din synlige Fra. En pasning på linje DKIM signatur kan tilfredsstille DMARC selv når en annen signatur mislykkes. Disse protokollreglene kommer fra RFC 7208 , RFC 6376 og RFC 9989, oppført nedenfor.
Sjekk autoritativ DNS før du diagnostiserer cacher. Spør en autoritativ server om nøyaktig navn og type, og sammenlign deretter en rekursiv resolver etter dens bufrede levetid. For DKIM , følg en CNAME til dens offentlige nøkkel TXT svar. Publiser aldri en privat nøkkel. Behold én SPF policy ved hvert evaluert navn og sjekk grensen på ti DNS-oppslag-forårsaker-termer på tvers av nestede inkluderer. Ikke erstatt en delt SPF policy med et leverandøreksempel.
Gjenoppretting og aksept
Sett den berørte arbeidsflyten på pause hvis tester viser en ny regresjon. Sammenlign den endrede posten med den lagrede versjonen og angre bare den endringen etter å ha sjekket andre avsendere. Sjekk DNS på nytt og send på nytt etter gjenoppretting; tilbakestilling av en verdi tømmer ikke hver resolver umiddelbart. Hold gamle DKIM verifiseringsposter tilgjengelige mens tidligere signerte meldinger fortsatt kan være på vei, med mindre en sikkerhetshendelse krever tilbakekalling.
Godta endringen bare når DNS , applikasjonsstatus og en reell mottatt melding stemmer overens. Registrer flyteier, bevistidsstempel og neste gjennomgangsutløser. Innboksplassering alene er ikke bevis på autentisering, og vellykket autentisering garanterer ikke plassering av innboks. Ikke stram inn DMARC retningslinjene for et delt domene på grunnlag av en leverandørs test. Inventar de andre legitime kildene først.
Diagnostiser en oppføring som ser riktig ut i feil sone
Skriftlig sak TI-01 antar at domenet er registrert hos TransIP, men dets offentlige delegering peker til en annen DNS operatør. En lagret TransIP-paneloppføring for gjennomgang. _domainkey.news etablerer ikke publisering ved review._domainkey.news.example.org . Domeneeieren må bekrefte den autoritative operatøren og ordne den godkjente posten der; endre navneservere eller aktivere automatiske innstillinger er ikke den korrigerende snarveien. Offentlige svar, utsendte d=/s= og mottakerresultater forblir ukjente inntil de samles inn separat. Dette scenariet er fastsatt, ikke et faktisk DNS oppslag eller panelhandling.
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.