Belangrijkste Conclusies
- Volgens RFC 1035 mogen standaard DNS -strings maximaal 255 tekens lang zijn.
- Veilige openbare DKIM -sleutels van 2048 bits bestaan doorgaans uit meer dan 400 tekens, waardoor het bij strikte DNS-hostingproviders noodzakelijk is om ze op te splitsen in meerdere reeksen.
- Een veelvoorkomende, cruciale misvatting is dat er twee afzonderlijke DNS-records worden aangemaakt voor de opgesplitste delen. In plaats daarvan moet je één enkel TXT-record publiceren waarin beide tekenreeksen tussen aanhalingstekens in precies hetzelfde waardeveld staan.
- Een gratis tool aan de gebruikerszijde, zoals de PowerDMARC DNS Record Splitter, voert de berekeningen direct en veilig uit, zonder dat uw gegevens ooit uw browser verlaten.
Het instellen van e-mailverificatie is zo’n klusje waarvan je denkt dat het maar vijf minuten duurt, totdat je tegen een muur aanloopt. Je genereert je beveiligde 2048-bits DKIM-sleutel, gaat naar je DNS-provider, plakt deze in het veld voor een nieuw TXT-record en klikt op ‘Opslaan’.
In plaats van een succesmelding verschijnt er een foutmelding op je scherm. AWS Route 53 geeft een cryptische foutmelding ‘CharacterStringTooLong’ weer. Google Cloud DNS meldt ronduit dat je ‘ongeldige recordgegevens’ hebt.
Mocht je bij het toevoegen van je DKIM-record tegen de limiet van 255 tekens aanlopen, maak je dan geen zorgen; je sleutel is niet beschadigd en je hoeft je beveiliging niet te verlagen. Je hoeft je DKIM TXT-record alleen maar op de juiste manier in meerdere delen op te splitsen. Het opsplitsen van een DKIM-record is een standaard, veilige beheerprocedure en zodra het is gepubliceerd, zullen DNS-resolvers de fragmenten automatisch naadloos weer aan elkaar koppelen.
Laten we eens nader bekijken waarom dit precies gebeurt en hoe je dit stap voor stap kunt oplossen met handmatige methoden of een automatische DNS-recordsplitter.
Waarom DKIM-records moeten worden opgesplitst
De noodzaak om DKIM-records op te splitsen vloeit voort uit de basisregels van het internet. Volgens RFC 1035, paragraaf 3.3.14, mag een enkele tekenreeks in een DNS TXT-record maximaal 255 tekens (of octetten) bevatten. Deze limiet is ingesteld omdat de lengte van een tekenreeks in een standaard DNS-pakket in één byte wordt opgeslagen, waardoor deze niet langer mag zijn dan 255 tekens.
Deze structurele beperking is van groot belang, afhankelijk van de lengte van uw cryptografische sleutels:
- 1024-bits DKIM-sleutels: deze reeksen met openbare sleutels zijn kort en passen doorgaans zonder aanpassingen ruimschoots binnen de limiet van 255 tekens.
- 2048-bits DKIM-sleutels: Deze sleutels bieden aanzienlijk meer beveiliging, maar genereren een Base64-reeks voor de openbare sleutel die bijna altijd tussen de 350 en meer dan 500 tekens lang is.
Aangezien een DKIM-sleutel van 2048 bits per definitie langer is dan de limiet van 255 tekens, kan deze niet in één aaneengesloten tekenreeks worden weergegeven.
Hoe deze grens wordt behandeld, hangt volledig af van uw DNS-hostingprovider. Vanaf 2026 vallen de grote platforms nog steeds in twee kampen uiteen:
- Strikte providers: Diensten zoals AWS Route 53, Google Cloud DNS en Azure DNS houden zich strikt aan RFC 1035 op het niveau van de gebruikersinterface. Als je een tekenreeks van 300 tekens invoert, wordt deze onmiddellijk geweigerd.
- Automatische providers: Platforms zoals Cloudflare, GoDaddy en cPanel voeren deze opmaak vaak onopgemerkt op de achtergrond uit, waarbij ze het record intern opsplitsen, zodat u dit niet handmatig hoeft te doen.
Belangrijke opmerking: Het splitsen van een record heeft geen invloed op uw DKIM-handtekening en zorgt er niet voor dat deze ongeldig wordt. Wanneer een inkomende mailserver de openbare DKIM-sleutel van uw domein opzoekt, voegt de DNS-resolver de gesplitste tekenreeksen automatisch weer samen tot één aaneengesloten tekenreeks voordat de cryptografische handshake wordt verwerkt.
Hoe een DKIM-record opsplitsen (stap voor stap)
Om uw record correct te splitsen zonder dat uw cryptografische gegevens ongeldig worden, moet u gestructureerde opmaakregels volgen.
Hier ziet u een voorbeeld van een ongesplitst, onbewerkt 2048-bits DKIM-record, een enkele aaneengesloten tekenreeks die door strikte providers wordt geweigerd, gevolgd door dezelfde sleutel die correct is opgesplitst:
Voorheen – één aaneengesloten reeks (410 tekens, afgewezen):
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDDj8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB
Daarna – één TXT-record, twee tussen aanhalingstekens geplaatste tekenreeksen, gesplitst op de grens van 255 tekens:
“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDD”
“j8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB”
Een DKIM-sleutel van 2048 bits opsplitsen
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…wIDAQAB
Eén aaneengesloten tekenreeks – 410 tekens die wordt geweigerd door AWS Route 53 / Google Cloud DNS
↓ splitsen op de grens van 255 tekens
Één TXT-record — twee tekenreeksen tussen aanhalingstekens
“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…”
blok 1 · 255 tekens
“…zrIZtoLuCr64CxqlIOdNKhiwIDAQAB”
deel 2 · rest (≈155)
precies één spatie tussen de stukken, zonder spaties binnen de stukken zelf.
Stap 1: Zoek je volledige DKIM-record op
U kunt inloggen op het dashboard van uw e-maildienst (zoals Google Workspace, Microsoft 365, SendGrid of Mailchimp) om uw gegenereerde openbare sleutel te vinden. De tekst begint altijd met bepaalde tags en volgt doorgaans precies deze indeling:
v=DKIM1; k=rsa; p=[Een zeer lange Base64-reeks]
Je kunt ook onze gratis DKIM-recordchecker gebruiken om je record binnen enkele seconden op te zoeken:

Om te controleren of opsplitsen echt nodig is, kopieer je de volledige waarde en plak je deze in een eenvoudige teksteditor om de totale lengte te bekijken. Als het aantal tekens hoger is dan 255, moet je de waarde opsplitsen.
Stap 2: Verdeel de sleutelwaarde in stukken van 255 tekens
Je hebt twee mogelijkheden om je gegevens op te splitsen: handmatig rekenen of een automatisch hulpprogramma gebruiken.
De handmatige methode
Open je teksteditor en tel precies 255 tekens vanaf het begin van je record (inclusief het voorvoegsel v=DKIM1; k=rsa; p=). Splits de tekenreeks precies op die grens van 255 tekens.
Je moet elk afzonderlijk fragment tussen een eigen paar dubbele aanhalingstekens (“”) plaatsen. Het is van cruciaal belang dat er geen spaties in de fragmenten staan, maar dat er precies één enkele spatie staat tussen het sluitende aanhalingsteken van het eerste fragment en het openingsaanhalingsteken van het tweede fragment.
De automatische methode (aanbevolen)
Om menselijke fouten te voorkomen, kunt u het handmatig tellen van tekens achterwege laten en de gratis tool ‘DNS Record Splitter’ van PowerDMARC gebruiken.
- Ga naar de toolpagina.

- Plak uw volledige, ongesplitste DKIM TXT-record in het invoerveld.

- Kies de formaatoptie 'Quoted' (vereist door strikte providers zoals AWS en Google).

- Klik op 'Record splitsen' om direct correct opgemaakte tekenreeksen te genereren.

- Zo zou het resultaat eruit moeten zien:

Stap 3: Voeg het split-record toe aan je DNS
Een veelgemaakte fout onder beheerders is dat ze in hun DNS-paneel twee afzonderlijke TXT-records proberen aan te maken, één voor elk deel. Doe dit niet; hierdoor zal de authenticatie volledig mislukken.
U moet één enkel TXT-record toevoegen. Plak in uw DNS-beheerinterface beide tekstfragmenten tussen aanhalingstekens in het veld ‘Waarde / Gegevens ’. Bij de meeste standaardproviders scheidt u ze met een enkele spatie:
“v=DKIM1; k=rsa; p=CHUNK1” “CHUNK2”
(Opmerking: als je AWS Route 53 gebruikt, sla dan de indeling met één regel witruimte over en volg de platformspecifieke methode voor regeleinden in het gedeelte over de provider hieronder.)
Stap 4: Controleer het DKIM-record
Zodra u uw wijzigingen hebt opgeslagen, moet u even wachten tot de DNS-wijzigingen overal op het internet zijn doorgevoerd. Hoewel dit meestal binnen 5 tot 30 minuten gebeurt, kan het soms tot 48 uur duren, afhankelijk van de TTL-instellingen (Time to Live) van uw zone.
Om er zeker van te zijn dat alles perfect werkt, kun je de gratis DKIM Lookup-tool van PowerDMARC gebruiken om te controleren of je record is gepubliceerd en correct wordt omgezet.
Pro-tip: Als je je werk nog even wilt controleren voordat je wacht tot de DNS-updates zijn doorgevoerd, kopieer dan de definitieve tekenreeks die je hebt samengesteld en plak deze terug in de DKIM-recordsplitter om te controleren of geen van beide segmenten de limiet van 255 tekens overschrijdt.
Als de test slaagt, krijg je je volledige, samengevoegde cryptografische sleutel terug met de status ‘groen’. Als de test mislukt, controleer dan op problemen zoals afgeknotte gegevens (ontbrekende gegevens), een ontbrekend secundair blok of syntaxfouten door niet-gesloten aanhalingstekens.
DKIM-records opsplitsen per DNS-provider
Verschillende DNS-beheerpanelen verwerken TXT-invoer met meerdere tekenreeksen op verschillende manieren. Hieronder wordt uitgelegd hoe je de instellingen op de vier meest gangbare platforms kunt configureren:
AWS Route 53
Amazon Route 53 hanteert strikte limieten en geeft een CharacterStringTooLong-foutmelding als een afzonderlijke tekenreeks geen aanhalingstekens bevat of langer is dan 255 tekens. Aangezien DNS-resolvers opeenvolgende tekenreeksen samenvoegen zonder ook maar één spatie ertussen, kan het invoeren van een letterlijke spatie tussen de aanhalingstekens op één regel er per ongeluk toe leiden dat je cryptografische sleutel onbruikbaar wordt.
- Werkwijze in de console: Voer in het tekstvak van de Route 53-console elk fragment in als een afzonderlijke tekenreeks tussen aanhalingstekens op een aparte regel. Laat geen spatie achter aan het einde van de regel. Route 53 behandelt opeenvolgende regels in één tekstvak standaard als afzonderlijke tekenreeksen binnen één TXT-record en voegt deze tijdens een zoekopdracht samen.
- API/JSON-methode: Als u infrastructuur implementeert via code of de AWS API, structureer uw recordinvoer dan als een JSON-array waarbij elk afzonderlijk blok een zelfstandig array-element is: [“v=DKIM1…”, “…CHUNK2”].
Google Cloud DNS
Google Cloud DNS geeft een algemene waarschuwing over ‘ongeldige recordgegevens’ weer als u een lange, onopgemaakte tekenreeks probeert in te voeren. Om dit in de gebruikersinterface van de Google Cloud Console op te lossen, plakt u de tekst niet op één regel. Zet in plaats daarvan elk deel tussen dubbele aanhalingstekens en gebruik de knop ‘Item toevoegen’ om meerdere opeenvolgende gegevensvelden binnen dezelfde set bronrecords te genereren.
Cloudflare
Cloudflare beschikt over een intelligente backend die lange TXT-strings bij het opslaan automatisch parseert en deze zonder tussenkomst van de gebruiker opsplitst in segmenten die voldoen aan de RFC-normen. Het vertrouwen op geautomatiseerde parsing kan echter af en toe tot uitzonderingsgevallen leiden bij complexe sleutels. De beste werkwijze blijft het handmatig plakken van je vooraf opgesplitste, tussen aanhalingstekens geplaatste strings rechtstreeks in het Cloudflare-dashboard.
cPanel / WHM
Oudere versies van de cPanel Zone Editor hanteren een strikte limiet van 255 tekens voor standaard tekstinvoervelden. Als uw standaardinterface deze lengte niet accepteert, ga dan naar de Geavanceerde DNS Zone Editor. Deze uitgebreide modus biedt de structurele flexibiliteit die nodig is om vooraf opgedeelde TXT-gegevensvelden met meerdere delen soepel in te voeren.
Veelvoorkomende fouten bij het opsplitsen van DKIM-records
Als u uw split-record hebt geïmplementeerd, maar authenticatiecontroles uw domein als verdacht markeren, controleer dan of er geen sprake is van deze drie veelvoorkomende configuratiefouten:
1. DKIM-handtekening mislukt na splitsing
- De oorzaak: Er is per ongeluk een spatie ingevoegd binnen een van je Base64-cryptografische blokken, in plaats van strikt tussen de sluitende en openingsaanhalingstekens.
- De oplossing: kopieer je onbewerkte sleutel naar een leeg bestand, verwijder alle interne witruimte volledig uit de tekenreeks met de waarde p=, en voer het splitsingsproces opnieuw uit.
2. DNS toont slechts een gedeeltelijke sleutel
- De oorzaak: Het tweede deel is opgeslagen als een volledig afzonderlijk, secundair TXT-record bij uw domeinhost, in plaats van te zijn samengevoegd in het eerste record.
- De oplossing: verwijder het secundaire record volledig. Pas je primaire DKIM TXT-record zo aan dat beide aangevulde tekenreeksen samen in het veld voor de enkele waarde staan.
3. Het record bevat meer dan 255 tekens na splitsing
- De oorzaak: Het splitsingspunt werd verkeerd berekend, waardoor een van de twee delen iets boven de limiet van 255 tekens uitkwam (vaak doordat het voorvoegsel v=DKIM1; verkeerd werd geteld).
- De oplossing: Splits uw record precies bij teken 255, of laat een automatische DNS-recordsplitser het tellen voor u doen.
Welke invloed heeft het splitsen van DKIM op DMARC?
Een veelvoorkomende zorg bij IT-managers is of het splitsen van een openbare sleutel invloed heeft op de manier waarop DMARC inkomende berichten verwerkt.
Wanneer een DKIM-record correct wordt opgesplitst, gedraagt het zich op precies dezelfde manier als een ongesplitst record. Omdat ontvangende e-mailservers de fragmenten tijdens het opzoeken weer tot één enkele tekenreeks samenvoegen, worden uw DKIM-handtekeningen naadloos gevalideerd, waardoor uw DMARC-alignment ongewijzigd blijft.
Als je split-record echter onjuist is opgebouwd of verkeerd is geformatteerd, zijn de gevolgen onmiddellijk merkbaar:
- De ontvangende e-mailserver kan uw openbare sleutel niet reconstrueren.
- De DKIM-verificatie zal mislukken.
- DMARC zal volledig moeten terugvallen op de conformiteit van uw SPF (Sender Policy Framework).
- Als ook uw SPF-afstemming mislukt (of als uw DMARC-beleid vereist dat beide protocollen op elkaar zijn afgestemd), worden uw legitieme zakelijke e-mails naar de spamfolder geleid of mogelijk zelfs direct geweigerd.
Voordat u volledig vertrouwt op de handhaving van uw DMARC-beleid, moet u uw openbare DKIM-sleutels valideren nadat u wijzigingen in de DNS hebt aangebracht.
Samenvattend
Het opsplitsen van een DKIM-record is een noodzakelijke administratieve stap bij het beheer van beveiligde 2048-bits sleutels bij strikte DNS-providers zoals AWS Route 53 of Google Cloud DNS. Het is een veilige en gangbare procedure die eenvoudig uit te voeren is zodra je de basisregels voor de opmaak kent.
Houd bij het bijwerken van je gegevens altijd de volgende basisregels in gedachten:
- Splits je tekenreeks op de grens van 255 tekens.
- Zet elk stuk tussen dubbele aanhalingstekens.
- Zet alles in één enkel TXT-record (gescheiden door een spatie bij standaardproviders, of op afzonderlijke regels bij strikte interfaces zoals AWS Route 53).
Ga niet gissen naar het aantal tekens en loop niet het risico dat je e-mail niet werkt. Sla het handmatig rekenen over en pas je sleutel direct aan met de gratis PowerDMARC DNS Record Splitter Tool, waarvoor je je niet hoeft aan te melden.
Veelgestelde Vragen
Wat is een DNS-record-splitter?
Een DNS-recordsplitter is een hulpprogramma dat is ontworpen om een lang DNS-TXT-record op te splitsen in afzonderlijke segmenten van 255 tekens. Deze opmaakstap is noodzakelijk om ervoor te zorgen dat uw records correct kunnen worden opgeslagen bij strikte DNS-hostingproviders die het automatisch opsplitsen van tekenreeksen niet automatisch uitvoeren. De inhoud van uw record blijft volledig ongewijzigd; het wordt alleen opgemaakt in gestructureerde, kortere blokken die door ontvangende systemen bij een opzoekactie weer aan elkaar worden gekoppeld.
Welke DNS-providers vereisen het handmatig opsplitsen van records?
Verschillende grote zakelijke leveranciers hanteren op hun interface strikt de limiet van 255 tekens, waardoor u lange tekstwaarden vooraf moet opmaken voordat u ze opslaat:
- AWS Route 53: Geeft de foutmelding „CharacterStringTooLong“ weer, tenzij lange tekenreeksen worden opgesplitst in afzonderlijke blokken tussen aanhalingstekens.
- Google Cloud DNS: Weigert lange aaneengesloten tekenreeksen volledig, wat een waarschuwing 'ongeldige recordgegevens' oplevert.
- Azure DNS: vereist handmatig gescheiden en opgesplitste tekstvelden bij het rechtstreeks invoeren van tekenreeksen via het Azure Portal-dashboard of de Azure CLI.
- DigitalOcean: Splits lange TXT-invoerreeksen niet automatisch op in het standaard webcontrolepaneel.
Waarom moet ik mijn DKIM-record opsplitsen?
De belangrijkste reden om een TXT-record op te splitsen is het gebruik van een zeer veilige openbare DKIM-sleutel van 2048 bits. Terwijl 1024-bits sleutels kort genoeg zijn om in één enkele tekenreeks te passen, bevat een 2048-bits sleutel inherent tussen de 350 en meer dan 500 tekens aan cryptografische base64-gegevens. Omdat RFC 1035 Sectie 3.3.14 een enkele aaneengesloten tekenreeks beperkt tot precies 255 octetten, moeten deze lange sleutels worden opgesplitst in afzonderlijke segmenten om binnen de standaard DNS-opslagarchitectuur te passen.
Zal het splitsen van mijn record de gegevens ervan wijzigen of de e-mailvalidatie verstoren?
Nee. Het opsplitsen van een lang TXT-record heeft geen invloed op de cryptografische waarde ervan en verandert deze ook niet. Wanneer een inkomende mailserver om de authenticatie-instellingen van uw domein vraagt, leest de DNS-resolver automatisch de opgesplitste segmenten door en voegt deze weer samen tot één aaneengesloten waarde zonder scheidingstekens. De opgesplitste indeling is louter een detail van de opslag achter de schermen; de verwerkte gegevens blijven identiek.
Wat is het verschil tussen de uitvoerformaten 'Quoted' en 'Plain'?
- Aangegeven indeling (aanbevolen): Elk afzonderlijk segment van 255 tekens wordt tussen een eigen paar dubbele aanhalingstekens geplaatst (“chunk1” “chunk2”), hetzij gescheiden door een spatie op één regel, hetzij ingevoerd in opeenvolgende gegevensvelden/regels. Deze exacte indeling is vereist door strikte interfaces zoals AWS Route 53 en Google Cloud DNS om beschadiging van sleutels te voorkomen.
- Standaardformaat: De lange regel wordt opgesplitst in afzonderlijke blokken, zonder dat er dubbele aanhalingstekens of extra witruimte of leestekens worden toegevoegd. Deze indeling is bedoeld voor moderne configuratieschermen die onbewerkte tekenreeksen van meerdere regels ondersteunen, of voor zelfgehoste BIND-systeemomgevingen (Berkeley Internet Name Domain).
Is het veilig om deze tool te gebruiken voor gevoelige sleutels of vertrouwelijke gegevens?
Ja. De PowerDMARC DNS Record Splitter werkt volledig binnen uw lokale webbrowser met behulp van scripts aan de gebruikerszijde. De door u ingevoerde tekststrings verlaten uw apparaat nooit, er worden geen gegevens via het internet naar externe verwerkingsservers verzonden en er zijn geen trackinglogs of verplichte aanmeldingen vereist. Bovendien is het belangrijk op te merken dat de tool uitsluitend is ontworpen voor openbare configuraties, zoals openbare DKIM-sleutels, SPF-includes, DMARC-beleidsregels of domeinverificatierecords, die al openbaar toegankelijk zijn op het web. Privésleutels mogen nooit in een online tool worden geplakt.
- Hoe een DKIM-record splitsen - 5 juni 2026
- compauth=fail: Uitleg over Microsoft Composite Authentication - 1 juni 2026
- Is Windows Defender voldoende voor de beveiliging van kleine bedrijven? - 14 mei 2026


