DNS-records beheren

DNS is het adresboek van het internet: het vertelt de rest van de wereld waar jouwsite.nl staat, waar je post heen moet en wie er namens jou mag versturen. Deze pagina laat zien hoe je die regels bekijkt en wijzigt.

Beeld — Paneel → Hosting → Accounts → jouw account → DNS. Bovenaan staat de kiezer DNS voor waarmee je tussen de domeinen van je account wisselt. Schermafdrukken worden gemaakt met openwolf designqc en staan in .wolf/designqc-captures/.

De zone bekijken

Bovenaan de pagina staat wat je over de zone moet weten:

• Zone — de naam.
• Backend — waar de zone daadwerkelijk staat. Dat is de PowerDNS van deze server, of een externe partij zoals Cloudflare.
• Soort en Serial — het volgnummer dat bij elke wijziging omhoog gaat. Ziet een secundaire nameserver een hoger nummer, dan haalt hij de zone op.
• DNSSEC — ondertekend of uit. Zie verderop.

Daaronder staat de tabel met alle records: Naam, Type, Waarde, TTL.

corectl dns zone list
corectl dns zone show jouwsite.nl
corectl dns record list jouwsite.nl

Een record toevoegen

1. Klik Record toevoegen, of gebruik de knoppen + A, + CNAME en + MX boven de lijst als je precies dat type nodig hebt.
2. Naam — leeg of @ betekent het domein zelf. www betekent www.jouwsite.nl; achter het vak staat het stuk dat het paneel er zelf bij zet, zodat je ziet welke naam er straks staat.
3. Type — kies er een uit de lijst. Er zijn er twintig; typ de eerste letters om te zoeken. Onder elk type staat in één regel waar het voor is.
4. De velden eronder veranderen mee met het type. Kies je MX, dan vraagt het paneel om een prioriteit en een mailserver in plaats van om één vak waar allebei in moet. Kies je SRV, dan zijn het prioriteit, gewicht, poort en doel; bij CAA een vlag, een soort en een waarde.
5. Onder het formulier staat wat er straks in de zone komt te staan. Die regel komt van de server zelf en verschijnt terwijl je typt. Klopt er iets niet aan de waarde, dan staat daar de reden en blijft de opslaanknop uit — je hoeft dus niet eerst op te slaan om te weten of het goed is.
6. Onder Geavanceerd staan TTL en, bij backends die het kunnen, de proxy-schakelaar. De TTL kies je uit vaste waarden (vijf minuten tot een dag) of je typt er zelf een; de standaardwaarden kloppen bijna altijd.
7. Klik Toevoegen.

corectl dns record add jouwsite.nl www A 203.0.113.10
corectl dns record add jouwsite.nl @ MX "10 mail.jouwsite.nl."
corectl dns record add jouwsite.nl @ TXT "v=spf1 a mx ~all" --ttl 3600

# hetzelfde antwoord dat het paneel onder het formulier zet, op de opdrachtregel
corectl dns record preview jouwsite.nl @ MX "20 backup.jouwsite.nl"
    zone     jouwsite.nl
    before   jouwsite.nl 3600 IN MX 10 mail.jouwsite.nl.
    after    jouwsite.nl 3600 IN MX 10 mail.jouwsite.nl.
    after    jouwsite.nl 3600 IN MX 20 backup.jouwsite.nl.

Wijzigen is hetzelfde record opnieuw toevoegen met --replace; dat vervangt alle waarden van die naam en dat type in één keer:

corectl dns record add jouwsite.nl www A 203.0.113.55 --replace
corectl dns record remove jouwsite.nl www A

Als de waarde niet in de velden past

Naast Waarde staat de schakelaar Rauwe waarde. Die toont het record als één regel, precies zoals hij is opgeslagen. Twee momenten waarop je hem nodig hebt:

• Je hebt een waarde die je ergens vandaan kopieert — een DKIM-sleutel, een regel uit een handleiding van een dienst. Plak hem in het rauwe vak en klaar.
• Een bestaand record past niet in de velden. Dat kan: een record dat met de hand of door een ander paneel is gezet, hoeft niet de vorm te hebben die de velden verwachten. Het paneel opent zo'n waarde dan vanzélf als rauwe waarde en zegt dat erbij. Er wordt nooit iets herschreven wat het paneel niet begreep.

Terug naar de velden gaat ook, zolang de waarde erin past. Past hij niet, dan blijft het paneel staan waar het staat in plaats van je invoer weg te gooien.

Meerdere waarden op één naam

Twee MX-records op je domein zijn niet twee losse records: het is één antwoord met twee regels erin, en een mailserver die je post aflevert leest ze allebei. Het paneel toont ze daarom als één regel in de lijst, met × 2 erachter, en je bewerkt ze samen:

• Klik de regel aan en je ziet elke waarde apart, elk met Wijzigen en Verwijderen ernaast.
• Waarde toevoegen zet er een bij.
• Record verwijderen onderin haalt het hele antwoord weg.

Bij een record met één waarde kun je in Geavanceerd ook de TTL en de proxy-schakelaar aanpassen. Staan er meerdere waarden onder één naam, dan kan dat daar niet: de TTL geldt voor het hele antwoord en het paneel zou het antwoord dan even moeten afbreken en opnieuw opbouwen. Het zegt dat er dan bij.

De typen die je nodig hebt

Drie dingen die vaak misgaan:

• Een CNAME op het domein zelf (@) mag niet. Het domein heeft ook een MX en een SOA nodig, en een CNAME sluit alles daarnaast uit. Gebruik daar een A-record.
• Een naam die naar een naam wijst eindigt op een punt. jouwsite.nl. is absoluut; jouwsite.nl zonder punt wordt gelezen als jouwsite.nl.jouwsite.nl.
• De TTL is een geheugen, geen instelling. Zet je een TTL van 24 uur en verander je daarna het adres, dan zien sommige bezoekers nog een etmaal het oude. Wil je binnenkort verhuizen, zet de TTL dan eerst op 300 en pas daarna het record.

Dat zijn de zeven die je in de praktijk nodig hebt. Het paneel biedt er twintig; de overige dertien zijn er voor wie ze kent en heeft ze nodig:

Wat je niet kunt wijzigen: het SOA-record en de nameservers van de zone zelf. Die horen bij de zone en worden door de server bijgehouden; ze staan wel in de lijst, maar openen zonder invulvelden. NS onder je domein en DS vragen om een reseller, want daarmee draag je een naam over aan iemand anders.

Draait je zone bij Cloudflare, dan zijn het er achttien: Cloudflare kent geen ALIAS (gebruik daar een CNAME op het domein zelf, die vlakt Cloudflare zelf af) en geen los SPF-type (gebruik TXT). Het paneel toont die twee met de reden erbij in plaats van een knop die alleen een foutmelding oplevert.

De MX als er een mailgateway voor je server staat

Staat er een mailgateway voor de post van een domein (zie Post die tegengehouden wordt), dan wijst de MX van dát domein naar de gateway in plaats van naar de mailserver. Twee dingen zijn daarbij goed om te weten:

• Het geldt per domein. Heb je drie domeinen en staat de gateway maar voor één ervan aan, dan verandert alleen die ene MX. De andere twee blijven naar de mailserver wijzen.
• Een gateway mag uit meer machines bestaan. Dan zie je meerdere MX-regels, elk met een eigen getal ervoor — het laagste getal wordt als eerste geprobeerd, de rest is de reserve.

dig +short MX jouwdomein.nl

10 pmg1.srvnl.nl.
20 pmg2.srvnl.nl.

Hosten wij je DNS, dan staan die records er vanzelf en worden ze bijgewerkt zodra de schakelaar omgaat. mail.<jouw domein> blijft altijd naar de mailserver wijzen: dáár meldt je e-mailprogramma zich aan.

Records voor een subdomein

Een subdomeinwebsite (staging.jouwsite.nl, shop.jouwsite.nl) heeft bewust geen eigen DNS-zone. Zijn records horen in de zone van het hoofddomein — anders zou je twee zones krijgen die stilletjes uiteenlopen en zou je bij de registrar delegatierecords moeten zetten voor iets wat gewoon naast je site staat.

Wil je dus een adres voor shop.jouwsite.nl, dan voeg je in de zone jouwsite.nl een record toe met Naam shop:

corectl dns record add jouwsite.nl shop A 203.0.113.10
corectl dns record add jouwsite.nl staging CNAME jouwsite.nl.

Dezelfde regel geldt voor tekstrecords van een subdomein:

corectl dns record add jouwsite.nl _acme-challenge.shop TXT "…"

Wil je een subdomein wél als eigen zone (bijvoorbeeld omdat een klant hem zelf beheert), dan is dat een aparte zone mét delegatie — vraag daarvoor je beheerder.

Er is nog geen zone

Zegt de pagina Nog geen DNS-zone, dan beheert deze server de DNS van dit domein niet. Twee mogelijkheden:

• De zone hoort hier te staan — klik Zone aanmaken. De server vult hem meteen met de records die uit je website- en mailconfiguratie volgen.
• De zone hoort bij je registrar of bij Cloudflare — laat hem daar staan en wijzig hem daar. Een zone die op twee plekken staat, loopt stil uiteen.

corectl dns zone add jouwsite.nl --from-domain
corectl dns zone export jouwsite.nl        # de hele zone, als tekst
corectl dns zone remove jouwsite.nl

Vergeet niet dat de nameservers bij je registrar naar deze server moeten wijzen; zonder dat vraagt niemand deze zone ooit iets. Welke namen dat zijn, zie je met:

corectl dns nameserver show

DNSSEC — en waarom het standaard uitstaat

DNSSEC zet een handtekening onder je DNS-antwoorden, zodat niemand onderweg een ander adres kan invullen. Goed idee — maar het werkt pas als de laatste stap óók gezet is: het DS-record bij je registrar. Zonder die stap ondertekent je zone in het luchtledige.

Daarom staat DNSSEC hier standaard uit. Aanzetten is een bewuste handeling in twee stappen:

1. Zet in het paneel Zone ondertekenen met DNSSEC aan. De backend maakt de sleutels en publiceert het DS-record.
2. Kopieer het getoonde DS-record voor de registrar naar het beheerpaneel van je domeinnaam.

corectl dns dnssec enable jouwsite.nl     # tekent en drukt het DS-record af
corectl dns dnssec show jouwsite.nl
corectl dns dnssec disable jouwsite.nl

Uitzetten gaat in omgekeerde volgorde: haal éérst het DS-record bij je registrar weg, wacht tot dat overal verlopen is, en zet dán het ondertekenen uit. Een DS dat naar sleutels wijst die niet meer bestaan, maakt je hele domein onbereikbaar — dat is de klassieke manier om jezelf van het internet te halen.

Secundaire nameservers

Eén nameserver is één storing. Een tweede server die dezelfde zone serveert houdt je domein in de lucht als de eerste onderhoud heeft. In CoreCP registreer je die op de primaire server, waarna de zones vanzelf worden overgedragen en elke wijziging met een NOTIFY wordt aangekondigd.

# op de primaire server
corectl dns secondary add ns2.jouwsite.nl --ip 203.0.113.20,2001:db8::20
corectl dns secondary list
corectl dns secondary join-command          # de regel die op de secundaire draait
corectl dns notify jouwsite.nl              # nu overdragen in plaats van straks

Registreer daarna beide namen bij je registrar. Voordat een zone gepubliceerd wordt, vraagt de primaire aan elke geregistreerde secundaire of die het domein al kent — dat vangt de fout af waarbij de tweede nameserver netjes in DNS staat maar niets serveert.

Hoe snel staat een wijziging op allebei? Binnen seconden. De primaire kondigt elke wijziging aan met een NOTIFY en de secundaire haalt de zone dan meteen op. Zie je een wijziging wél op de eerste en minutenlang niet op de tweede nameserver, dan is de aankondiging onderweg geweigerd: een secundaire accepteert alleen een NOTIFY van het adres waarop hij zijn primaire kent. Vraag het de secundaire zelf — hij schrijft de weigering op met het adres dat hij zag — en leg dat naast het adres waarmee je de primaire hebt geregistreerd. Zonder die aankondiging wacht de tweede nameserver op zijn eigen ronde langs de primaire, en dat is standaard drie uur.

Als er iets niet klopt

Controleren doe je altijd bij de bron:

dig +short A     www.jouwsite.nl
dig +short MX    jouwsite.nl
dig +short NS    jouwsite.nl @1.1.1.1
dig +short TXT   _dmarc.jouwsite.nl

Een subdomein heeft geen eigen DNS-zone

Heb je een website op bijvoorbeeld staging.test300.nl, dan zoek je de DNS-instellingen daarvan tevergeefs onder dat subdomein: die records horen in de zone van test300.nl. Dat is met opzet. Twee zones voor één domein is een delegatie, en een delegatie die niemand heeft gevraagd is een storing die op een TTL staat te wachten.

Het paneel brengt je er nu vanzelf heen. Open je de DNS-pagina van zo'n subdomein, dan opent de zone van het hoofddomein, met bovenaan de lijst een knopje Records voor staging.test300.nl in test300.nl. Zolang dat aanstaat zie je alléén de records die bij dat subdomein horen — zijn eigen adres, zijn www, zijn mailserver, zijn DMARC- en MTA-STS-regels en zijn DKIM-sleutel. Klik het knopje weg en je ziet de hele zone weer.

Voeg je een record toe terwijl dat filter aanstaat, dan begint het naamveld al met het subdomein — "hier een A-record toevoegen" betekent dus wat het filter zegt.

Vanaf de server is het één regel, en je kunt de hele set van een subdomein in één keer opvragen:

corectl dns record add test300.nl staging A 185.117.226.123
corectl dns record list test300.nl --under staging.test300.nl

Tot de eindcontrole van ronde 2 stond hier een technische foutmelding (no such endpoint). Die kwam niet door het subdomein maar doordat de pagina haar vraag stelde vóórdat ze wist welk domein je bekeek. Daarna bleef er nog een tweede staan — powerdns does not have this zone, de server die meldde dat een zone ontbrak die er nooit had moeten zijn. Die is er nu ook uit: de server zegt in welke zone de records dan wél staan, en de pagina brengt je erheen.

Een extra naam krijgt wél een eigen zone

Anders dan een subdomein is een extra naam een eigen hoofddomein, en die krijgt dus wel een eigen DNS-zone op deze server — met dezelfde records als elke andere website: het domein zelf, www, en de mailrecords als de naam de post van je hoofddomein meeneemt.

corectl domain alias add mijnbedrijf.nl mijnbedrijf.be
dig +short @<server> mijnbedrijf.be SOA

Die zone wordt daarna met rust gelaten. Er is bewust geen automatische synchronisatie vanuit de zone van je hoofddomein: die zou elke aanpassing die je in de zone van de extra naam maakt weer overschrijven, en "mijn TXT-record was vanochtend weg" is een vervelender probleem dan "ik moet het twee keer invoeren".

Staat de DNS van die naam ergens anders en wil je dat zo houden, gebruik dan --no-dns (of laat het vinkje DNS-zone aanmaken in het paneel uit).

De waarde-kolom is weer een kolom

In de recordtabel werd de kolom Waarde een tijdlang tot één teken breed geknepen, zodat een lange TXT-regel verticaal stond en de koppen WAARDE en TTL over elkaar heen vielen. De oorzaak zat in de tabel zelf: twee kolommen vroegen allebei de restbreedte op. Er rekt er nu precies één mee, elke andere kolom staat op één regel met een afkapping, en de volledige waarde lees je door op de rij te klikken.

# de meting die dat bewaakt
node corecp-panel/web/scripts/check-tables.mjs --url=http://127.0.0.1:5199 --route=/accounts/acc-1/dns
#   1 table(s) measured, 0 finding(s)

"Nog geen website" — en wat je dan doet

DNS-records horen bij een website: de zone waarin ze staan is de zone van een domeinnaam, dus zonder domein is er geen zone om te beheren. Heeft dit account nog geen website, dan legt het DNS-scherm dat uit — vroeger stond hier een rode foutmelding, want de pagina vroeg een zone zonder naam op.

1. Ga naar Accounts → jouw account → DNS.
2. Klik Website toevoegen en voeg de website toe.
3. Kom terug op DNS. De zone is aangemaakt met de standaardrecords erin, en de domeinkiezer boven de pagina wijst hem aan.

Mag je zelf geen website toevoegen, dan staat er dezelfde uitleg met een link Websites bekijken.

Wijst je domein hierheen? De DNS-voorcontrole

Een website die hier klaarstaat terwijl de naam nog ergens anders heen wijst, is de bekendste reden voor "mijn site doet het niet". Het paneel stelt die vraag daarom zelf, op twee plekken: in het formulier Website toevoegen, zodra je een naam hebt getypt, en op het overzicht van het account, als adviesregel.

De vraag heeft twee helften: wijst de naam naar dit platform, en zo niet, welke nameservers horen hier. Het antwoord is een van vier:

Het is een mededeling, geen slot. Je kunt een website altijd toevoegen, ook als de controle oranje is — dat is precies wat je doet als je een domein verhuist: eerst de website hier neerzetten, dan de nameservers omzetten. De knop Website toevoegen blijft gewoon werken.

Onder het oordeel staan de bevindingen zelf, in hetzelfde rijtje als bij het wijzigen van een record: een korte kop in jouw taal en daaronder de zin van de server. Die zin noemt de nameservers waaraan het domein nu gedelegeerd is.

De controle vraagt het na bij de bron — de nameservers van de zone erboven (.nl, .com), en daarna de nameservers die die aanwijzen — en niet bij een tussenliggende resolver. Een resolver geeft wat hij heeft onthouden, en net na het omzetten van een delegatie is dat het oude antwoord.

Vanaf de terminal

# corectl dns preflight example.net
elsewhere  example.net
  belongs    ns1.corecp.dev, ns2.corecp.dev
  delegated  betty.ns.cloudflare.com, hugh.ns.cloudflare.com
  answers    104.20.21.8, 172.66.175.59
  warning   example.net is delegated to betty.ns.cloudflare.com, hugh.ns.cloudflare.com, not to this platform, …

Meer namen tegelijk kan (corectl dns preflight a.nl b.nl), en met --account <naam> rekent de controle voor een naam die er nog niet staat met de nameservers van dat account.

Zie ook

• Zorgen dat je e-mail aankomt — de vier mailrecords, uitgelegd.
• SSL en certificaten — wildcard-certificaten hebben je DNS-zone nodig.
• Een testomgeving maken — waarom een staging-subdomein in de parentzone staat.

Eigen nameservers

Verkoop je hosting onder je eigen naam, dan kunnen je klanten ns1.jouwmerk.nl te zien krijgen in plaats van onze nameservers — inclusief de controle of de registry weet waar die naam staat. Dat staat in Eigen nameservers.

Een zone bij Cloudflare in plaats van bij ons

Niet elke zone hoeft door onze eigen nameservers bediend te worden. Staat een domein bij Cloudflare, dan kan het paneel die zone daar beheren — mits de server een API-token van jou heeft.

Zo'n token bewaar je per server, en sinds augustus 2026 kan dat vanuit het paneel: Instellingen → Koppelingen → Cloudflare DNS. Kies de server, klik Token opslaan, geef het token een naam en plak hem. Je ziet daarna alleen de naam, de aanbieder en het Cloudflare-account terug — het token zelf komt nergens meer in beeld, en er is ook geen knop of adres waarmee je het zou kunnen teruglezen.

Klopt het token niet, of is het verlopen, dan zegt het formulier dat meteen en wordt er niets opgeslagen: het wordt eerst bij Cloudflare gecontroleerd. Het token heeft Zone:Read + Zone:Edit en DNS:Read + DNS:Edit nodig op de zones die het beheert.

Welke zone welk token gebruikt, kies je daarna hier op de DNS-pagina van het domein. Meer over de andere koppelingen staat in Koppelingen.

Vanaf de terminal geef je het token via de invoer mee, nooit als optie — een optie is op een gedeelde server zichtbaar voor iedereen zolang het commando loopt:

printf '%s' "$TOKEN" | corectl dns credential set default --token-stdin

Geef je --token en --token-stdin tegelijk, of een lege invoer, dan weigert corectl in plaats van een leeg token op te slaan.

Waarom webmail. er soms niet staat

De naam webmail.jouwdomein.nl verschijnt alleen in je zone als de server jouw webmail ook echt aanbiedt. Staat webmail uit, of kan de server hem tijdelijk niet serveren, dan wordt het record niet gepubliceerd — een naam die naar een lege pagina wijst is vervelender dan een naam die er niet is, en hij zou ook op je certificaat terechtkomen.

Zet je webmail aan, dan komt het record er vanzelf bij; vraag daarna één keer een nieuw certificaat aan, zodat de naam ook in het slotje zit. Je ziet het record staan op de DNS-pagina van het domein, tussen mail. en de rest.

Wat er uit de bovenliggende zone verdwijnt als je een subdomein verwijdert

Een subdomein-website zet zijn records in de zone van het hoofddomein. Verwijder je het subdomein, dan gaan ál zijn records mee — sinds augustus 2026 ook de mailbeveiligingsrecords (_mta-sts, mta-sts, _smtp._tls, mail., webmail.). Er blijft dus geen belofte aan verzendende mailservers achter die nergens meer heen wijst. Records die je zélf met de hand hebt toegevoegd blijven staan.

Als de beheerder de zoneopslag van de server verhuist

De records die jij hier beheert, staan op de naamserver zelf. Op servers die de beheerder heeft omgezet, staan ze in een opslag die van de server is in plaats van in de database-server waar ook websitedatabases staan.

Aan jouw kant verandert er niets: dezelfde records, dezelfde knoppen, dezelfde wachttijd voordat de wereld een wijziging ziet. Wat je wél kunt merken:

• Tijdens de omzetting wordt de naamserver één keer herstart. Een vraag die op dat moment binnenkomt, wordt door de vrager vanzelf herhaald — resolvers doen dat standaard — en de rest van het internet werkt uit zijn cache.
• Servers worden één voor één omgezet. Een tweede naamserver die nog niet is omgezet blijft gewoon antwoorden; jouw domein staat dus nooit stil doordat er één machine bezig is.

Wil je zelf zien of een wijziging is doorgekomen, vraag het dan aan allebei je naamservers en vergelijk het serienummer:

dig +short @ns1.voorbeeld.nl voorbeeld.nl SOA
dig +short @ns2.voorbeeld.nl voorbeeld.nl SOA

Staan er twee verschillende serienummers, wacht dan een paar minuten en vraag het opnieuw; de tweede naamserver haalt de nieuwe versie zelf op.

Wat een wijziging betekent, vóórdat je hem opslaat

Onder het invulformulier stond al de regel die straks in de zone komt te staan. Daaronder staat sinds september 2026 ook wat die wijziging betekent — in volgorde van hoe zwaar het weegt:

• De server houdt dit tegen. Er gaat iets kapot dat nu werkt. Denk aan: een DMARC-regel op een naam waar geen enkele ontvanger hem leest, een tweede SPF-regel (twee tellen als geen enkele), een MX die naar een alias wijst, of een CAA-record dat de certificaatuitgever van deze server buitensluit — dan mislukt je certificaatvernieuwing weken later, als je er niet meer aan denkt.
• Let op. Het gaat door, maar het neemt iets mee. "Deze website verhuist naar een ander adres." "Post volgt dit record."
• Advies. Het kan zo, maar er is een gangbaardere manier.
• Ter info. Een feit over wat er gebeurt.

Er staat nooit bij wanneer de wereld je wijziging ziet — dat kán een naamserver niet weten. Wat er wél staat is de TTL die tot nu toe werd meegegeven: wie het oude antwoord al had opgehaald, houdt dat zo lang. Alles wat een ander paneel je belooft over "24 tot 48 uur" is een gok.

Verwijderen vraagt nu eerst wat het kost

Op Verwijderen klikken deed het meteen, met een ongedaan maken-knop in de melding. Die knop is er nog, maar hij was een half antwoord: een record terugzetten herstelt de zone en niet wat er intussen misging. Post die stuiterde toen de MX weg was, komt niet terug met het record.

Daarom vraagt het paneel het nu eerst aan de server, en laat het zien:

1. welke regels uit de zone verdwijnen (doorgestreept) en wat er blijft staan;
2. wat dat kost, in dezelfde vier soorten als hierboven.

Weegt het zwaar — de laatste MX van een domein waarvan de mailboxen hier staan, de DKIM-sleutel waarmee je post nog ondertekend wordt — dan houdt de server het tegen en vraagt het venster om een reden. Die reden komt in het logboek te staan, naast de wijziging. Zo blijft de uitzondering een keuze die je later kunt terugvinden, in plaats van iets dat iemand met een terminal heeft gedaan.

Cloudflare kan minder, en dat staat er nu bij

Ligt je zone bij Cloudflare, dan zijn er twee dingen die daar anders werken:

• ALIAS bestaat er niet. Cloudflare lost een CNAME op het domein zelf op (CNAME-flattening); zet daar dus een CNAME neer. Het type wordt niet aangeboden, met die reden erbij.
• SPF als apart recordtype is nooit gemeten. Het paneel zegt dat eerlijk in plaats van te doen alsof het het zeker weet: het type staat er nog, met de opmerking dat SPF sinds 2014 als TXT-record hoort te worden gepubliceerd — dat is wat verzenders opzoeken.

Zet je een naam achter de proxy, dan zie je twee opmerkingen: je eigen adres is dan niet meer zichtbaar (alles wat je server op naam moet bereiken — een MX-doel, een SSH-host — heeft een naam nodig die níet achter de proxy staat), en de TTL die je invult wordt niet gebruikt: Cloudflare bedient een geproxyde naam met vaste 300 seconden.