Start med den autoritative zone
IONOS-registrering, IONOS DNS hosting og IONOS-e-mail er forskellige ansvarsområder. Denne vejledning omhandler udgivelse af godkendelsesposter gennem IONOS-domænekontrolpanelet, ikke konfiguration af en IONOS-postkasse eller godkendelse af hver IONOS-afsendetjeneste. Den officielle dokumentation tillader eksterne navneservere; registreringer, der indtastes i en inaktiv IONOS-zone, bliver ikke internettets svar. Etabler den delegerede zone og den ansvarlige administrator, før du forbereder enhver redigering. IONOS eksterne navneservere
For hver anmodet ændring skal du registrere det fulde ejernavn, posttype, nutidsværdi, foreslået værdi, afsendende service og godkendende ejer. Opnå DKIM materiale fra den faktiske afsenderes kontospecifikke instruktioner. En DNS vært udgiver offentlig konfiguration; den kan ikke levere en anden tjenestes signeringsnøgle eller bevise, at tjenesten underskriver meddelelser. Hold private nøgler uden for DNS ændringsanmodningen. Hentning af DKIM nøgler
Oversæt navne, før du indtaster værdier
IONOS dokumenterer TXT stien som domænets handlingsmenu, DNS , Tilføj post og derefter TXT . Formularen adskiller værtsnavn, værdi og valgfri TTL. Eksisterende poster har handlingen Rediger registrering. Dens generiske TXT side beskriver @ som et jokertegn, men den formulering bør ikke blive en antagelse om autentificeringsdesign. En zoneoprindelsesforkortelse er ikke et løfte om at offentliggøre en politik ved hver efterkommer. Bekræft den resulterende ejer i stedet for at stole på symbolet alene. IONOS TXT editor DNS master-fil notation
Den dedikerede DMARC instruktioner er mere præcise: Værtsnavn _dmarc opretter _dmarc under det valgte domæne. I et fiktivt eksempel bør valg example.com og indtaste _dmarc adressere _dmarc.example.com . Dette er en foreslået forventning, ikke et fanget IONOS-resultat. Indtast ikke domæne-suffikset to gange. For indlejrede ejere skal du beholde det tilsigtede fuldt kvalificerede navn og kræve en publiceret-svar-sammenligning før accept. IONOS DMARC udgivelse
Bevar registreringsgrænser og politikejerskab
En eksisterende TXT samling kan indeholde ikke-relaterede bekræftelsestokens. Vælg den relevante godkendelsespolitik, ikke alle TXT post hos den ejer. SPF tillader én valgt SPF politik; tilføjelse af en anden kandidat er ikke, hvordan en anden afsender modtager tilladelse. Enhver konsolidering kræver en afsenderopgørelse og evaluering af DNS-forespørgselsvilkårene, inklusive afhængigheder, der nås gennem include. Udvid ikke autorisationen stille, mens du rydder tekst. SPF postvalg og grænser
En TXT ressourcepost kan indeholde flere tegnstrenge. For SPF er disse strenge sammenkædet uden indsatte mellemrum. Flere strenge inde i én post er ikke flere separat udgivet SPF optager. De gennemgåede IONOS-instruktioner fastslår ikke enhver opdeling, undslippelse eller tilbudsadfærd med lang værdi. Behandl disse editordetaljer som en acceptcheck: sammenlign de autoritative data og registreringsgrænser med den godkendte fuldstændige værdi. Fremstil ikke et vellykket eksperiment med lang nøgle. SPF flere strenge TXT dataformat
Skelne et alias fra delegeret myndighed
For en afsenderleveret DKIM CNAMEIONOS dokumenterer en underdomæne DNS sti, et værtsnavnfelt og et punkt til mål udtrykt som et fuldt kvalificeret værtsnavn uden et web-URL-skema. EN vælger alias er ikke en instruktion til at omdirigere et websted eller ændre domænets mail-routing. Bekræft den nøjagtige vælger og destination med ejeren af den afsendende tjeneste. IONOS CNAME arbejdsgang
IONOS advarer, når en ny rekord er i konflikt med en aktiv tjeneste. Stop ved en sådan advarsel og identificer afhængigheden, før du godkender en erstatning. Almindelige TXT og CNAME data kan ikke dele den samme aliasejer. Separat understøtter udbyderen underdomæne NS-poster gennem DNS editoren; dette uddelegerer ansvaret for et undertræ og har en bredere effekt end at udgive et nøglealias. Behandl ikke delegering som en løsning på en uforklarlig kollision. IONOS konflikter IONOS underdomæne delegation
Bekræft publicering og post uafhængigt
Den foreslåede acceptsekvens begynder med autoritative før-og-efter-forespørgsler for hver eksakt ejer og type, optageserver, tidspunkt, svarkode, svar og relevant delegering. Sammenlign derefter en rekursiv observation og undersøg enhver uoverensstemmelse. Positive caches og cachelagret ikke-eksistens er separate årsager til forældede svar. Negativ caching bruger den mindste af SOA TTL og SOA MINIMUM i dens indledende levetid, ikke MINIMUM alene. En redaktørs gemte tilstand og et dokumentationsestimat på én time er ikke en universel DNS konvergensgaranti. DNS -cache Negativ caching levetid
Dernæst bør en autoriseret operatør udøve den tilsigtede afsendelsesarbejdsgang og bevare den modtagne besked. Sammenlign dets synlige Fra-domæne, SMTP konvolutidentitet, DKIM signeringsdomæner og vælgere med betroede modtagergodkendelsesresultater. RFC 9989 tillader DMARC succes gennem en tilpasset passerende SPF eller DKIM -sti; blot at finde begge DNS poster beviser ingen af vejene. En politik anmoder om behandling og garanterer ikke levering eller rapportering. RFC 9990 specificerer samlet rapportering separat. DMARC justering Samlet rapportering Godkendelse-resultater tillid
Hold genopretningen smallere end hændelsen
Før en godkendt ændring skal du beholde de tidligere berørte optegnelser og årsagen til, at de er vigtige. IONOS zone backup og gendannelse kræver DNS Pro; restaurering overskriver eksisterende zonedata. En tilgængelig backup er derfor ikke tilladelse til at rulle ikke-relaterede ændringer tilbage. Få ejeren til at vælge en målrettet gendannelse eller en gennemgået helzonegendannelse, og gentag derefter offentliggørelsen og meddelelseskontrollen. Denne pakke udfører ingen af handlingerne. IONOS backup omfang
Bevis påkrævet før offentliggørelse
Det nøjagtige katalogkrav er: En aktuel IONOS-udgivelsesgennemgang med autoritative før/efter-forespørgsler og en uafhængig verificeret besked.
Det krav forbliver åbent. Offentlige instruktioner blev gennemgået den 9. november 2026 uden kontoadgang, live DNS forespørgsler, ændrede registreringer eller en modtaget besked. Nuværende lejeretiketter, lang TXT-håndtering, faktisk delegering, afsenderens anvendelighed, teknisk gennemgang, kontrol af produktionsruter, visuel accept og ejergodkendelse kræver stadig beviser. Eksemplet med det fiktive navn og den foreslåede verifikationssekvens er forberedelse, ikke en udført gennemgang.