Waarom domain health er toe doet#

Wanneer de meeste teams zeggen "het domein is healthy", bedoelen ze meestal "de website gaf de laatste keer dat iemand keek een 200 terug". Dat is één signaal van minstens vijf — en de andere vier veroorzaken meer outages, meer omzetverlies en meer schade aan klantvertrouwen dan dat ene waar iedereen op let.

Een domein is healthy wanneer het bereikbaar, beveiligd, geauthenticeerd, reputabel en observable is. SEO hangt ervan af (Google bestraft mixed content, verlopen certs en trage TTFB). Deliverability hangt ervan af (Gmail en Yahoo weigeren nu mail van misaligned domeinen voor bulkverzenders). Beveiliging hangt ervan af (een dangling CNAME is een subdomain takeover die op gebeuren staat). En klantvertrouwen hangt ervan af (een browserwaarschuwing op het moment dat een creditcard wordt ingevoerd is een conversie gekild en een refund getriggerd).

Deze gids is een audit van 5 minuten. Aan het eind weet je precies welke van de vijf pijlers nu stilletjes faalt op jouw domein, welk command je moet draaien om het te bevestigen, en welke gratis tool van Nova Uptime je gebruikt om het op te lossen. Geen fluff, geen marketingtekst — gewoon de audit die een senior SRE zou doorlopen als je hem een domein gaf en vroeg: "is dit ding in goede vorm?"

De 5 pijlers van domain health#

Voor we pijler voor pijler doorlopen, hier is het mentale model. Elk healthy domein passeert alle vijf checks. De meeste productiedomeinen falen op minstens één — en het team weet het zelden tot de failure een klantticket wordt.

Pijler 1: DNS-configuratie — A, AAAA, MX, CNAME, TXT, DNSSEC. Zijn alle records aanwezig, correct en wijzen ze waar ze zouden moeten?
Pijler 2: SSL/TLS-certificaten — geldigheidsvenster, ketenintegriteit, SAN-dekking, cipher-sterkte, HSTS. Vertrouwt elke browser het cert vandaag én over 60 dagen?
Pijler 3: E-mailauthenticatie — SPF, DKIM, DMARC, alignment. Kunnen aanvallers je domein spoofen? Belanden legitieme mails in inboxen of in spam?
Pijler 4: Reputatie — DNSBL-listings op Spamhaus, Barracuda, SORBS, SpamCop. Staat je verzendend IP of domein op een blacklist die stilletjes je deliverability afbrandt?
Pijler 5: Uptime en performance — HTTP-status, responstijd-percentielen, multi-region-bereikbaarheid, domeinverloop, registratieleeftijd. Is de site daadwerkelijk up, snel en niet op het punt om volgende dinsdag te verlopen?

Elke pijler heeft een 30-seconden-check die je vanuit een terminal kunt draaien, een diepere inspectie die je met een gratis Nova Uptime-tool kunt draaien, en een continue monitor die je kunt opzetten om gewaarschuwd te worden voor de volgende failure.

Pijler 1: DNS-configuratie#

DNS is het fundament. Klopt DNS niet, dan doen de andere vier pijlers er niet toe — het verzoek bereikt je server nooit.

De records die ertoe doen#

A-records mappen een hostname naar een IPv4-adres. Elk domein heeft er minstens één nodig voor de apex en één voor www.
AAAA-records mappen een hostname naar een IPv6-adres. De meeste teams slaan deze over. Ze zouden dat niet moeten doen. IPv6-verkeer is nu routinematig 30–40% van het mobiele verkeer in grote markten, en een ontbrekend AAAA-record forceert fallback naar IPv4 — wat latency toevoegt en, in slecht geconfigureerde carrier-netwerken, af en toe failures.
MX-records definiëren mailrouting. Meerdere MX-records gebruiken priority-waarden (lager = preferred). De allereerste MX-bug die we zien is een MX-record met priority 0 dat naar het apex-domein zelf wijst terwijl de apex geen SMTP-listener heeft — mail bounct stilletjes.
CNAME-records zijn aliassen. Het gevaar zijn dangling CNAMEs: een CNAME die wijst naar een dienst die je niet meer gebruikt (een afgedankte S3-bucket, een oude Heroku-app, een uitgefaseerde Zendesk-instance). Een aanvaller die die resource bij de upstream-provider claimt, neemt je subdomein over.
TXT-records dragen verificaties, SPF, DMARC, domain-ownership-tokens. Ze moeten periodiek worden geaudit — oude verificaties van diensten die je niet meer gebruikt vervuilen de zone en verhogen het SPF-lookup-aantal.
DNSSEC voegt een cryptografische vertrouwensketen toe aan DNS-responses. Het voorkomt cache poisoning en DNS-hijacking. Het is niet strikt vereist, maar voor elk domein dat geld, credentials of healthcare-data afhandelt is het aanbevolen.

Snelle checks#

dig +short A jouwdomein.com
dig +short AAAA jouwdomein.com
dig +short MX jouwdomein.com
dig +short TXT jouwdomein.com
dig DNSKEY jouwdomein.com +short

Voor MX-specifieke validatie, run Nova Uptime's e-mail-health-checker — die bevestigt MX-records, prioriteiten en resolveert elke MX-hostname naar een IP.

Pijler 2: SSL/TLS-certificaten#

Een werkend cert is niet genoeg. Er zijn zes onafhankelijke dingen die fout kunnen zijn aan een SSL-certificaat, en de meeste monitoring-tools checken er precies één van — de verloopdatum.

Wat te verifiëren#

notBefore en notAfter definiëren het geldigheidsvenster. Met de 90-dagen-cyclus van Let's Encrypt en de industriebrede push naar 47-dagen-certs in 2028, gebeurt verloop snel en stilzwijgend. Je moet het 30 dagen vooruit weten.
Integriteit van de issuer-keten. Het cert dat je server presenteert moet de intermediate-certificaten bevatten die hem terugkoppelen aan een vertrouwde root. Het cert valideert prima in Chrome (dat intermediates cachet) maar breekt in oudere Safari, op iOS of in headless tools die ontbrekende intermediates niet ophalen. Dit is de meest voorkomende "maar het werkt in mijn browser"-SSL-bug.
SAN- (Subject Alternative Name) dekking. Het cert moet elke hostname vermelden die het bedient: apex, www en eventuele subdomeinen die hetzelfde cert gebruiken. Een cert dat geldig is voor www.jouwdomein.com maar niet voor de kale apex is een veelvoorkomende misconfiguratie.
Cipher suites en protocolversies. TLS 1.0 en 1.1 zijn deprecated. TLS 1.2 is de ondergrens; TLS 1.3 is het doel. Zwakke ciphers (RC4, 3DES, alles met CBC-modus in oudere configuraties) zouden uitgeschakeld moeten zijn.
HSTS-header. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload vertelt browsers HTTP voor altijd te weigeren. Zonder HSTS kan een man-in-the-middle-aanvaller bij het eerste contact downgraden naar HTTP.
OCSP-stapling. De server hangt een ondertekend bewijs van cert-geldigheid aan de TLS-handshake, waardoor een round-trip naar de OCSP-responder van de CA wordt geëlimineerd. Het is sneller en meer privé. De meeste moderne webservers ondersteunen het; weinige hebben het ingeschakeld.

Snelle check#

echo | openssl s_client -servername jouwdomein.com -connect jouwdomein.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

Voor continue monitoring met 30-dagen-verloop-alerts en chain-validatie, gebruik Nova Uptime's SSL expiry checker.

Pijler 3: E-mailauthenticatie#

Dit is de pijler waar 2026 de regels veranderde. De bulk-sender-handhaving van Gmail en Yahoo betekent dat een ontbrekend of misaligned DMARC-record je nu inbox-plaatsing kost, niet alleen reputatie.

SPF — wie mag voor jouw domein versturen#

SPF is een DNS TXT-record dat de IP's en domeinen vermeldt die geautoriseerd zijn om als jou e-mail te versturen. De twee valkuilen:

De limiet van 10 DNS-lookups. Elke include: in je SPF-record telt mee. SendGrid alleen al is 3 lookups; voeg Google Workspace (3), Mailchimp (1) en een transactionele provider (3) toe en je zit boven de limiet. Ontvangende servers geven een permerror terug en je mail faalt.
De +all- (of geen) qualifier. De qualifier aan het eind (-all, ~all, ?all, +all) vertelt ontvangers wat te doen met mail van niet-vermelde bronnen. +all betekent "iedereen mag als mij versturen" — gebruik dat nooit.

Valideer met Nova Uptime's SPF-checker.

DKIM — cryptografische handtekening#

DKIM ondertekent elk uitgaand bericht met een private key. De ontvanger haalt de public key op uit selector._domainkey.jouwdomein.com en verifieert de handtekening. De twee valkuilen:

Selector-verwarring. Er is geen wildcard voor DKIM. Je moet de selector kennen die je verzendservice gebruikt (s1, google, mandrill, selector1, etc.). De key staat op {selector}._domainkey.jouwdomein.com.
Sleutelrotatie. DKIM-sleutels moeten jaarlijks geroteerd worden. De meeste teams zetten ze één keer op en vergeten ze vijf jaar lang.

Check via Nova Uptime's DKIM-checker, die automatisch 50 veelvoorkomende selectors scant.

DMARC — de policy-laag#

DMARC vertelt ontvangende servers wat te doen wanneer SPF en DKIM falen. Drie policies:

p=none — alleen monitoren, geen actie ondernemen. Gebruik dit voor de eerste 2–4 weken terwijl je rapporten verzamelt.
p=quarantine — stuur falende mail naar spam.
p=reject — weiger falende mail direct. Dit is het doel.

De meeste domeinen blijven voor altijd op p=none hangen omdat niemand de aggregaat-(rua) rapporten leest. Wees niet de meeste domeinen. Loop door onze DMARC-policy-setupgids en valideer met Nova Uptime's DMARC-checker.

Alignment — het deel dat iedereen mist#

DMARC vereist dat het SPF- of DKIM-domein uitlijnt met het From-header-domein. Een bericht kan SPF passeren (voor mailgun.org) en DKIM passeren (ondertekend door mandrillapp.com), maar als de From-header zegt jij@jouwdomein.com, faalt DMARC omdat niets uitlijnt. Los het op door custom return-path-domeinen en DKIM-signing-domeinen te configureren voor elke verzendservice.

Voor alle vier de checks tegelijk, gebruik Nova Uptime's e-mail-health-checker — die scoort SPF, DKIM, DMARC en alignment samen.

Pijler 4: Reputatie (blacklists)#

Zelfs met perfecte authenticatie belandt een slechte reputatie je in spam. DNSBL's (DNS-based blocklists) zijn de publieke scoreboards.

Wat DNSBL's bijhouden#

Sommige blocklists houden IP's bij (het adres van je verzendende mailserver). Andere houden domeinen bij (de URI in de berichtinhoud). Elke blocklist heeft zijn eigen listingcriteria, maar de gemene triggers zijn: versturen naar spamtraps, hoge klachtenpercentages, plotselinge volumepieken en op hetzelfde IP-blok zitten als bekende spammers.

De lijsten die ertoe doen#

Spamhaus SBL/XBL/PBL/DBL — de gouden standaard. Grote mailboxproviders raadplegen Spamhaus direct.
Barracuda Reputation Block List — zwaar gebruikt door enterprise-filters.
SORBS — aggregeert verschillende feeds; kan agressief zijn.
SpamCop — gedreven door gebruikersklachten; relatief korte listingperiodes maar hoog volume.

Waarom je gelist zou kunnen zijn#

De vier meest voorkomende redenen: (1) een gecompromitteerd account op je platform verstuurde spam, (2) een klant op een shared-IP-setup deed het, (3) je verstuurde een campagne naar een oude, onverifiëerde lijst, (4) je formulieren staan ongeauthenticeerde signups toe en bots gebruiken je platform om te versturen.

Hoe te checken#

Gebruik Nova Uptime's blacklist-checker — die queryt 60+ DNSBL's parallel en toont precies welke lijsten je IP's en domeinen hebben gemarkeerd, met delisting-links voor elk.

Sta je gelist, fix dan eerst het onderliggende probleem (sluit het gecompromitteerde account, schoon de lijst op, fix het formulier), en dien dan delisting-verzoeken in. Een week later met dezelfde root cause opnieuw gelist worden levert je een langere ban op.

Pijler 5: Uptime en performance#

Dit is de pijler waar iedereen op let — en zelfs hier letten de meeste teams maar op één metric.

Wat te meten#

HTTP-statuscode. 200 is healthy. 4xx is jouw probleem. 5xx is het probleem van je server. 3xx-redirects zouden binnen 3 hops naar 200 moeten resolven.
Responstijd-percentielen. Mediaan (p50) is het verhaal; p95 en p99 zijn de waarheid. Een site met een 200ms p50 en een 9.000ms p99 heeft een serieus probleem dat 1 op de 100 verzoeken raakt — meestal een trage database-query of cold cache.
Multi-region-bereikbaarheid. Single-region-monitoring vangt jouw outages. Het mist de outages van je klanten — de BGP-route-flap in Azië, het regionale Cloudflare-incident, het ISP-peering-conflict dat 10% van je gebruikers raakt.
Failure-screenshots. Wanneer de site plat gaat, leg het scherm vast dat de gebruiker ziet. "Site onbereikbaar" ziet er identiek uit vanaf een monitor of het issue nu een 500 is, een Cloudflare-challenge-pagina of een payment-provider-iframe dat faalt.
Domeinverloop. Domeinen verlopen. Auto-renew faalt (verlopen creditcard, registrar-account opgeschort, factuurmail die naar de mailbox van een ex-medewerker gaat). Houd de verloopdatum van de registrar bij — en de registratieleeftijd, die autoriteit signaleert voor SEO.

Voor continue monitoring met 59-seconden-intervallen, multi-region-checks, screenshots en WhatsApp/e-mail/webhook-alerts, meld je aan op Nova Uptime's pricing-pagina. Voor eenmalige checks van registratieleeftijd en verloop, gebruik domain expiry checker en domain age checker.

De 5-minuten-health-check-checklist#

Run deze in volgorde. Elke stap heeft een duidelijke pass/fail.

DNS — dig +short A jouwdomein.com && dig +short AAAA jouwdomein.com && dig +short MX jouwdomein.com. Alle drie zouden waarden moeten teruggeven. Is MX leeg, dan is mail kapot.
SSL — echo | openssl s_client -servername jouwdomein.com -connect jouwdomein.com:443 2>/dev/null | openssl x509 -noout -dates. notAfter moet meer dan 30 dagen vooruit zijn.
SPF — bezoek /tools/spf-checker, voer je domein in. Score moet 90+ zijn.
DKIM — bezoek /tools/dkim-checker, voer je domein in. Status moet "Configured" zijn.
DMARC — bezoek /tools/dmarc-checker. Policy moet quarantine of reject zijn, niet none.
E-mail-health (gecombineerd) — /tools/email-health geeft een A–F-cijfer over al het bovenstaande.
Blacklists — /tools/blacklist-checker. Nul listings is het doel.
SSL deep check — /tools/ssl-expiry voor chain-validatie en 30-dagen-alerts.
Domeinverloop — /tools/domain-expiry. Moet meer dan 60 dagen vooruit zijn; langer is beter voor SEO-autoriteit.
Uptime — curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://jouwdomein.com. Status 200, tijd onder 1,5s.

Faalt een van deze, dan heb je net je topprioriteit geïdentificeerd.

Echte stories#

Een paar voorbeelden uit de afgelopen zes maanden van teams helpen hun domeinen te auditen:

De unaligned DKIM die zes maanden verborgen bleef. Een B2B-SaaS-bedrijf verstuurde transactionele e-mails via een custom subdomein (mail.hunsite.com) maar de d=-tag van DKIM was het domein van de provider, niet die van hen. Gmail's grace period betekende dat de mail bij lage volumes nog steeds in de inbox belandde. Toen ze hun eerste grote campagne — 50.000 e-mails — verstuurden, waren de open rates 4%. Bounce-rapporten lieten zien dat Gmail de berichten al maandenlang stilletjes had gedowngrade. De fix was een DNS-wijziging van 10 minuten. De les was dat "deliverability ziet er prima uit" geen meting is.

Het intermediate cert dat alleen Safari opmerkte. Een e-commerce-site verlengde automatisch hun SSL-cert via hun hostingprovider. Het nieuwe cert deployde correct, maar het intermediate-certificaat ontbrak in de bundle. Chrome en Firefox cachten de intermediate van eerdere bezoeken en bleven valideren. Safari (dat intermediates niet agressief cachet) toonde een full-page beveiligingswaarschuwing. Ongeveer 18% van hun checkout-verkeer was iOS Safari. Ze verloren twee dagen omzet voordat een klantondersteuningsticket de punten met elkaar verbond.

De dangling CNAME die een takeover werd. Een oude marketing-landingpage op promo.hundomein.com was een CNAME naar een Heroku-app die drie jaar eerder was verwijderd. Een aanvaller registreerde dezelfde Heroku-app-naam, en gedurende 12 uur serveerde dat subdomein willekeurige HTML — inclusief een phishing-formulier dat de loginpagina van het bedrijf nabootste. De fix was 30 seconden DNS-cleanup. De ontdekking was nul — het team kwam er pas achter toen een klant de phishing-poging rapporteerde. Een maandelijkse subdomain-audit had het opgevangen.

Conclusie#

Domain health is vijf pijlers, niet één. Run de 5-minuten-checklist hierboven. Fix de failures. Zet daarna een continue monitor op de dingen die over tijd drift — certs verlopen, blacklists verschuiven, registraties lopen af, en SPF-records groeien tot ze de lookup-limiet breken. Alle vijf pijlers, gratis, in één dashboard op Nova Uptime.

Domain Health Check: een volledige gratis audit (DNS + SSL + e-mail + uptime)