Stel vast of Openprovider de actieve zone bedient
Deze handleiding gaat over het publiceren van authenticatierecords in Openprovider DNS . Het is geen configuratiehandleiding voor de afzonderlijke mailbox- of doorstuurproducten van Openprovider. Uw domein kunt u registreren in Openprovider terwijl Microsoft 365 , een campagnedienst of een andere provider zijn mail verzendt. De afzender levert zijn authenticatie-instructies; de gezaghebbende DNS operator publiceert de goedgekeurde records. Houd deze rollen gescheiden bij het toewijzen van het werk.
Openprovider ondersteunt zijn eigen naamservers en externe naamservers. In de nameserverhandleiding wordt uitgelegd dat extern gehoste zones moeten worden geconfigureerd bij de externe DNS provider, terwijl door Openprovider gehoste zones worden beheerd via DNS Management en DNS zoneoverzicht. Begin met de daadwerkelijke publieke delegatie en de exacte zone die wordt gewijzigd. Een geregistreerd domein en een zichtbare zone in het account zijn niet voldoende om autoriteit te vestigen. Begeleiding voor de naamserver van Openprovider
Wijzig de naamservers niet alleen maar om een SPF redacteur beschikbaar. Dat is een aparte migratie die invloed kan hebben op de website, inkomende mail, validatietokens en DNSSEC. Als een externe provider gezaghebbend is, geef dan de goedgekeurde recordwijzigingen door aan de beheerder van die provider. Als Openprovider gezaghebbend is, bevestig dan dat u de livezone bewerkt in plaats van een sjabloon die bedoeld is voor toekomstig gebruik.
Verzamel de recordwijzigingen van de verzendende service
Vraag de huidige door de afzender uitgegeven SPF autorisatie aan, DKIM eigenaren en waarden, eventuele instructies voor aangepaste enveloppen en het precieze domein waarop deze van toepassing zijn. Vermijd een universeel record dat Openprovider SPF instelling wordt genoemd: een DNS host wordt geen geautoriseerde afzender van e-mail door simpelweg de zone te hosten. Hetzelfde onderscheid geldt voor DKIM . DKIM artikel van Openprovider staat dat de verzendende mailserver de recordinhoud bepaalt en dat de provider of systeemingenieur deze aanlevert. Openprovider DKIM publicatie
Exporteer of bewaar op andere wijze de volledige betrokken recordsets, inclusief namen van eigenaren, typen, TTL's en waarden. Houd niet-gerelateerde TXT tokens intact. Registreer elke voorgestelde actie als toevoegen, vervangen of intrekken, met de service-eigenaar en de reden ervan. A keuzeschakelaar dat er oud uitziet, valideert mogelijk nog steeds e-mail in de wachtrij of ondersteunt een andere toepassing. De instructie van een nieuwe dienst geeft geen toestemming voor het verwijderen van de sleutel van de oude dienst.
Scheid de volledig gekwalificeerde beoogde eigenaar van de invoer van de editor. Voor DKIM zijn de selector- en _domainkey -labels essentieel; ze zijn niet uitwisselbaar met de domeintop. Voor DMARC, identificeer de toepasselijke _dmarc eigenaar. Voor SPF identificeert u het daadwerkelijke SMTP envelopdomein. De opgehaalde DNS Records-gids stelt geen huidige universele apex-invoerconventie vast. Bevestig de huidige interface-afhandeling van de root-eigenaar en de toegevoegde achtervoegsels voordat u opslaat; ga er niet vanuit dat een leeg veld of @ in elke invoermodus wordt geaccepteerd. Openprovider DNS recordconventies
Publiceer SPF als één beleid met geverifieerde TXT opmaak
SPF gids van Openprovider gebruikt TXT records en instrueert zijn gebruikers specifiek om de inhoud tussen rechte aanhalingstekens te plaatsen. Volg de gedocumenteerde invoerconventie van de huidige editor en inspecteer vervolgens het gepubliceerde TXT antwoord om te verifiëren dat de opmaak correct is geïnterpreteerd. Gekrulde aanhalingstekens gekopieerd uit een tekstverwerker zijn niet gelijkwaardig. Voeg niet herhaaldelijk offertelagen toe als een oplosser al tekenreeksen met aanhalingstekens weergeeft. Openprovider SPF publicatie
Protocolsemantiek is het acceptatiecriterium. Er moet één kandidaat SPF beleid zijn bij de geëvalueerde eigenaar. Een TXT record kan meerdere tekenreeksen bevatten die worden samengevoegd voor SPF verwerking, dus een weergavesplitsing hoeft niet noodzakelijkerwijs uit meerdere beleidsregels te bestaan. Omgekeerd zijn twee afzonderlijke records die beginnen met de SPF versiemarkering geen geldige manier om twee afzenders te huisvesten. Behoud de vereiste spaties en de volledige mechanismevolgorde in de gereconstrueerde waarde. SPF RFC 7208
Het algemene SPF artikel van de provider bevat vereenvoudigde taal over TXT lengte, terwijl de DNS Records-gids expliciet beschrijft hoe een grote TXT waarde in kleinere reeksen binnen één record moet worden gesplitst. De tekenreekslimiet mag niet worden beschouwd als een totale recordlimiet. Bevestig de afhandeling van de huidige redacteur en verifieer het gereconstrueerde antwoord. Openprovider TXT recordbegeleiding Als een lange waarde wordt afgewezen, vraag dan advies aan de aanbieder; verkort een publieke sleutel niet en splits een SPF beleid niet op in onafhankelijke records.
Evalueer de recursieve opzoeklimieten van SPF voordat u een samengevoegd beleid opslaat. Een visueel kort beleid kan de limiet nog steeds overschrijden via opgenomen beleid. Vervang door de provider onderhouden mechanismen niet door een momentopname van de huidige IP-adressen, tenzij dat onderhoudsmodel doelbewust is goedgekeurd en ondersteund. Statische afvlakkende veranderingen die toekomstige veranderingen in de infrastructuur moeten volgen.
Houd DKIM -recordtypen en selectoreigendom intact
Sommige verzendservices leveren een openbare TXT sleutel; anderen leveren een CNAME alias. Publiceer het opgegeven type bij de opgegeven selectoreigenaar. Plaats geen CNAME doel in een TXT veld en publiceer de sleutel niet aan de top. De ontvanger leidt de zoekopdracht af van het ondertekeningsdomein en de selector van het bericht. Daarom helpt een plausibel ogende record bij een andere eigenaar niet. DKIM RFC 6376
Openprovider documenteert fouten wanneer een CNAME de eigenaar deelt met andere gewone recordgegevens. Als de redacteur een duplicaat of CNAME conflict rapporteert, inspecteer dan de volledige recordset van de exacte eigenaar. Verwijder de conflicterende TXT record niet voordat u de afzender heeft geïdentificeerd die er eigenaar van is. Vraag de nieuwe afzender om een ondersteunde, niet-conflicterende selector of plan een gecontroleerde rotatie. Het conflict is een kwestie van vertrouwen en niet louter een probleem van invoervalidatie. Richtlijnen voor Openprovider CNAME conflicten
Een openbare sleutel of een delegatierecord zorgt er niet voor dat de verzendende service begint met ondertekenen. Voltooi elke activering aan de afzenderzijde afzonderlijk en verifieer de handtekening op een echt bericht. Publiceer nooit privésleutels, API-referenties of SMTP wachtwoorden in de zone of het werkblad.
Onderscheid handmatige DMARC van gehoste delegatie
De EasyDMARC-integratie van Openprovider beschrijft twee beheerpaden: een gehost beleid dat wordt bereikt via een CNAME alias en een handmatig onderhouden TXT beleid. Het waarschuwt dat het delegatiedoel dat in een voorbeeld wordt getoond, niet de te gebruiken waarde is; het bedieningspaneel levert het daadwerkelijke doel. Het beschrijft ook het automatisch aanmaken CNAME in een kwalificerende aankoop- of activeringsstroom met behulp van Openprovider-naamservers. Inspecteer daarom de bestaande _dmarc eigenaar voordat u iets handmatig toevoegt. Openprovider EasyDMARC-beheer
Kies één goedgekeurd managementmodel. Bij een gehoste delegatie kan het operationele beleid in de gehoste dienst veranderen zonder dat er een overeenkomstige wijziging in de Openprovider-zone plaatsvindt. Wijs een eigenaar toe voor die service en behoud de goedgekeurde beleidsinstellingen. Bij handmatige TXT moeten wijzigingen worden weerspiegeld in de gepubliceerde waarde. Zorg ervoor dat u een TXT beleid en een CNAME niet bij dezelfde eigenaar achterlaat, en vervang bestaande rapportagebestemmingen niet alleen maar om een integratiewizard te volgen.
DMARC evalueert het zichtbare Van-domein tegen het doorgeven van uitgelijnde SPF of DKIM -identiteiten. Publicatie is een onderdeel van dat proces; het bewijst niet dat de afzenders van het domein op één lijn liggen. Zorg ervoor dat het gedrag van de ontvanger gescheiden blijft van het gevraagde beleid en houd een domeinbrede afzenderinventaris bij voordat u de handhaving verscherpt. DMARC RFC 9989
Herbruikbaar publicatiewerkblad van Openprovider
Maak één rij voor elke gewijzigde eigenaar en bewaar een gedeelde wijzigingsrecord voor het domein.
- Domein, gezaghebbende naamservers en live zone-ID: ______.
- DNS beheerder, afzenderbeheerder en goedkeurder van wijzigingen: ______.
- Verzendende service en het huidige configuratiebewijs: ______.
- Beoogde volledig gekwalificeerde eigenaar en aparte hostinvoer van de editor: ______.
- Recordtype, volledige goedgekeurde waarde en TTL: ______.
- Eerdere recordset en afhankelijkheden die moeten blijven bestaan: ______.
- SPF evalueerde de envelopeigenaar en recursieve beleidscontrole: ______.
- Eigendom van DKIM selector, beoordeling van conflicten en activatie van afzender: ______.
- DMARC handmatige TXT of gehoste CNAME keuze en beleidseigenaar: ______.
- Gezaghebbend antwoord na verandering en recursieve vergelijking: ______.
- Referentie ontvangen bericht, Van, envelop, handtekeningen en vertrouwde resultaten: ______.
- Stappen terugdraaien, eigenaar opnieuw testen, visuele controle en menselijke acceptatie: in behandeling.
Fictieve diagnose van een selectorbotsing
Dit voorbeeld is fictief. Een reseller voegt een nieuwe marketingdienst toe aan een domein waarvan DNS wordt gehost door Openprovider. De nieuwe dienst vraagt een CNAME aan bij een selector die al een TXT sleutel voor een factuurafzender bevat. Openprovider wijst de wijziging af als conflict. De reseller stelt voor de TXT te verwijderen omdat de nieuwe installatiehandleiding zegt dat de selector vereist is.
Het veilige onderzoek identificeert de afzender van de factuur en bevestigt dat deze nog steeds uitgaande berichten met die selector ondertekent. Het voorgestelde herstel bestaat uit het aanvragen van een andere ondersteunde selector bij de marketingservice of het coördineren van een geverifieerde sleuteloverdracht met beide eigenaren. Het is niet de bedoeling om de factuursleutel blindelings te verwijderen. Na een goedgekeurde wijziging zouden afzonderlijke factuur- en marketingberichten worden getest. Dit scenario vertegenwoordigt geen daadwerkelijke zone, zender of succesvolle test.
Sluit af met DNS en berichtbewijs
Vraag de exacte eigenaren op de gezaghebbende naamservers na het opslaan en bewaren van de antwoorden. Vergelijk een recursief antwoord afzonderlijk, waarbij caching wordt herkend. Laat vervolgens elke betrokken afzender een gecontroleerd bericht produceren voor een onafhankelijke mailbox en de resultaten van de vertrouwde ontvanger vastleggen. Een DNS-only validator kan niet bevestigen welke selector de afzender daadwerkelijk gebruikt en of de doorgegeven identiteit overeenkomt.
Als herstel noodzakelijk is, herstel dan alleen de betrokken eerdere recordset en herhaal de relevante workflowtests. Bewaar bewijs van gehoste beleidsinstellingen en DNS waarden, omdat de eerste onafhankelijk kunnen veranderen. Toegang tot huidige accounts, interface-screenshots, gezaghebbende voor-en-na-opnames, bewijs van ontvangen berichten en menselijke goedkeuring van het MKB zijn nog in behandeling voor deze gids. Er zijn geen DNS bewerkingen of live tests uitgevoerd.
Houd openbare registers gescheiden van cryptografische bewerkingen
Het publiceren van een openbare sleutel versleutelt niet de hoofdtekst van de e-mail, creëert geen handtekening en garandeert niet dat het hele bericht veilig is. Gebruik de DKIM standaard voor het ondertekenen van semantiek in plaats van de vereenvoudigde encryptie-uitleg van het providerartikel. Controleer de daadwerkelijke ondertekende inhoud en het resultaat van de ontvanger nadat de zenderoperator de activering heeft voltooid.
Scheid berichtacceptatie van beleidsuitrol
Een goed uitgelijnd SPF resultaat kan voldoen aan een berichtevaluatie, maar rechtvaardigt niet alleen het verplaatsen van een heel domein om te weigeren. RFC 9989 Sectie 7.4 vereist een geldige DKIM voor het publiceren van domeinen p=reject en waarschuwt voor interoperabiliteit van indirecte post. Inventariseer alle legitieme afzenders en indirecte routes voordat de beleidseigenaar de handhaving goedkeurt. Voor dit artikel zijn geen DNS wijzigingen, tenantbewerkingen of ontvangen berichtentest uitgevoerd.