Bekræft, at TransIP er autoritativ
Dette er en DNS -udgivelsesvejledning, ikke en TransIP-mail-service onboarding-guide. Et domæne kan registreres hos TransIP, mens det er autoritativt navneservere er andre steder. Tjek domænets offentlige delegation og identificer den autoritative zone før redigering. Skift ikke navneserver bare for at gøre en DNS formular tilgængelig. Få afsenderens nøjagtige postnavne, typer og værdier sammen med den eksisterende zoneeksport og et godkendt ændringsomfang.
Indtast navne og værdier korrekt
Vælg domænet i kontrolpanelet, og åbn DNS indstillinger. Brugerdefineret redigering kræver, at de automatiske TransIP-indstillinger er slået fra. Genaktivering af disse indstillinger kan overskrive brugerdefinerede poster og navneservere. Navn-feltet bruger @ for zonespidsen og relative navne for underdomæner. En ekstern CNAME målet har brug for sit fulde navn og den efterfølgende prik. Disse grænsefladeregler er dokumenteret i TransIP-kontrolpanelkilden nedenfor.
For en TXT DKIM nøgle, instruerer DKIM kilden brugerne til at udelade omgivende anførselstegn og unødvendige skråstreg. Brug afsenderens offentlige nøgle, aldrig en genereret prøve. EN vælger på et afsendende underdomæne skal det underdomæne i det relative ejernavn. Brug kun CNAME , når afsenderen faktisk har udstedt en CNAME delegation. Udgivelse af en nøgle får ikke en sendetjeneste til at begynde at signere.
Originalt regneark til registrering af registreringer
Det følgende er en fiktiv kortlægningsøvelse for zonen example.org , ikke en produktionskonfiguration. En komplet DKIM review._domainkey.news.example.org -kort til anmeldelse. _domainkey.news i feltet Navn. EN DMARC ejer _dmarc.news.example.org kort til _dmarc.news. De SPF ejer news.example.org maps til nyheder. Marker det forventede fulde navn på ændringsbilletten, så en anmelder kan opdage et utilsigtet suffiks example.org.example.org .
Hold SPF og DMARC som TXT politikker ved deres korrekte ejernavne. Indsæt ikke en fuld zonefillinje, inklusive klasse og type, i feltet Værdi. Flere TXT registreringer kan eksistere side om side til ikke-relaterede formål, men to SPF politikker ved ét evalueret navn er ikke gyldige. Lange DKIM værdier kræver omhyggelig håndtering: De hentede TransIP-sider etablerer ikke en universel langstrengs-opdelingsprocedure. Hvis panelet afviser udbyderens fulde værdi, skal du stoppe og få aktuel TransIP-vejledning i stedet for at afkorte den.
Bekræft publikationen, før du tester mail
Spørg hver autoritativ server for de fulde SPF , DMARC og vælgernavne. Sammenlign komplette værdier, inklusive sammenkædede TXT strenge, hvor de returneres. For en delegeret nøgle skal du bekræfte CNAME målet og det endelige TXT svar. Gentag gennem en rekursiv resolver og behold TTL-observationer. Et korrekt kontrolpaneldisplay med et fraværende offentligt svar kan indikere forkert autoritet eller ikke-gemte data, ikke blot langsom udbredelse.
Først derefter udløses en kontrolleret besked gennem afsendertjenesten. DNS-side rollback bør gendanne de ændrede poster, ikke genaktivere automatiske indstillinger eller gendanne en hel gammel zone uden at sammenligne ikke-relaterede ændringer.
Bevis identiteten ved modtageren
Brug en kontrolleret ekstern postkasse og send gennem produktions-workflowet, med harmløst indhold og ingen kundedata. Gem råbeskeden, tidsstemplet og det modtagende system Authentication-Results. Ignorer godkendelsespåstande indsat af en ikke-pålidelig afsender. Optag det synlige Fra-domæne, Return-Path eller autentificeret kuvertidentitet, og hvert DKIM d= og s= par. Et vist navn eller svar-til-adresse er ikke DMARC identiteten.
SPF passet autoriserer den forbindende server til den evaluerede kuvertidentitet. DKIM pass validerer en signatur for sit signeringsdomæne. DMARC har brug for en videregivelsesmetode, hvis domæne stemmer overens med den synlige Fra: streng justering kræver det samme domæne; afslappet tilpasning tillader den relevante organisation-domæne-relation. En udbyderejet signatur kan passere uden at godkende din synlige Fra. En aflevering justeret DKIM signatur kan tilfredsstille DMARC selv når en anden signatur fejler. Disse protokolregler kommer fra RFC 7208 , RFC 6376 og RFC 9989, anført nedenfor.
Tjek autoritativ DNS før diagnosticering af caches. Spørg en autoritativ server om det nøjagtige navn og type, og sammenlign derefter en rekursiv resolver efter dens cachelagrede levetid. For DKIM , følg enhver CNAME til dens offentlige nøgle TXT svar. Udgiv aldrig en privat nøgle. Hold én SPF politik ved hvert evalueret navn, og tjek grænsen på ti DNS-lookup-causing-terms på tværs af indlejrede inkluderer. Erstat ikke en delt SPF -politik med et udbydereksempel.
Restitution og accept
Sæt den berørte arbejdsgang på pause, hvis test viser en ny regression. Sammenlign den ændrede post med den gemte version, og fortryd kun denne ændring efter at have kontrolleret andre afsendere. Tjek DNS igen og send igen efter gendannelse; gendannelse af en værdi fjerner ikke alle resolvere med det samme. Hold gamle DKIM -bekræftelsesregistreringer tilgængelige, mens tidligere underskrevne meddelelser stadig kan være i transit, medmindre en sikkerhedshændelse kræver tilbagekaldelse.
Accepter kun ændringen, når DNS , applikationstilstand og en reel modtaget besked stemmer overens. Registrer flowejeren, bevistidsstemplet og næste gennemgangstrigger. Indbakkeplacering alene er ikke bevis for godkendelse, og vellykket godkendelse garanterer ikke placering i indbakken. Stram ikke et delt domænes DMARC politik på grundlag af en udbyders test. Inventar de andre legitime kilder først.
Diagnostiser en korrekt udseende indgang i den forkerte zone
Skriftlig sag TI-01 antager, at domænet er registreret hos TransIP, men dets offentlige delegation peger på en anden DNS operatør. En gemt TransIP-panelindgang til gennemgang. _domainkey.news etablerer ikke offentliggørelse ved review._domainkey.news.example.org . Domæneejeren skal bekræfte den autoritative operatør og arrangere den godkendte post der; at ændre navneservere eller aktivere automatiske indstillinger er ikke den rette genvej. Offentlige svar, udsendte d=/s= og modtagerresultater forbliver ukendte, indtil de indsamles separat. Dette scenarie er fastsat, ikke et egentligt DNS opslag eller panelhandling.
Bevar håndhævelsesgrænsen
RFC 9989 Afsnit 7.4 kræver gyldig DKIM , ikke SPF alene, for domæner, der udgiver p=reject, og advarer om interoperabilitet mellem indirekte mail og mailinglister. En enkelt vellykket test med direkte beskeder er ikke et bevis på, at enhver legitim rute er klar til en stærkere politik. Behold eksisterende godkendt beskyttelse, mens du diagnosticerer det faktiske hul; enhver politikændring kræver sin egen beslutning.