Start med den autoritative sonen
IONOS-registrering, IONOS DNS hosting og IONOS-e-post er forskjellige ansvarsområder. Denne veiledningen gjelder publisering av autentiseringsposter gjennom IONOS-domenekontrollpanelet, ikke konfigurering av en IONOS-postboks eller autorisering av hver IONOS-sendetjeneste. Den offisielle dokumentasjonen tillater eksterne navneservere; poster som legges inn i en inaktiv IONOS-sone blir ikke Internetts svar. Etabler den delegerte sonen og ansvarlig administrator før du forbereder enhver redigering. IONOS eksterne navneservere
For hver forespurte endring, noter det fullstendige eiernavnet, posttype, nåverdi, foreslått verdi, sendetjeneste og godkjennende eier. Få DKIM materiale fra den faktiske avsenderens kontospesifikke instruksjoner. En DNS vert publiserer offentlig konfigurasjon; den kan ikke levere en annen tjenestes signeringsnøkkel eller bevise at tjenesten signerer meldinger. Hold private nøkler utenfor DNS endringsforespørselen. Henting av DKIM -nøkler
Oversett navn før du legger inn verdier
IONOS dokumenterer TXT banen som domenets Handlingsmeny, DNS , Add Record, så TXT . Skjemaet skiller Vertsnavn, Verdi og valgfri TTL. Eksisterende oppføringer har handlingen Rediger post. Den generiske TXT siden beskriver @ som et jokertegn, men den formuleringen bør ikke bli en antagelse om autentiseringsdesign. En sone-opprinnelsesforkortelse er ikke et løfte om å publisere en policy på hver etterkommer. Bekreft den resulterende eieren i stedet for å stole på symbolet alene. IONOS TXT redigerer DNS -hovedfilnotasjon
Den dedikerte DMARC instruksjonene er mer presise: Vertsnavn _dmarc oppretter _dmarc under det valgte domenet. I et fiktivt eksempel bør valg av example.com og skrive inn _dmarc adressere _dmarc.example.com . Dette er en foreslått forventning, ikke et fanget IONOS-resultat. Ikke skriv inn domene-suffikset to ganger. For nestede eiere, behold det tiltenkte fullt kvalifiserte navnet og krever en sammenligning av publiserte svar før de godtas. IONOS DMARC publisering
Bevar rekordgrenser og policyeierskap
En eksisterende TXT -samling kan inneholde urelaterte bekreftelsestokener. Velg den relevante autentiseringspolicyen, ikke alle TXT post hos den eieren. SPF tillater én valgt SPF policy; å legge til en annen kandidat er ikke hvordan en annen avsender får tillatelse. Enhver konsolidering trenger en avsenderinventar og evaluering av DNS-spørringsvilkårene, inkludert avhengigheter nådd gjennom include. Ikke utvide autorisasjonen stille mens du rydder tekst. SPF -postvalg og grenser
En TXT ressurspost kan inneholde flere tegnstrenger. For SPF er disse strengene sammenkoblet uten innsatte mellomrom. Flere strenger inne i en post er ikke flere separat publisert SPF poster. De gjennomgåtte IONOS-instruksjonene fastslår ikke enhver lang verdisplitting, unnslipping eller sitatatferd. Behandle disse redaktørdetaljene som en akseptsjekk: sammenlign autoritative data og registreringsgrenser med den godkjente fullstendige verdien. Ikke lag et vellykket eksperiment med lang nøkkel. SPF flere strenger TXT dataformat
Skille et alias fra delegert myndighet
For en DKIM levert av avsender CNAME, IONOS dokumenterer en underdomene DNS bane, et vertsnavnfelt og et punkt til mål uttrykt som et fullt kvalifisert vertsnavn uten et web-URL-skjema. EN velger alias er ikke en instruksjon om å omdirigere et nettsted eller endre domenets e-postruting. Bekreft den nøyaktige velgeren og destinasjonen med eieren av avsendertjenesten. IONOS CNAME arbeidsflyt
IONOS varsler når en ny rekord kommer i konflikt med en aktiv tjeneste. Stopp ved en slik advarsel og identifiser avhengigheten før du godkjenner en erstatning. Vanlige TXT og CNAME data kan ikke dele samme aliaseier. Separat støtter leverandøren underdomene NS-poster gjennom DNS editoren; dette delegerer ansvaret for et undertre og har en bredere effekt enn å publisere ett nøkkelalias. Ikke behandle delegering som en løsning for en uforklarlig kollisjon. IONOS-konflikter IONOS underdomene delegering
Bekreft publisering og e-post uavhengig
Den foreslåtte akseptsekvensen begynner med autoritative før-og-etter-spørringer for hver eksakt eier og type, opptaksserver, tid, svarkode, svar og relevant delegering. Sammenlign deretter en rekursiv observasjon og undersøk eventuelle avvik. Positive cacher og bufret ikke-eksistens er separate årsaker til foreldede svar. Negativ hurtigbufring bruker den minste av SOA TTL og SOA MINIMUM for sin opprinnelige levetid, ikke MINIMUM alene. En redaktørs lagrede tilstand og et dokumentasjonsestimat på én time er ikke en universell DNS konvergensgaranti. DNS -bufring Negativ caching levetid
Deretter bør en autorisert operatør utøve den tiltenkte sendearbeidsflyten og bevare den mottatte meldingen. Sammenlign dets synlige fra-domene, SMTP konvoluttidentitet, DKIM signeringsdomener og velgere med pålitelige mottakerautentiseringsresultater. RFC 9989 tillater DMARC suksess gjennom en justert bestått SPF eller DKIM bane; bare å finne begge DNS postene beviser ingen av veiene. En policy ber om behandling og garanterer ikke levering eller rapportering. RFC 9990 spesifiserer samlet rapportering separat. DMARC -justering Samlet rapportering Autentisering-resultater tillit
Hold utvinningen smalere enn hendelsen
Før en godkjent endring, ta vare på de tidligere berørte postene og årsaken til at hver er viktig. Sikkerhetskopiering og gjenoppretting av IONOS-soner krever DNS Pro; restaurering overskriver eksisterende sonedata. En tilgjengelig sikkerhetskopi er derfor ikke tillatelse til å rulle tilbake urelaterte endringer. Be eieren velge en målrettet gjenoppretting eller en gjennomgått helsone-restaurering, og gjenta deretter publiserings- og meldingskontrollene. Denne pakken utfører ingen av handlingene. IONOS backup omfang
Bevis kreves før publisering
Det nøyaktige katalogkravet er: En nåværende IONOS-publiseringsgjennomgang med autoritative før/etter-spørsmål og en uavhengig bekreftet melding.
Det kravet forblir åpent. Offentlige instruksjoner ble gjennomgått 9. november 2026, uten kontotilgang, direkte DNS spørringer, endrede poster eller en mottatt melding. Nåværende leietakeretiketter, langvarig TXT-håndtering, faktisk delegering, avsenderens anvendelighet, teknisk gjennomgang, produksjonsrutekontroller, visuell aksept og eiergodkjenning trenger fortsatt bevis. Det fiktive navneksemplet og den foreslåtte bekreftelsessekvensen er forberedelse, ikke en utført gjennomgang.