[ Gidsen voor DNS-providers ]

Publiceer authenticatie DNS in IONOS

Plan een IONOS DNS wijziging rond de echte gezaghebbende zone, exacte recordeigenaren en onafhankelijk e-mailbewijs. De gedocumenteerde editorworkflow is beschikbaar; de live walkthrough in opdracht is nog steeds uitstekend.

Door het EmailAuth -onderzoeksteam · 6 minuten lezen

[ Kernpunten ]

  • Houd de DNS host, registrar en verzendservice gescheiden.
  • Vertaal relatieve hostlabels naar expliciete verwachte eigenaarnamen.
  • Behoud één SPF -beleid en inspecteer CNAME of delegatieconflicten voordat u afhankelijkheden wijzigt.
  • Bewijs de gezaghebbende publicatie en de uitlijning van ontvangen berichten afzonderlijk.
Op deze pagina

Begin met de gezaghebbende zone

IONOS-registratie, IONOS DNS hosting en IONOS-e-mail zijn verschillende verantwoordelijkheden. Deze handleiding gaat over het publiceren van authenticatierecords via het IONOS-domeincontrolepaneel, niet over het configureren van een IONOS-mailbox of het autoriseren van elke IONOS-verzendservice. De officiële documentatie staat externe naamservers toe; records die in een inactieve IONOS-zone worden ingevoerd, worden geen antwoorden van internet. Stel de gedelegeerde zone en de verantwoordelijke beheerder vast voordat u een bewerking voorbereidt. IONOS externe naamservers

Noteer voor elke aangevraagde wijziging de volledige naam van de eigenaar, het recordtype, de contante waarde, de voorgestelde waarde, de verzendservice en de goedkeurende eigenaar. Verkrijgen DKIM materiaal uit de daadwerkelijke accountspecifieke instructies van de afzender. Een DNS host publiceert openbare configuratie; het kan niet de ondertekeningssleutel van een andere dienst leveren of bewijzen dat de dienst berichten ondertekent. Bewaar privésleutels buiten het DNS wijzigingsverzoek. Ophalen DKIM sleutel

Vertaal namen voordat u waarden invoert

IONOS documenteert het TXT pad als het menu Acties van het domein, DNS , Record toevoegen en vervolgens TXT . Het formulier scheidt hostnaam, waarde en optionele TTL. Bestaande vermeldingen hebben de actie Record bewerken. De generieke TXT pagina beschrijft @ als een jokerteken, maar die bewoording mag geen aanname voor het authenticatieontwerp worden. Een afkorting van de zone-oorsprong is geen belofte om bij elke afstammeling een beleid te publiceren. Verifieer de resulterende eigenaar in plaats van alleen op het symbool te vertrouwen. IONOS TXT editor DNS -masterbestandsnotatie

De toegewijde DMARC instructies zijn nauwkeuriger: Hostnaam _dmarc maakt _dmarc aan onder het geselecteerde domein. In een fictief voorbeeld zou het kiezen example.com en het invoeren van _dmarc betrekking moeten hebben op _dmarc.example.com . Dit is een voorgestelde verwachting, geen vastgelegd IONOS-resultaat. Voer het domeinachtervoegsel niet tweemaal in. Voor geneste eigenaren geldt dat u de beoogde volledig gekwalificeerde naam behoudt en een vergelijking van gepubliceerde antwoorden vereist voordat u deze accepteert. IONOS DMARC -publicatie

Behoud recordgrenzen en beleidseigendom

Een bestaande TXT verzameling kan niet-gerelateerde verificatietokens bevatten. Selecteer het relevante authenticatiebeleid, niet elk TXT record bij die eigenaar. SPF staat één geselecteerd SPF beleid toe; het toevoegen van een tweede kandidaat is niet hoe een andere afzender toestemming krijgt. Voor elke consolidatie is een inventarisatie van de afzender en evaluatie van de DNS-querytermen nodig, inclusief afhankelijkheden die via include worden bereikt. Verruim de bevoegdheid niet stilletjes terwijl u tekst opruimt. SPF -recordselectie en limieten

Een TXT bronrecord kan meerdere tekenreeksen bevatten. Voor SPF worden deze strings aaneengeschakeld zonder tussengevoegde spaties. Verschillende strings binnen één record worden niet afzonderlijk gepubliceerd SPF records. De beoordeelde IONOS-instructies leggen niet elk gedrag van het splitsen, ontsnappen of citeren van lange waarden vast. Behandel deze redacteurgegevens als een acceptatiecontrole: vergelijk de gezaghebbende gegevens en registreer grenzen met de goedgekeurde volledige waarde. Maak geen succesvol experiment met een lange sleutel. SPF meerdere strings TXT gegevensformaat

Onderscheid een alias van gedelegeerde autoriteit

Voor een door de afzender verstrekte DKIM CNAMEIONOS documenteert een DNS pad voor het subdomein, een hostnaamveld en een point-to-target, uitgedrukt als een volledig gekwalificeerde hostnaam zonder een web-URL-schema. A keuzeschakelaar alias is geen instructie om een ​​website om te leiden of de e-mailroutering van het domein te wijzigen. Bevestig de exacte selector en bestemming bij de eigenaar van de verzendservice. IONOS CNAME workflow

IONOS waarschuwt wanneer een nieuw record conflicteert met een actieve service. Stop bij een dergelijke waarschuwing en identificeer de afhankelijkheid voordat u een vervanging goedkeurt. Gewone TXT en CNAME gegevens kunnen niet dezelfde aliaseigenaar delen. Afzonderlijk ondersteunt de provider NS-records voor subdomeinen via de DNS editor; dit delegeert de verantwoordelijkheid voor een subboom en heeft een breder effect dan het publiceren van één belangrijke alias. Beschouw delegatie niet als een tijdelijke oplossing voor een onverklaarbare botsing. IONOS-conflicten IONOS-subdomeindelegatie

Verifieer publicatie en e-mail onafhankelijk

De voorgestelde acceptatiereeks begint met gezaghebbende voor-en-na-vragen voor elke exacte eigenaar en type, opnameserver, tijd, responscode, antwoord en relevante delegatie. Vergelijk vervolgens een recursieve waarneming en onderzoek eventuele discrepantie. Positieve caches en niet-bestaan ​​in de cache zijn afzonderlijke oorzaken van verouderde antwoorden. Negatieve caching gebruikt de kleinste van de SOA TTL en SOA MINIMUM voor de initiële levensduur, en niet alleen MINIMUM. De opgeslagen status van een redacteur en een documentatieschatting van één uur vormen geen universele garantie voor DNS convergentie. DNS -caching Negatieve cachelevensduur

Vervolgens moet een geautoriseerde operator de beoogde verzendworkflow uitvoeren en het ontvangen bericht bewaren. Vergelijk de zichtbare Van-domein-, SMTP envelop-identiteit, DKIM ondertekeningsdomeinen en selectors met de authenticatieresultaten van vertrouwde ontvangers. RFC 9989 maakt DMARC succes mogelijk via een uitgelijnd passerend SPF of DKIM pad; alleen het vinden van beide DNS records bewijst geen van beide paden. Een polis vraagt ​​om behandeling en garandeert geen levering of rapportage. RFC 9990 specificeert de geaggregeerde rapportage afzonderlijk. DMARC uitlijning Geaggregeerde rapportage Authenticatie-resultaten vertrouwen

Houd het herstel beperkter dan het incident

Bewaar vóór een goedgekeurde wijziging de eerder getroffen gegevens en de reden waarom deze van belang zijn. Voor back-up en herstel van de IONOS-zone is DNS Pro vereist; herstel overschrijft bestaande zonegegevens. Een beschikbare back-up is dus geen toestemming om niet-gerelateerde wijzigingen ongedaan te maken. Laat de eigenaar kiezen voor een gericht herstel of een gecontroleerd herstel voor de hele zone, en herhaal vervolgens de publicatie- en berichtcontroles. Dit pakket voert geen enkele actie uit. IONOS-back-upscope

Bewijs vereist vóór publicatie

De exacte catalogusvereiste is: Een actuele IONOS-publicatie-walkthrough met gezaghebbende voor/na-vragen en een onafhankelijk geverifieerd bericht.

Die eis blijft open. Openbare instructies zijn op 9 november 2026 beoordeeld, zonder accounttoegang, live DNS query's, gewijzigde records of een ontvangen bericht. Huidige huurderlabels, lange-TXT-afhandeling, daadwerkelijke delegatie, toepasbaarheid van de afzender, technische beoordeling, controles van de productieroute, visuele acceptatie en goedkeuring van de eigenaar hebben nog steeds bewijs nodig. Het fictieve naamvoorbeeld en de voorgestelde verificatievolgorde zijn voorbereiding en geen uitgevoerde walkthrough.

[ Afhaalmaaltijden ]

Accepteer de wijziging alleen als de beoogde gezaghebbende gegevens en de feitelijke verzendidentiteit overeenkomen met de goedgekeurde configuratie.

[ Per rol ]

Wat dit voor jou betekent

Kies jouw rol voor praktische vervolgstappen.

DNS beheerder

Bescherm de zonegrens

Een succesvolle redding in de verkeerde zone is nog steeds een ineffectieve verandering. De beheerder is eigenaar van de gezaghebbende plaatsing en de effecten op aangrenzende records.

Volgende stappen

  1. Schrijf de volledige verwachte eigenaar en typ naast elk voorgesteld editoritem.
  2. Leg de huidige afhankelijkheden vast voordat u een CNAME conflict oplost of delegatie overweegt.
  3. Bewaar het volledige gezaghebbende voor-en-na-bewijs wanneer een goedgekeurde test wordt uitgevoerd.

Eigenaar van e-mailservice

Geef identiteiten op, geen generieke records

De afzender bepaalt zijn envelop- en ondertekengedrag. Een DNS beheerder hoeft geen tenant-selector af te leiden of aan te nemen dat een record ondertekening activeert.

Volgende stappen

  1. Geef de huidige accountspecifieke openbare configuratie en de beoogde verzendworkflow op.
  2. Definieer de zichtbare Van-, verwachte envelop- en handtekeningidentiteit voor acceptatie.
  3. Regel een geautoriseerd gecontroleerd bericht en bekijk de resultaten van vertrouwde ontvangers.

Goedkeurder wijzigen

Definieer een begrensd herstel

Authenticatiebewerkingen kunnen niet-gerelateerde e-mail verstoren wanneer een beleid, delegatie of hele zone wordt vervangen zonder controle van de afhankelijkheid.

Volgende stappen

  1. Keur de getroffen namen, services en het terugdraaibereik goed voordat u deze uitvoert.
  2. Controleer of DNS Pro-herstel nieuwere, niet-gerelateerde records zou overschrijven.
  3. Houd de vrijgave geblokkeerd totdat de walkthrough, de technische beoordeling en de publicatiegoedkeuringen zijn voltooid.

[ Veelgestelde vragen ]

Veelgestelde vragen

Bewijst een IONOS-registratie dat deze editor gezaghebbend is?

Nee. Registratie kan naast externe naamservers bestaan. Volg de gedelegeerde autoriteit voor de exacte zone voordat u besluit waar u wilt publiceren; schakel niet van naamserver alleen maar om een ​​bewerking zichtbaar te maken.

Moet ik _dmarc.example.com in de hostnaam plakken?

De speciale IONOS DMARC procedure specificeert het relatieve label _dmarc voor het geselecteerde domein. Bewaar de beoogde volledige eigenaar afzonderlijk en controleer of de gepubliceerde naam geen dubbel achtervoegsel heeft.

Is @make SPF automatisch van toepassing op elk subdomein?

Nee. Behandel @ als zone-oorsprongnotatie, niet als wildcard-autorisatie. SPF wordt geëvalueerd op de daadwerkelijk gebruikte identiteit; een ouderbeleid voorziet niet automatisch elk onderliggend domein van een eigen SPF beleid.

Wat is het veilige antwoord op twee bestaande SPF beleidslijnen?

Stop de voorgestelde toevoeging en vraag de verantwoordelijke afzendereigenaren om de autorisatie in één geldig beleid af te stemmen. Behoud niet-gerelateerde TXT tokens en evalueer eventuele afhankelijkheden in plaats van simpelweg twee volledige records samen te voegen.

Kan IONOS een afzenderspecifieke DKIM CNAME bevatten?

De openbare instructies ondersteunen CNAME publicatie voor subdomeinen. De verzendende aanbieder moet de toepasselijke selector en bestemming opgeven. Controleer op conflicterende gegevens bij die exacte aliaseigenaar en laat andere selectors met rust.

Hoe moet een lange TXT sleutel worden gecontroleerd?

Vergelijk de volledige goedgekeurde openbare sleutel met het gezaghebbende TXT record, inclusief tekenreeksaaneenschakeling en recordgrenzen. Dit onderzoek heeft het splits-, ontsnappings- of citaatgedrag van IONOS niet getest, dus die details blijven een echte walkthrough-poort.

Is een uur genoeg om de implementatie succesvol te verklaren?

Verstreken tijd is geen acceptatiebewijs. Afzonderlijke gezaghebbende publicatie, recursieve caching en berichtauthenticatie. Eerder in de cache opgeslagen positieve gegevens of het niet bestaan ​​ervan kunnen verschillende waarnemingen verklaren; inspecteer de daadwerkelijke respons en TTL-context.

Kan een DNS Pro-back-up alleen mijn authenticatiebewerking veilig ongedaan maken?

Een zoneherstel is breder: IONOS zegt dat het bestaande zonegegevens overschrijft. Controleer de rechten, back-upinhoud en tussenliggende wijzigingen. Een gerichte, goedgekeurde reparatie van archiefstukken kan voorkomen dat niet-gerelateerd werk ongedaan wordt gemaakt; geen van beide opties is hier uitgevoerd.

[ Bronnen ]

Bronnen

  1. RFC 8601 : Berichtkopveld voor het aangeven van de berichtauthenticatiestatus
  2. IONOS: Back-up maken en herstellen DNS zones
  3. IONOS: Een CNAME record configureren voor een subdomein
  4. IONOS: DNS conflicten vermijden
  5. RFC 6376 : DomainKeys geïdentificeerde e-mailhandtekeningen
  6. RFC 9989 : Op domein gebaseerde berichtauthenticatie, rapportage en conformiteit
  7. RFC 1034 : Domeinnamen - concepten en faciliteiten
  8. RFC 1035 : Domeinnamen - implementatie en specificatie
  9. IONOS: Een DMARC -record voor een domein configureren
  10. IONOS: uw eigen naamservers gebruiken voor een domein
  11. RFC 2308 : Negatieve caching van DNS query's
  12. RFC 9990 : DMARC geaggregeerde rapportage
  13. RFC 7208 : Kader voor afzenderbeleid
  14. IONOS: Een NS-record voor een subdomein toevoegen, wijzigen of verwijderen
  15. IONOS: TXT records beheren

[ Glossarium ]

Glossarium

Gezaghebbende zone
Het deel van de DNS naamruimte dat wordt bediend vanuit de verantwoordelijke gezaghebbende gegevens. Identificeer het voordat u de editor voor een authenticatie-eigenaar kiest.
Naam eigenaar
De DNS naam waartoe een record behoort, zoals _dmarc.example.com . Het verschilt van een CNAME doel of een TXT waarde.
TXT tekenreeks
Eén component met beperkte lengte van TXT -recordgegevens. Meerdere componenten kunnen tot één bronrecord behoren en vereisen protocolspecifieke interpretatie.
Selectoralias
Een CNAME bij een eigenaar van een DKIM selector die de resolutie verwijst naar de door de afzender beheerde sleutellocatie; het is geen NS-delegatie voor het hele domein.
Negatieve cache
DNS bewijs in cache opgeslagen dat een naam of gevraagde gegevens ontbreken. De levensduur ervan is relevant wanneer een nieuw aangemaakt authenticatierecord nog niet door een oplosser is gezien.

Herkomst onderneming

Waarom top financiële instellingen en overheden hebben hun e-mailbeveiligingsdashboards stopgezet.

Traditionele platforms voor e-mailauthenticatie verkopen u een dashboard en vragen uw technici om het werk te doen. In omgevingen waar veel op het spel staat, betekent handmatig toezicht vertraagde handhaving, configuratieafwijking en niet-gecontroleerde schaduwdomeinen.

EmailAuth is het agentische e-mailherkomstplatform. Onze agenten handhaven p=reject, houd externe afzenders op één lijn en verplaats uw domeinen naar vol RFC 9989 compliance, de nieuwe DMARC standaard, met 'human-in-the-loop'-auditeerbaarheid.

Regeringen Grote ondernemingen Tier-1 financiële instellingen

SaaS · Toegewijde huur · Air-gapped on-premise · BYOK-encryptie

Kennisbank