E-mailverificatie instellen voor een nieuw geregistreerd domein

door

Laatst bijgewerkt:
10 leestijd: 10 minuten
E-mailverificatie instellen voor een nieuw geregistreerd domein

Belangrijkste Conclusies

  • Een nieuw geregistreerd domein heeft geen SPF, DKIM of DMARC – waardoor het vanaf dag één een doelwit voor spoofing is
  • Zorg ervoor dat de records in de juiste volgorde worden ingesteld: eerst SPF, dan DKIM en vervolgens DMARC
  • Stel DMARC altijd eerst in op p=none om de situatie te monitoren voordat je de regels gaat handhaven
  • Controleer alle drie de records na de DNS-propagatie met behulp van de gratis controletools van PowerDMARC
  • Bekijk de geaggregeerde DMARC-rapporten voordat u overgaat tot een strengere handhaving van het beleid

Zodra een domein is geregistreerd, wordt het een doelwit voor spoofing – nog voordat er ook maar één e-mail is verzonden. Zonder SPF, DKIM of DMARC kan iedereen e-mails versturen die lijken te komen van uw domein, en hebben ontvangende servers geen technische middelen om dit te detecteren. In deze handleiding wordt stap voor stap uitgelegd hoe u e-mailverificatie in de juiste volgorde instelt, met concrete voorbeelden van DNS-records, verificatiestappen en wat u in de gaten moet houden zodra alles in gebruik is.

Waarom nieuwe domeinen bijzonder kwetsbaar zijn

Een nieuw domein mist niet alleen authenticatierecords – het mist alles: geen verzendgeschiedenis, geen reputatie, geen eerdere configuratie om op voort te bouwen. Die combinatie brengt specifieke risico’s met zich mee en vereist een andere aanpak dan het configureren van authenticatie op een bestaand domein.

Waarom-nieuwe-domeinen-bijzonder-kwetsbaar-zijn--

1. Nog geen afzenderreputatie

E-mailproviders gebruiken de verzendgeschiedenis om te bepalen hoe ze inkomende e-mail behandelen. Een domein dat nog nooit iets heeft verzonden, heeft geen reputatie, wat betekent dat ontvangende servers op basis van reputatie alleen geen onderscheid kunnen maken tussen een legitieme nieuwe afzender en een vervalste afzender.

E-mailverificatie vult die leemte op. SPF, DKIM en DMARC geven e-mailproviders een technisch signaal dat u de beheerder van het domein bent en dat u het zo hebt geconfigureerd dat legitieme afzenders worden geautoriseerd – zelfs voordat er enige reputatie is opgebouwd. Correct geverifieerde e-mail van een nieuw domein kan in het begin nog steeds in de spamfolder terechtkomen, maar zonder verificatie ontneemt u de providers het laatste geloofwaardigheidssignaal dat zij in uw voordeel kunnen gebruiken.

2. Nieuwe domeinnamen zijn een belangrijk doelwit voor spoofing

Aanvallers richten zich specifiek op nieuwe en recent geregistreerde domeinen, omdat daar vrijwel nooit authenticatieregistraties voor zijn ingesteld. Zonder SPF, DKIM en DMARC kan elke server beweren dat hij namens uw domein e-mails verstuurt, en daar ook in slagen.

Deze kwetsbaarheid heeft betrekking op verschillende soorten bedreigingen. Bij aanvallen waarbij zich iemand voordoet als uw merk, wordt uw domein gebruikt om contact op te nemen met klanten of partners voordat u een relatie met hen hebt opgebouwd. Phishingcampagnes maken misbruik van het schone blazoen van een nieuw domein – geen negatieve reputatie betekent minder activering van spamfilters. Business Email Compromise (BEC) kan zich richten op uw leveranciers of interne team door gebruik te maken van een vervalste versie van uw e-mailadres. Elk bedrijf dat projectupdates, facturen of e-mails naar klanten verstuurt, zoals een bedrijf voor maatwerksoftwareontwikkeling in Austin, loopt risico totdat er authenticatie is ingesteld.

3. Geen verouderde gegevens die moeten worden omzeild

Dit is waar nieuwe domeinen een duidelijk voordeel hebben ten opzichte van bestaande domeinen. Oudere domeinen stapelen in de loop van de tijd DNS-problemen op: een dubbel SPF-record van een platform dat al jaren geleden is vervangen, een DKIM-selector die gekoppeld is aan een e-mailprovider die niet langer namens hen verstuurt, of een DMARC-beleid dat nog steeds op p=none staat en nooit is herzien.

Helemaal opnieuw beginnen betekent dat je alles vanaf het begin correct instelt. Geen controle van oude gegevens, geen risico dat een bestaande e-mailstroom wordt verstoord, geen overgeërfde verkeerde configuraties die je moet ontrafelen. De installatie is overzichtelijker, sneller en gemakkelijker te controleren.

4. Overwegingen bij een koude start

Authenticatie en domein-warm-up zijn verwante, maar afzonderlijke processen. Authenticatierecords laten ontvangende servers weten dat uw e-mail geautoriseerd is. Warm-up is het proces waarbij een positieve verzendgeschiedenis wordt opgebouwd door te beginnen met een laag volume en dit in de loop van de tijd geleidelijk te verhogen.

Authenticatie staat voorop – je kunt een domein dat de authenticatiecontroles niet doorstaat, niet opwarmen. Zodra SPF, DKIM en DMARC actief en geverifieerd zijn, begin je met beperkte verzendvolumes en laat je je DMARC-rapporten zich opstapelen voordat je het beleid aanscherpt of het uitgaande verkeer opschaal.

Hoe je e-mail verifiëren?

Wat je nodig hebt voordat je begint

  • Toegang tot het DNS-paneel van uw domein

SPF-, DKIM- en DMARC-records worden allemaal als TXT-records in het DNS gepubliceerd. Je DNS-paneel bevindt zich mogelijk bij je domeinregistrar (Namecheap, GoDaddy, Cloudflare, enz.) of bij je hostingprovider. Je hebt schrijftoegang nodig om nieuwe records toe te voegen – alleen-lezen toegang is niet voldoende.

  • Uw platform voor e-mailverzending

DKIM-sleutels worden gegenereerd door uw e-mailplatform – ze worden niet handmatig aangemaakt. Voordat u een DKIM-record kunt publiceren, moet u het DKIM-configuratieproces binnen uw platform doorlopen (Google Workspace, Microsoft 365, een aangepaste SMTP-dienst of iets dergelijks). Het platform genereert het sleutelpaar en geeft u de exacte naam en waarde van het record dat u in DNS moet publiceren. U kunt geen geldig DKIM-record aanmaken los van het verzendplatform.

Als er meer dan één platform e-mails verstuurt vanuit uw domein, breng deze dan nu allemaal in kaart. Elk platform moet in uw SPF-record worden opgenomen en heeft mogelijk een eigen DKIM-selector nodig.

  • Een e-mailadres voor DMARC-rapporten

DMARC-overzichtsrapporten worden verzonden naar het adres dat u opgeeft in de rua-tag van uw DMARC-record. Dit kan elke bewaakte inbox zijn: een speciaal adres zoals [email protected], een gedeelde team-inbox of een adres dat door een DMARC-rapportageplatform wordt verstrekt. Het adres moet alleen bestaan en actief worden gecontroleerd. Zonder een werkend rua-adres levert de bewakingsfase van uw DMARC-configuratie geen bruikbare informatie op.

Stap 1 – Stel je SPF-record in

SPF (Sender Policy Framework) geeft ontvangende mailservers door welke IP-adressen bevoegd zijn om e-mail namens uw domein te verzenden. Stel eerst SPF in – dit vormt de basis waarop DKIM en DMARC voortbouwen.

SPF werkt via één enkel DNS TXT-record waarin uw geautoriseerde afzenders worden vermeld. Wanneer een ontvangende server een bericht van uw domein ontvangt, vergelijkt deze het afzender-IP-adres met uw SPF-record. Een IP-adres dat in het record staat, wordt geaccepteerd; een IP-adres dat niet in het record staat, wordt geweigerd.

v=spf1 include:_spf.google.com ~all

v=spf1 → geeft aan dat dit een SPF-record is

omvat:… → geeft toestemming aan alle IP-adressen binnen de e-mailinfrastructuur van Google

~all → weigert alle afzenders die niet expliciet in de lijst staan

Hoe voeg je je SPF-record toe?

  1. Log in bij je DNS-provider
  2. Maak een nieuw TXT-record aan
  3. Stel het veld Host / Naam in op @ (dit staat voor je hoofddomein)
  4. Plak de SPF-waarde die je e-mailplatform verstrekt
  5. Het record opslaan
TYPE GASTGEVER WAARDE
TXT @ v=spf1 include:_spf.google.com ~all

Als u vanaf meer dan één platform e-mails verstuurt, voeg dan alle afzenders samen in één enkel SPF-record. Het publiceren van twee SPF-TXT-records op het hoofddomein leidt tot een fout bij de SPF-validatie: er wordt slechts één record geëvalueerd en het resultaat is onvoorspelbaar.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Veelgemaakte fouten met SPF bij nieuwe domeinen

  • Twee SPF-records – Per domein is slechts één SPF TXT-record geldig. Als u er twee publiceert, worden beide ongeldig. Voeg alle verzendbronnen samen in één record.
  • Als je -all te vroeg gebruikt, wordt e-mail van niet-vermelde afzenders onmiddellijk geweigerd (hard-fail). Gebruik eerst ~all (soft-fail) totdat je volledige lijst met afzenders is bevestigd.
  • Ontbrekend verzendplatform – Elk platform dat namens uw domein e-mails verstuurt en niet in het SPF-record is opgenomen, zal de authenticatie niet doorstaan. Zorg ervoor dat u alle afzenders hebt opgenomen voordat u het record opslaat.

Stap 2 – Maak je DKIM-record aan en publiceer het

DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan uitgaande e-mails. Ontvangende servers gebruiken een openbare sleutel in uw DNS om te controleren of het bericht afkomstig is van uw domein en tijdens het verzenden niet is gewijzigd.

DKIM-sleutels worden binnen uw e-mailplatform gegenereerd – u hoeft ze niet zelf in te voeren. Ga naar het gedeelte over DKIM, domeinverificatie of e-mailinstellingen van uw platform en volg de aangegeven stappen. Het platform genereert een sleutelpaar: een privésleutel (die wordt gebruikt om uitgaande e-mail te ondertekenen) en een openbare sleutel (die in DNS wordt gepubliceerd, zodat ontvangende servers de handtekeningen kunnen verifiëren).

Elk platform wijst een selector toe – een label in de recordnaam waarmee meerdere DKIM-sleutels op hetzelfde domein kunnen bestaan. Als u twee verzendplatforms gebruikt, krijgt elk platform zijn eigen selector en zijn eigen DNS-record. Voorbeeld van een recordnaam met de selector google:

google._domainkey.uwdomein.com

Hoe publiceer je je DKIM-record

  1. Open het gedeelte 'DKIM' in uw e-mailplatform
  2. Kopieer de naam van het TXT-record (bijv. google._domainkey)
  3. Kopieer de waarde van het TXT-record (de tekenreeks van de openbare sleutel)
  4. Open je DNS-paneel en maak een nieuw TXT-record aan
  5. Plak de naam en waarde precies zoals ze zijn opgegeven
  6. Sla op en ga vervolgens terug naar je platform om de verificatie te starten
TYPE GASTGEVER WAARDE
TXT google._domainkey v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9…

Sommige platforms kunnen het DKIM-record automatisch aanmaken als ze ook uw DNS beheren – raadpleeg de installatiehandleiding van uw platform voordat u het handmatig toevoegt.

Hoe controleer je of DKIM is ingeschakeld

PowerDMARC DKIM-controle
Plak je domein en selector om direct te controleren of je DKIM-record actief is, de juiste indeling heeft en de validatie doorstaat.

De DNS-verspreiding is doorgaans binnen enkele uren voltooid, maar kan tot 48 uur duren. Als de verificatie na die periode nog steeds mislukt, controleer dan of er extra spaties in de waarde staan, of de hostnaam onjuist is of of de sleutel is afgekapt.

Stap 3 – Maak je DMARC-record aan

DMARC (Domain-based Message Authentication, Reporting and Conformance) vormt de beleidslaag. Terwijl SPF en DKIM de authenticatiecontroles uitvoeren, geeft DMARC ontvangende servers aan wat ze moeten doen met berichten die deze controles niet doorstaan – en levert het geaggregeerde rapporten, zodat u precies kunt zien wie er e-mails verstuurt via uw domein.

Het juiste DMARC-beleid voor een nieuw domein

Begin altijd met p=none.

Een beleid waarbij alleen wordt gecontroleerd, houdt in dat mislukte berichten toch worden afgeleverd – er wordt niets tegengehouden. Dit is het juiste uitgangspunt voor een nieuw domein, omdat je nog niet hebt gecontroleerd of elke legitieme afzender correct is geauthenticeerd. Als je meteen overgaat op p=reject zonder eerst je rapporten te bekijken, kan dit ertoe leiden dat legitieme e-mail van een afzender die je bent vergeten toe te voegen, ongemerkt wordt tegengehouden.

BELEID EFFECT
p=geen Alleen ter controle – dit heeft geen invloed op de levering
p=quarantine Berichten die niet kunnen worden afgeleverd, worden naar de spamfolder gestuurd
p=afwijzen Foutmeldingen worden op de server geweigerd

Doorloop deze niveaus op basis van wat uit je rapporten blijkt – niet volgens een vast schema.

Hoe u uw DMARC-record aanmaakt en publiceert

PowerDMARC DMARC-recordgenerator
Maak binnen enkele seconden een correct opgemaakt DMARC-record aan. Kies uw beleid, voeg uw RUA-adres toe en kopieer het TXT-record dat klaar is om te worden gepubliceerd.

Maak het record aan als een TXT-record op _dmarc.uwdomein.com.

Minimale startresultaten:

v=DMARC1; p=none; rua=mailto:[email protected]

v=DMARC1 → geeft aan dat dit een DMARC-record is

p=geen → bewakingsmodus (geen berichten geblokkeerd)

rua=mailto: → adres waarnaar de geaggregeerde rapporten worden verzonden

TYPE GASTGEVER WAARDE
TXT _dmarc v=DMARC1; p=none; rua=mailto:[email protected]

Wat de rua-tag doet

De rua-tag is de plek waar de geaggregeerde DMARC-rapporten worden afgeleverd. Deze rapporten – die dagelijks door ontvangende mailservers worden verzonden – geven aan welke IP-adressen e-mail hebben verzonden via uw domein, of die berichten de SPF- en DKIM-controles hebben doorstaan, en of er onbekende afzenders zijn die zich voordoen als u. Zonder de rua-tag past uw DMARC-record wel een beleid toe, maar genereert het geen gegevens. Bij p=none zijn rapporten de enige output – het weglaten van de tag maakt de hele monitoringfase zinloos.

Stap 4 – Controleer of uw gegevens live zijn

Wacht na het publiceren van alle drie de records even totdat de DNS-verspreiding is voltooid, voordat u de controle uitvoert. De meeste records worden binnen enkele uren verspreid; houd rekening met een termijn van maximaal 48 uur voordat u een mislukte controle als een daadwerkelijk probleem beschouwt in plaats van als een vertraging in de verspreiding.

Hulpmiddelen om SPF, DKIM en DMARC te controleren

  • PowerDMARC SPF Checker – controleert of uw SPF-record bestaat, de juiste syntaxis heeft en de juiste afzenders vermeldt
  • PowerDMARC DKIM-checker – controleert of het DKIM-record actief is bij de juiste selector en het juiste domein
  • PowerDMARC DMARC Checker – controleert of uw DMARC-record te vinden is in _dmarc en geldige beleidslabels bevat
  • PowerDMARC DNS-propagatiecontrole – laat zien of uw records zijn doorgevoerd op DNS-servers wereldwijd; handig wanneer een controleprogramma kort na publicatie de melding ‘niet gevonden’ weergeeft
  • PowerDMARC Domain Analyzer – voert een volledige domeinscan uit voor SPF, DKIM, DMARC, BIMI, MTA-STS en TLS-RPT in één overzicht, zodat u uw volledige e-mailverificatiestatus kunt bekijken voordat u live gaat

Wat te doen als een record de verificatie niet doorstaat

Begin bij het begin. Controleer of het recordtype TXT is – en niet A, CNAME of MX. Controleer of de hostnaam overeenkomt met wat de tool verwacht: @ voor SPF, _dmarc voor DMARC en selector._domainkey voor DKIM. Let op veelvoorkomende fouten bij het kopiëren en plakken: extra spaties, ontbrekende puntkomma’s, aanhalingstekens die zijn overgenomen uit de DNS-interface, of een punt aan het einde van de recordnaam.

Als alles er in het DNS goed uitziet, gebruik dan de DNS Propagation Checker om te controleren of het record volledig is doorgevoerd, voordat je ervan uitgaat dat er een configuratiefout is.

Stap 5 – Houd uw rapporten en de voortgang van de handhaving in de gaten

Het publiceren van authenticatierecords is het begin van het proces, niet het einde. De fase p=none is bedoeld voor actieve monitoring: deze fase levert je de gegevens op om te controleren of je legitieme e-mail de authenticatie doorstaat, voordat je eventuele handhavingsmaatregelen neemt.

Onbewerkte DMARC-overzichtsrapporten worden geleverd als XML-bestanden – die zijn niet bedoeld om handmatig te lezen. PowerDMARC zet deze om in dashboards die je per afzender het volgende laten zien:

  • Welke IP-adressen hebben e-mails verzonden onder uw domeinnaam?
  • Of berichten de SPF-controle hebben doorstaan of niet
  • Of berichten de DKIM-controle hebben doorstaan of niet
  • Of er onbekende bronnen zijn die vanaf uw domein verzenden

Deze gegevens laten zien of je configuratie naar behoren werkt en brengen eventuele verzendplatforms aan het licht die je mogelijk over het hoofd hebt gezien bij het instellen van SPF of DKIM.

Wanneer moet je overschakelen van p=none naar p=reject?

Laat uw rapporten de gang van zaken bepalen. Zodra uit die rapporten consequent blijkt dat alle legitieme afzenders voldoen aan de SPF- of DKIM-verificatie, schakelt u over naar p=quarantine. Houd dit enkele weken in de gaten. Zodra u er zeker van bent dat er geen legitieme e-mail meer wordt geweigerd, schakelt u over naar p=reject. Er is geen standaard aantal dagen – het juiste moment om de handhaving aan te scherpen is wanneer uw rapporten aangeven dat u er klaar voor bent.

Veelgemaakte fouten bij het verifiëren van een nieuw domein

  • Als je twee SPF-records publiceert in plaats van één, werkt de SPF-validatie helemaal niet meer; voeg alle afzenders samen in één record
  • DKIM overslaan – SPF alleen is niet voldoende voor DMARC-conformiteit, en DKIM is de enige controle die bij het doorsturen van e-mails intact blijft
  • Als u DMARC instelt op p=reject voordat u de situatie in de gaten houdt, loopt u het risico dat legitieme e-mails van een afzender die u nog niet hebt geverifieerd, worden geblokkeerd
  • Als je de tag `rua=` weglaat, wordt alle zichtbaarheid tijdens de monitoringfase uitgeschakeld; er worden dan geen geaggregeerde rapporten verzonden
  • Geen controle van records na propagatie – een record dat er in uw DNS-paneel correct uitziet, kan toch een opmaakfout bevatten die alleen door een validatietool wordt opgemerkt

Conclusie

De volgorde is belangrijk: eerst SPF, dan DKIM en ten slotte DMARC. Bij een nieuw domein biedt het instellen van p=none je de mogelijkheid om te controleren of je configuratie correct werkt voordat je de regels daadwerkelijk toepast – zo bescherm je de reputatie van je domein nog voordat je de kans hebt gehad om die op te bouwen.

Probeer PowerDMARC gratis uit om uw gegevens te controleren, een volledige domeinscan uit te voeren of overzichtsrapporten in een overzichtelijk dashboard te bekijken, en zorg dat de authenticatie geregeld is voordat uw eerste e-mail op grote schaal wordt verzonden.

Veelgestelde Vragen

Heb ik e-mailverificatie nodig als mijn domein gloednieuw is?

Ja – zorg dat je dit hebt ingesteld voordat je ook maar één e-mail verstuurt. Een nieuw domein zonder authenticatierecords is een gemakkelijk doelwit voor spoofing, en uit vroege DMARC-rapporten kan blijken dat er al ongeoorloofde activiteiten plaatsvinden nog voordat je iets hebt verstuurd.

Wat is de juiste volgorde voor het instellen van SPF, DKIM en DMARC?

Eerst SPF, dan DKIM en vervolgens DMARC. DMARC beoordeelt de resultaten van de SPF- en DKIM-controles, dus beide moeten goed werken voordat de handhaving van DMARC zin heeft.

Hoe lang duurt het voordat DNS-verversing plaatsvindt nadat authenticatierecords zijn toegevoegd?

De meeste wijzigingen worden binnen enkele uren doorgevoerd. Houd rekening met een wachttijd van maximaal 48 uur en gebruik de DNS-propagatiechecker om te controleren of de propagatie is voltooid, in plaats van er zomaar vanuit te gaan.

Welk DMARC-beleid moet ik gebruiken voor een nieuw domein?

Begin met p=none. Controleer de geaggregeerde rapporten om te verifiëren of alle legitieme afzenders de authenticatie doorstaan, ga vervolgens over naar p=quarantine en uiteindelijk naar p=reject. Deze stap-voor-stapaanpak moet worden bepaald door de rapportgegevens, niet door een vast tijdschema.

Kan ik DMARC instellen voordat ik e-mails ga versturen?

Ja, en dat is zeker de moeite waard. DMARC-rapporten geven inzicht in alle activiteiten op uw domein vóór het verzenden van e-mails – inclusief mogelijk reeds plaatsvindend ongeoorloofd gebruik. Gebruik de Domain Analyzer om de authenticatiestatus van uw domein volledig te scannen voordat u uw eerste e-mail verstuurt.

Moet ik me aanmelden als ik alleen e-mail ontvang en geen e-mails verstuur?

SPF en DKIM zijn vooral van belang voor uitgaande e-mail, maar een DMARC-record wordt ook voor domeinen die alleen e-mail ontvangen nog steeds aanbevolen. Zonder een dergelijk record kan iedereen uw domeinnaam vervalsen om phishing-e-mails te versturen naar uw contactpersonen, klanten of partners.

CTA