DKIM-record: instellen, selectors en sleutelrotatie

Dalende openpercentages zijn geen bewijs van een DNS-fout: privacy en tracking beïnvloeden de meting ook. Controleer naast inhoud en doelgroep je authenticatie, waaronder het DKIM-record.

SPF controleert de verzendende IP voor een envelopidentiteit. DKIM, DomainKeys Identified Mail, lijkt op een verzegeling: het verifieert de ondertekende delen van een bericht en het ondertekenende domein, niet de volledige menselijke afzenderidentiteit. Sinds 2024 stellen Google en Yahoo aanvullende eisen aan bepaalde bulkafzenders. Ontbrekende of ongeldige DKIM kan filtering beïnvloeden, maar veroorzaakt niet automatisch onzichtbare mail of spam bij iedere inbox.

Voor een oprichter kan instellen een klus van tien minuten lijken, zonder dat dit een gegarandeerde duur is. Voor een MSP met 500 domeinen vragen rotaties, selectors en DNS-syntaxis blijvende aandacht; een fout kan ook op vrijdag om 9 uur 's avonds opvallen.

Dit is een praktische beheergids voor je DKIM-record: DNS-werking, de grens van 255 octetten per TXT-tekenreeks en onderzoek wanneer een geverifieerde status bij je ESP niet overeenkomt met echte verzending.

Wat is een DKIM-record?

Een DKIM-record publiceert een cryptografische publieke sleutel in DNS, doorgaans als TXT. Daarmee controleren ontvangers een handtekening van het ondertekenende domein en de integriteit van de ondertekende inhoud volgens de gebruikte canonicalisatie. Dat authenticeert niet automatisch het zichtbare From-domein of iedere berichtinhoud.

De sleutel wordt opgezocht op selector._domainkey.yourdomain.com, waarbij selector de sleutel aanwijst. Dit minimale voorbeeld is afgekort en niet geschikt voor publicatie:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1 noemt de versie, k=rsa het sleuteltype en p= de base64-gecodeerde publieke sleutel. De bijbehorende privésleutel hoort in beveiligde verzendinfrastructuur, nooit in DNS. De uitleg over een DKIM-record maken behandelt de velden en inrichting verder.

Wat DKIM ondertekent en waarom dat telt

DKIM is meer dan een vinkje. Het koppelt een handtekening aan een ondertekenend domein en beschermt de integriteit van de gedekte inhoud, niet noodzakelijk alle headers of de volledige identiteit van de auteur.

De server kiest headers, vaak From, Subject, Date, To en Message-ID, plus de gedekte body. From moet ondertekend zijn; de overige keuze hangt van de configuratie af. Daarbij wordt doorgaans SHA-256 gebruikt. De server ondertekent met de privésleutel en voegt een DKIM-Signature-header toe. De exacte dekking en canonicalisatie staan in de handtekening.

Een ontvanger zoals Gmail of Outlook voert vervolgens onder meer deze controles uit:

1. Lees DKIM-Signature om selector en ondertekenend domein te bepalen.
2. Zoek de publieke sleutel op selector._domainkey.yourdomain.com in DNS.
3. Verifieer de cryptografische handtekening met die sleutel; dit is geen gewone ontsleuteling van het bericht.
4. Bereken de relevante hashes opnieuw uit de ontvangen, gecanonicaliseerde inhoud.
5. Controleer overeenkomsten én de overige sleutel- en handtekeningvoorwaarden. Dat bepaalt of verificatie slaagt of faalt.

Een geslaagde controle ondersteunt twee eigenschappen: authenticiteit van de handtekening namens het ondertekenende domein en integriteit van de gedekte, gecanonicaliseerde inhoud. Niet iedere gewijzigde byte maakt DKIM ongeldig: toegestane normalisatie kan verschillen opvangen. De publieke sleutel maakt verificatie mogelijk. RFC 6376 beschrijft het basismechanisme en is nuttig bij technische discussies over correcte implementatie.

Doorsturen en het behoud van DKIM

Een directeur stuurt een factuur naar een contactpersoon die alles naar persoonlijke Gmail doorstuurt. Blijft de oorspronkelijke envelopafzender staan, dan kan SPF falen omdat de IP van de doorstuurserver niet geautoriseerd is. DMARC faalt pas wanneer noch succesvolle uitgelijnde SPF, noch een geldige uitgelijnde DKIM-handtekening aanwezig is. Filtering of weigering hangt vervolgens van de ontvanger af.

DKIM kan zo'n doorstuurroute overleven als de relevante ondertekende headers en body geldig blijven en de sleutel en overige voorwaarden kloppen. De oorspronkelijke handtekening kan aan het einde tegen DNS worden geverifieerd, maar wijzigingen door tussenliggende systemen kunnen haar ongeldig maken.

Vertrouw daarom niet uitsluitend op SPF. Combineer DKIM met een passende SPF-inrichting; de gids over SPF voor e-mail behandelt de basis. DMARC kan dan via een van beide uitgelijnde methoden slagen, zonder garantie op aflevering.

TrekMail beschrijft doorsturen met SRS (Sender Rewriting Scheme), dat het envelopadres voor SPF van de doorstuurdienst kan herschrijven. Het herstelt niet automatisch oorspronkelijke From-uitlijning. Verifieer op de actuele uitgaande routes of DKIM-ondertekening actief is; ga niet uit van één gegarandeerde standaard voor alle configuraties.

Selectors: meerdere DKIM-sleutels beheren

Een DKIM-selector wijst de publieke sleutel aan die de ontvanger moet ophalen. Een onjuiste selector of DNS-naam is een belangrijke mogelijke oorzaak van verificatiefouten, maar niet aantoonbaar de oorzaak van de meeste fouten.

SPF heeft één beleid per geëvalueerde DNS-naam; DKIM kan verschillende selectors gebruiken op selector._domainkey.yourdomain.com. Zo kun je tien selectors tegelijk beheren, bijvoorbeeld een per verzenddienst. Praktische provider- en DNS-grenzen blijven gelden: dit is geen algemene belofte van onbeperkte records.

Waarom meerdere selectors helpen

Bij meerdere verzenddiensten, bijvoorbeeld Google Workspace en Mailchimp, zijn afzonderlijke sleutels en selectors doorgaans wenselijk. Een gedeelde privésleutel vergroot het risico en bemoeilijkt intrekking; gebruik de configuratie die iedere dienst ondersteunt. Deze namen zijn voorbeelden, geen universele providerinstellingen:

• Google Workspace: Een selector kan google zijn, met een sleutel op google._domainkey.yourdomain.com.
• Mailchimp: Kan k1 of k2 gebruiken; controleer het voorgeschreven TXT- of CNAME-record voor k1._domainkey.yourdomain.com.
• TrekMail: Een voorbeeld is tm1 op tm1._domainkey.yourdomain.com. Gebruik alleen de daadwerkelijk ondersteunde TXT- of CNAME-configuratie.

Afzonderlijke selectors maken gerichte intrekking mogelijk, bijvoorbeeld van k1 na een incident bij een marketingdienst. Andere sleutels hoeven dan niet te worden ingetrokken, maar continuïteit en reputatie zijn niet gegarandeerd: DNS-caches en gedeelde configuratie kunnen meespelen. De selectorgids legt namen, syntaxis en toegewezen ESP-selectors uit.

Een klassieke naamfout

Je bedoelt google._domainkey.yourdomain.com, maar het DNS-paneel voegt het domein opnieuw toe en maakt google._domainkey.yourdomain.com.yourdomain.com. Op de bedoelde naam kan dan NXDOMAIN verschijnen. Een ESP-status kan verouderd zijn; controleer de echte naam en antwoorden. De gids DNS-status controleren helpt dit met een gerichte DNS-query onderzoeken.

Sleutellengte en rotatiebeleid

De sleutel bepaalt mede de beveiliging van DKIM. Instellingen die vijf jaar geleden gebruikelijk waren, verdienen opnieuw beoordeling op algoritme, lengte, opslag en ontvangerseisen.

De voorkeur voor sleutels van 2048 bits

RSA-sleutels van 1024 bits waren jarenlang gangbaar. Google noemt nog een minimum, terwijl voor sterkere inrichting 2048 bits wordt aanbevolen; controleer afzonderlijk Yahoos huidige richtlijnen. Een oude cPanel- of Postfix-configuratie met 1024 bits van vóór 2019 verdient inspectie, niet de aanname dat iedere verificatie noodzakelijk faalt.

Een sleutel van 512 bits is onvoldoende voor moderne eisen. Bij dkim=perm_fail met "weak key" of "policy" onderzoek je de volledige reden. Overweeg een nieuw paar van 2048 bits en een gecontroleerde overgang, met onmiddellijke incidentmaatregelen bij compromittering. Zie Googles afzenderrichtlijnen.

Hoe vaak roteren?

Jaarlijkse rotatie is een mogelijk intern beheerbeleid, geen universele DKIM-verplichting. Kies een frequentie op basis van risico en providerbeheer. Een gelekte privésleutel vereist directe reactie: een aanvaller kan ermee tekenen zolang verificatie tegen de bijbehorende sleutel mogelijk blijft. Bewaak ook je domeinreputatie.

Behandel de privésleutel als een gevoelig geheim. Vijf jaar ongewijzigd gebruik is een aanleiding om risico en beleid te beoordelen; veilige opslag, toegangsbeheer en incidentrespons zijn minstens zo belangrijk als een kalender.

De DNS-grens van 255 octetten en de oplossing

Bij de overstap naar 2048 bits kan de lengte verrassen. Een publieke sleutel van 2048 bits heeft base64-gecodeerd ongeveer 400 tekens. DNS TXT staat maximaal 255 octetten per tekenreeks toe. Interfaces kunnen lange waarden splitsen, weigeren of onjuist verwerken; ga niet uit van universele stille afkapping.

Een lange waarde kan worden verdeeld over meerdere geciteerde tekenreeksen binnen hetzelfde TXT-record. RFC 6376 voorziet in samenvoegen voor verificatie. De sleutelinhoud mag daarbij niet worden afgekort of vervangen door voorbeeldtekst.

Afgekort voorbeeld, niet publiceerbaar; verwerking van lange invoer verschilt per provider:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

Schematisch voorbeeld met twee tekenreeksen; vervang alle placeholders door de volledige sleutel:

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

Invoer verschilt per DNS-provider. Haakjesnotatie kan bij zonebestanden horen en is niet overal paneelinvoer. Zie DNS instellen bij bekende providers voor Cloudflare, Route 53, GoDaddy en andere diensten; controleer hun actuele interface.

Een ondersteunde CNAME-configuratie kan sleutelpublicatie delegeren. Het beschreven model gebruikt één korte verwijzing in plaats van een sleutel van meer dan 255 tekens. Dat kan lokaal onderhoud verminderen, maar controleer de doelnaam, sleutelpublicatie en rotatieprocedure; een onveranderde CNAME maakt rotatie niet automatisch foutloos.

De inrichting verifiëren

Een ESP-badge "Verified" kan op eerder verzamelde gegevens berusten, soms van uren of dagen geleden. Onderzoek actuele DNS-antwoorden én een daadwerkelijk ondertekend testbericht. Een DNS-query alleen bewijst nog niet dat de server correct ondertekent.

Stap 1: bestaat de sleutelnaam?

Gebruik een terminal op Linux of macOS. Op Windows kun je nslookup uitvoeren:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Vervang selector door de daadwerkelijke selector en yourdomain.com door je domein.

Een passende sleutelwaarde kan beginnen met v=DKIM1, al is die versietag niet in alle geldige sleutelrecords verplicht. NXDOMAIN vraagt onderzoek. Een NXDOMAIN-antwoord wijst op een ontbrekende naam in het betreffende antwoord: controleer selector, publicatie en caches. Opnieuw testen na 30 minuten is slechts een voorbeeld, geen vaste DNS-termijn.

Stap 2: controleer de sleutelinhoud

Bestaat het record maar faalt verificatie, bekijk dan de ruwe waarde:

dig txt selector._domainkey.yourdomain.com +short

Let op twee punten:

• Afkapping: Een base64-waarde van minder dan 200 tekens bij een vermeende sleutel van 2048 bits is een aanwijzing om de volledige gedecodeerde sleutel te controleren, geen zelfstandig bewijs dat de provider heeft afgekapt.
• Gewijzigde tekens: Bekijk hoe het paneel regelafbrekingen, witruimte en escapes in base64 verwerkt. Niet iedere visuele wijziging verandert de sleutel. Vergelijk de uiteindelijk gepubliceerde en gedecodeerde waarde met de bedoelde publieke sleutel.

Stap 3: test verzending en lees headers

Stuur naar je eigen Gmail-account en kies "Origineel weergeven" via het menu met drie puntjes. Zoek Authentication-Results, maar vertrouw alleen resultaten die de ontvangende dienst zelf heeft toegevoegd. Dit is een illustratief resultaat:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass bevestigt een geslaagde controle voor die test. Bij fail, neutral, perm_fail of temperror lees je de providerafhankelijke reden; deze labels zijn niet overal identieke protocolresultaten. De DKIM-instelgids geeft verdere context. Gebruik ook TrekMails checklist voor eerste inrichting voor samenhangende authenticatiestappen.

DKIM-fouten: drie praktijksituaties

Een bestaand record op de juiste selector garandeert geen geldige handtekening. Controleer bij aanhoudende fouten de berichtverwerking, gebruikte sleutel en de daadwerkelijke DNS-antwoorden.

De uitgebreide DKIM-foutengids biedt meer detail. Deze drie situaties komen geregeld voor, maar vormen geen bewezen ranglijst van alle productieproblemen.

Situatie 1: "Body Hash Did Not Verify"

Bij e-mailbezorgbaarheid wijst deze melding op een afwijkende bodyhash. Mogelijk is de gedekte inhoud na ondertekening veranderd. De melding bewijst op zichzelf niet dat de headerhandtekening verder cryptografisch geldig is; onderzoek beide controles.

Mogelijke oorzaken:

• Waarschuwingen voor externe afzenders: Een gateway voegt "EXTERNAL EMAIL: CAUTION" toe. Gebeurt dit vóór verificatie en verandert het de gedekte body buiten toegestane canonicalisatie, dan kan DKIM falen. Bekijk ook mailflowregels in Microsoft 365.
• Juridische voetteksten: Een gateway voegt een disclaimer van 15 regels toe nadat de mailboxserver heeft ondertekend. Dat kan de bodyhash veranderen. Laat bij eigen uitgaande verwerking de definitieve versie ondertekenen.
• Herschreven URL's: Mimecast, Proofpoint en Defender for Office 365 kunnen voor phishingbescherming google.com herschrijven naar protect.mimecast.com/s/.... Een wijziging van de gedekte body kan de handtekening ongeldig maken; timing en dekking zijn bepalend.

Onderteken eigen uitgaande mail na de laatste door jou beheerde inhoudswijziging. Dat voorkomt bepaalde lokale fouten, maar niet wijzigingen bij latere ontvangers of doorstuurdiensten. Controleer bij TrekMail de daadwerkelijke ondertekenroute en huidige configuratie. De documentatie over verzendfouten helpt het onderzoek verder.

Situatie 2: uitlijning

Een geldige handtekening kan samengaan met DMARC-falen. Je ziet bijvoorbeeld:

dkim=pass (signature was valid)

DKIM slaagt, maar mogelijk niet voor het juiste domein. Onderzoek DKIM-uitlijning en de andere geldige authenticatiemethoden; DMARC-falen leidt niet automatisch bij iedereen tot spam.

DMARC vergelijkt het ondertekenende domein in d= met het domein van Header From. Strict alignment vereist exact dezelfde naam; relaxed alignment kan hetzelfde organisatiedomein accepteren. Eén geldige uitgelijnde DKIM-handtekening of succesvolle uitgelijnde SPF is voldoende.

Een illustratie:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

De handtekening is geldig voor sendgrid.net, maar het gepubliceerde DMARC-beleid hoort bij het zichtbare afzenderdomein yourcompany.com, niet bij het domein van de ontvanger. sendgrid.net != yourcompany.com. Deze handtekening is niet uitgelijnd; DMARC faalt alleen als geen andere geldige uitgelijnde methode slaagt.

Onderzoek domeinauthenticatie of aangepaste ondertekening bij je ESP. Een eigen DKIM-sleutel kan d= instellen op yourcompany.com in plaats van sendgrid.net, waar ondersteund. Mogelijkheden verschillen per dienst en abonnement. Begrijp ook DMARC-uitlijning en test alle verzendroutes.

Situatie 3: oude of zwakke sleutels

Bij dkim=perm_fail met "policy" of "weak key" kunnen oude sleutels van 512 of 768 bits relevant zijn, maar ook andere oorzaken bestaan. Controleer de daadwerkelijke sleutel en providerreden. Verouderde lengtes kunnen niet aan actuele ontvangereisen voldoen; het label alleen bewijst geen specifieke sleutelgrootte.

Genereer waar passend een nieuw paar van 2048 bits en gebruik een nieuwe selector. Publiceer en verifieer eerst, schakel ondertekening om en behoud de oude publieke sleutel zolang legitieme onderweg zijnde berichten die nodig hebben. Bij een gelekte sleutel kan onmiddellijke intrekking belangrijker zijn. Zie de offline generatorrichtlijnen hieronder.

Sleutelgenerators: veiligheid beoordelen

Een DKIM-record vereist een passende publieke sleutel en beveiligde privésleutel. Kom je bij een website die een sleutelpaar toont, beoordeel dan eerst waar de privésleutel wordt gegenereerd en wie haar kan zien.

Een door een onbekende server gegenereerde privésleutel kan zijn opgeslagen of ingezien. Alleen weergave in een browser bewijst niet automatisch compromittering, bijvoorbeeld bij gecontroleerde lokale generatie, maar onbekende webdiensten zijn geen geschikte basis voor productiegeheimen. Bij blootstelling moet je reageren; misbruik is niet per definitie onbeperkt na intrekking.

Generatiemethoden vergelijken

Voor een eigen mailserver kun je lokaal OpenSSL gebruiken. Beveilig bestandsrechten en opslag voordat je deze illustratieve opdrachten uitvoert:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

Houd de privésleutel beveiligd. Alleen de correct gecodeerde inhoud van de publieke sleutel gaat in DNS; de getoonde leesopdracht verwijdert PEM-headers niet zelf. Deel een privésleutel niet per e-mail voor "verificatie" en verifieer verzoeken via een vertrouwd kanaal.

Voor oprichters, bureaus en andere gebruikers kan providerbeheer praktischer zijn. Controleer of de verzenddienst generatie, beveiligde opslag en rotatie ondersteunt, in plaats van dit stilzwijgend aan te nemen.

DKIM-beheer: handmatig of geautomatiseerd

Rotatie maakt beheerkosten zichtbaar. De onderstaande jaarlijkse routine is een beleidsvoorbeeld; iedere sleutel vraagt passende controle, ook als een provider het technische werk uitvoert.

Handmatige rotatie: een jaarlijks voorbeeld per domein

1. Genereer een nieuw RSA-paar met een nieuwe selector, bijvoorbeeld s2026.
2. Publiceer de publieke sleutel op s2026._domainkey.yourdomain.com.
3. Het voorbeeld reserveert 48 uur voor DNS; bepaal werkelijk wachten aan de hand van TTL, caches en geverifieerde antwoorden.
4. Configureer de server om met de nieuwe privésleutel te ondertekenen en test.
5. Het voorbeeld houdt beide selectors 7 dagen beschikbaar; stem overlap af op wachtrijen, onderweg zijnde berichten en risico.
6. Verwijder de oude publieke selector pas na de passende verificatieperiode, behalve wanneer incidentrespons eerdere intrekking vereist.
7. Vernietig de oude privésleutel veilig volgens je bewaarbeleid.

Dit voorbeeld heeft 7 stappen per domein per jaar. Voor 50 domeinen zijn dat 350 handelingen, geen onvermijdelijk exact werkvolume. Stap 5 overslaan kan verificatie van onderweg zijnde mail beïnvloeden; stap 6 vergeten kan een oude sleutel langer beschikbaar houden dan bedoeld. Automatiseer en controleer waar nuttig.

Voor één domein kan handmatig beheer goed uitvoerbaar zijn. Bij 50 domeinen helpt automatisering om herhaling en planning te beheersen. Toch is geen aanpak automatisch onwerkbaar of vrij van fouten; houd bewijs van publicatie, rotatie en tests bij.

Hoe TrekMail DKIM kan beheren

TrekMail richt zich op beheerders van meerdere domeinen, van een oprichter met vijf nevenprojecten tot een MSP met 800 klantdomeinen. Beoordeel de actuele DKIM-inrichting voor jouw verzendroutes.

Rotatie met CNAME-delegatie

De bron beschrijft één CNAME bij domeintoevoeging. Dit is een configuratievoorbeeld, geen bevestiging van de huidige doelnaam of ondersteuning:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Een verwijzing kan lokaal ongewijzigd blijven terwijl de provider sleutelpublicatie beheert. Controleer hoe nieuwe selectors, caches en oude handtekeningen tijdens rotatie worden behandeld; dezelfde selector simpelweg overschrijven kan onderweg zijnde mail breken. Ook bij 80 domeinen blijven monitoring en incidentrespons nodig. Het beschreven model garandeert geen rotatie zonder onderbreking of beheeractie.

Een Pro-voorbeeld van $8 per maand voor 100 domeinen vergelijkt het model met 700 jaarlijkse handmatige handelingen. Dit is illustratieve rekenkunde op basis van de gekozen routine, geen gegarandeerde besparing of actuele prijs.

Begeleide DNS-wizard

De beschreven wizard helpt MX, SPF, DKIM en DMARC opstellen en controleren. Verifieer huidige functies, autoritatieve DNS en relevante resolvercaches, plus echte ondertekende mail. Een dashboardstatus is geen volledige verificatie van alle verzendroutes. Zie vereiste DNS-records.

Platformprijzen in plaats van alleen gebruikersprijzen

De bron noemt Starter op $3.50 per maand met 50 domeinen en 100 gebruikers per domein, Pro op $8 per maand met 100 domeinen en 300 gebruikers per domein en Agency met 1,000+ domeinen. Opslag wordt als gedeeld beschreven. Controleer actuele prijzen, grenzen en functies; extra mailboxen zijn niet onder alle omstandigheden kosteloos.

DKIM wordt als onderdeel van de DNS-inrichting beschreven. Bevestig welke authenticatiefuncties iedere huidige bundel en verzendroute werkelijk ondersteunt, inclusief eigen SMTP.

Je DKIM-record beheren: eigen beheer of delegatie

Conclusie

Een correct DKIM-record is belangrijk voor moderne authenticatie en toepasselijke afzendereisen in 2025 en daarna. Ontbrekende DKIM betekent niet automatisch DMARC-falen wanneer uitgelijnde SPF slaagt, en niet iedere doorstuurroute beschadigt reputatie. Controleer beide methoden en het ontvangersbeleid.

Begin bij passende sleutels, bijvoorbeeld RSA van 2048 bits, de juiste selector, volledige TXT-publicatie en DKIM-uitlijning met Header From. Richt daarna gecontroleerde rotatie, DMARC-beleid en monitoring in, bijvoorbeeld met Google Postmaster Tools, rekening houdend met de beschikbare gegevens.

De vergelijking van SPF, DKIM en DMARC verduidelijkt hun verschillende rollen. Bij actuele bezorgproblemen helpt de gids voorkomen dat mail in spam belandt de controles te prioriteren; pas de volgorde aan concrete meldingen aan.

Bij meerdere domeinen kunnen sleutel-, publicatie- en uitlijningsfouten betrokken verzendroutes raken. Delegatie kan handwerk verminderen, maar verwijdert deze foutcategorieën niet volledig. Bekijk de abonnementen en verifieer de huidige voorwaarden van het beschreven gratis aanbod voor 10 domeinen zonder creditcard.