Nepfacturen onder jouw bedrijfsnaam stoppen: DMARC, lookalike-domeinen en je klantcommunicatie

Je klant belt op een dinsdagmiddag. Vriendelijk, maar in de war: die factuur van 4.180 euro heeft hij vorige week betaald, dus waarom krijgt hij nu een herinnering? Je zoekt het na. Die factuur bestaat niet. Wat wel bestaat is een pdf met jouw logo, jouw opmaak en jouw factuurnummerreeks, verstuurd vanaf een afzender die je zonder aandachtig kijken voor die van jou aanziet, met een rekeningnummer dat niet van jou is.

Zoek daarna op wat je moet doen en je komt uit bij KVK en de Fraudehelpdesk. Goede pagina's, met hetzelfde advies: waarschuw je klanten en doe aangifte. Wat er niet staat is hoe je zorgt dat het morgen niet nog een keer kan. De KVK-pagina over misbruik van je bedrijfsnaam noemt spoofing wel als de gebruikte techniek, maar noemt geen SPF, DKIM of DMARC als tegenmaatregel. Daar zit dit stuk tussenin.

Bedrijfsnaamfraude is het gebruik van de naam, huisstijl en gegevens van een bestaand bedrijf om derden geld afhandig te maken. De Fraudehelpdesk registreert het als misbruik bedrijfsgegevens en telde daarvan 530 zakelijke meldingen in 2025, goed voor het hoogste zakelijke schadebedrag van dat jaar, 286.000 euro. Jij betaalt niet. Jouw naam staat er wel onder.

Dit is het draaiboek in vier lagen. Eerst vaststellen welk mechanisme je voor je hebt, want de remedie verschilt volledig. Dan je eigen domein dichtzetten zodat een vervalste afzender geweigerd wordt. Dan lookalike-domeinen opsporen en offline laten halen. En als laatste je factuurcommunicatie zo inrichten dat een klant zelf kan zien of iets echt van jou komt, met daarbij wat je doet op de dag dat er al betaald is.

Wat je nodig hebt

Voordat je iets in je DNS aanraakt, leg je dit klaar. De volgorde is niet vrijblijvend: de meeste mislukte DMARC-uitrollen stranden op het eerste punt, een lijst met verzenders die niet compleet bleek.

• Toegang tot je DNS-beheer. Bij je registrar of je hostingpartij, met rechten om TXT-records toe te voegen en te wijzigen. Weet je niet wie je registrar is, dan vind je dat in laag 3.
• Beheerderstoegang tot je mailplatform. Microsoft 365 of Google Workspace. DKIM zet je daar aan, niet alleen in DNS.
• Een complete lijst van alles wat mail verstuurt met jouw domein in de afzender. Je mailplatform, je boekhoudpakket, je webshop, je nieuwsbrieftool, je offertetool, je supportsysteem, het contactformulier op je site.
• Een postbus voor de rapportages, bijvoorbeeld dmarc@jouwdomein.nl, of een account bij een rapportagedienst die dat adres voor je levert.
• De originele valse mail als .eml-bestand, opgevraagd bij de klant die hem kreeg. Zonder de kopregels kun je laag 1 niet doen.
• Vier tot zes weken doorlooptijd. Het handwerk is een paar uur. De rest is wachten op rapportages, en dat wachten is precies waar de veiligheid vandaan komt.

Laag 1: welk mechanisme heb je voor je?

"Zet DMARC aan" is het standaardadvies, en in ongeveer de helft van de gevallen lost het niets op. Dat komt doordat dezelfde klacht, iemand factureert onder mijn naam, vier verschillende technische oorzaken kan hebben. Twee daarvan raakt DMARC niet aan.

Begin dus bij het bewijs. Vraag je klant om de originele mail als bijlage, niet als doorstuur en niet als screenshot. Een doorgestuurde mail verliest precies de kopregels die je nodig hebt. In Gmail kiest je klant "Als bijlage doorsturen"; in Outlook sleept hij de mail in een nieuw bericht. Open hem daarna zelf en lees de kopregels: in Gmail via "Origineel bericht weergeven", in Outlook via Bestand, Eigenschappen, Internetkopteksten.

Drie regels vertellen je alles. From is het domein dat je klant zag staan. Return-Path is waar de bounces heen gaan, vaak het echte domein van de afzender. En Authentication-Results bevat het oordeel van de ontvangende server: spf=, dkim= en dmarc= met pass of fail erachter.

Die laatste regel is de belangrijkste van de tabel. Een geslaagde DMARC-controle op je eigen domein betekent dat iemand vanuit jouw mailplatform verstuurde, of via een tool die namens jou mag versturen. Dan is dit geen communicatievraagstuk maar een incident, en loop je eerst je credentials, je netwerk en je herstelplan na voordat je aan DNS begint.

Leg het vast terwijl je bezig bent. Bewaar het .eml-bestand, de nepfactuur, het gebruikte IBAN, het bedrag, de datum en welke klant hem kreeg. Dat mapje is straks je bewijs bij een takedown en bij de aangifte, en het is precies wat je niet meer terugvindt als je drie weken later begint met zoeken.

Laag 2: van p=none naar p=reject zonder je eigen mail te breken

DMARC is een TXT-record in je DNS waarin je twee dingen vastlegt: wat een ontvangende mailserver moet doen met mail die jouw domein als afzender voert maar niet door SPF of DKIM komt, en waar die server daarover mag rapporteren. Sinds mei 2026 is het een officiële standaard van de IETF, vastgelegd in RFC 9989.

De reden dat zoveel bedrijven op p=none blijven hangen, is dat ze de rapportagestap overslaan. Zonder rapportages weet je niet welke van je eigen tools nog mail verstuurt die niet uitlijnt, en dan is p=reject een gok met je eigen offertes als inzet.

1. Inventariseer elke verzender

Maak een tabel met vier kolommen: de tool, het domein of subdomein dat hij in de afzender zet, de SPF-include die hij vraagt, en de DKIM-selector die hij levert. Je vergeet er gegarandeerd een paar. De rapportages uit stap 5 zijn er precies om die aan te vullen.

2. Eén SPF-record, onder de tien lookups

Een domein mag maximaal één SPF-record hebben. Twee records leveren een permanente fout op, en die fout betekent dat SPF voor iedereen faalt. Hetzelfde gebeurt boven de tien DNS-lookups, de harde grens uit de SPF-standaard: elke include: van een tool telt mee, en de includes van die tools tellen ook mee. Vier of vijf mailtools erin en je zit eraan.

Sluit af met ~all en niet met -all. Het NCSC schrijft dat een hardfail mail al kan blokkeren voordat DKIM en DMARC überhaupt beoordeeld zijn, en dat is niet wat je wil: het is juist DMARC dat de beslissing moet nemen.

3. DKIM per verzender, met een eigen selector

DKIM zet een cryptografische handtekening onder je mail. Het NCSC adviseert RSA-SHA256 met 2048 bits, naast Ed25519-SHA256 voor moderne servers, en geen RSA-SHA1 meer. Belangrijker voor jou: geef elke verzender zijn eigen selector. Dan kun je later één tool intrekken zonder je hele mailstroom te raken.

In Microsoft 365 staat DKIM in de Defender-portal onder e-mailverificatie; in Google Workspace onder Apps, Google Workspace, Gmail, e-mail verifiëren, waar je kiest voor een 2048-bits sleutel. Je boekhoud-, nieuwsbrief- en supporttools leveren elk hun eigen CNAME- of TXT-record aan.

4. Publiceer DMARC op p=none, met rua

Het eerste record is bewust tandeloos:

_dmarc.jouwdomein.nl TXT "v=DMARC1; p=none; rua=mailto:dmarc@jouwdomein.nl"

Het rua-adres is het hele punt. Zonder dat adres krijg je geen rapportages en leer je niets. Laat ruf weg: het NCSC raadt die foutrapportages af omdat er persoonsgegevens in zitten.

Dit is meteen het minimum dat de grote mailplatforms van je vragen. Gmail eist van bulkverzenders vanaf 5.000 berichten per dag SPF, DKIM én DMARC, waarbij het beleid op none mag blijven staan zolang de From-regel uitlijnt met SPF of DKIM.

5. Lees twee tot vier weken rapportages

De rapportages komen als XML binnen, dagelijks, per ontvangende partij. Handmatig lezen kan, maar is zonde van je tijd. De gratis wekelijkse digest van Postmark toont de tien grootste bronnen met vijf IP-adressen per bron en zeven dagen historie; de betaalde versie kost 14 dollar per domein per maand en geeft alle bronnen, 60 dagen historie en een dashboard (prijzen augustus 2026).

Je zoekt drie dingen. Eigen tools die falen op uitlijning, want dat zijn je toekomstige slachtoffers. Verzenders die je niet herkent maar wel van jou blijken, meestal een dienst die marketing ooit aanzette. En bronnen die niets met jou te maken hebben: dat is de spoofer.

6. Repareer de uitlijning, niet het beleid

Elke legitieme verzender die faalt, los je op bij de bron: DKIM aanzetten, of de juiste include in SPF, of de tool laten versturen vanaf een subdomein met eigen sleutels. Verhoog je beleid pas als de rapportages twee weken schoon zijn. Doorgestuurde mail en mailinglijsten blijven falen, dat is normaal en geen reden om te wachten.

7. Stap op met t=y, niet met pct

Hier zit de val die de meeste handleidingen nog niet hebben verwerkt. Jarenlang faseerde je een strenger beleid in met pct=10, dan 25, dan 50. Die tag bestaat niet meer: RFC 9989 heeft pct geschrapt en vervangen door t, en een ontvanger die de nieuwe standaard volgt negeert onbekende tags. Je pct=10 levert bij zo'n ontvanger dus honderd procent handhaving op.

De vervanger doet iets anders en iets veiligers. Met t=y erbij wordt een reject-beleid als quarantine toegepast en een quarantine-beleid als none: je zet één trede lager dan wat er staat, voor alle mail in plaats van voor een steekproef. Microsoft schrijft in zijn eigen DMARC-handleiding nog steeds de pct-ladder voor, bijgewerkt in juli 2026. Volg die stap niet.

De route wordt dan: p=quarantine; t=y; een week, p=quarantine; twee weken, en daarna p=reject;. Blijf de rapportages lezen bij elke trede.

8. Zet ook je stille domeinen dicht

Elk domein dat je bezit maar niet voor mail gebruikt, is een gratis afzenderadres voor een oplichter. Het NCSC is daar expliciet over: implementeer SPF, DKIM en DMARC op al je domeinnamen, inclusief de domeinen waarvandaan niets verstuurd wordt. Zo'n geparkeerd domein krijgt v=spf1 -all en v=DMARC1; p=reject;, zonder DKIM-record.

Vergeet je subdomeinen niet. Zonder sp= erft een subdomein je hoofdbeleid, maar een niet-bestaand subdomein is een apart geval: daar is de nieuwe np=-tag voor. v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@jouwdomein.nl sluit alle drie de gaten.

Laag 3: lookalike-domeinen opsporen en laten weghalen

Een p=reject-record is een grens rond precies één domein: het jouwe. Registreert iemand jouwbedrijf-facturen.nl en publiceert hij daar keurige SPF-, DKIM- en DMARC-records, dan komt zijn mail overal doorheen. Technisch is er niets mis mee. Hij liegt alleen over wie hij is, en dat is geen protocolvraagstuk.

Opsporen doe je met permutaties. De open source tool dnstwist genereert de varianten van je domeinnaam die een mens over het hoofd ziet en controleert per variant of hij geregistreerd is. Installeren doe je met pip install dnstwist[full], draaien met dnstwist --registered jouwbedrijf.nl. Naast typefouten en homoglyphen doet hij ook detectie van MX-hosts die bedoeld zijn om verkeerd geadresseerde mail te onderscheppen, en dat is het signaal waar je op let. Een lookalike zonder MX-records is meestal geparkeerd. Een lookalike mét MX-records is een werkende mailbox.

Twee gratis controles doe je er maandelijks bij. Zoek je merknaam op crt.sh, dat de logs van uitgegeven TLS-certificaten doorzoekt: wie een lookalike-domein achter https wil zetten, moet een certificaat aanvragen en dat komt in die logs. En zet een Google Alert op je bedrijfsnaam, wat KVK ook adviseert. Wil je het uitbesteden, dan bestaat SIDN Merkbewaking, dat wereldwijd waarschuwt bij registraties die op je merknaam lijken.

Weghalen is een ladder, geen knop. Zoek eerst uit wie erachter zit. Dat doe je via RDAP, de opvolger van Whois die sinds begin 2025 de norm is en waarin een anonieme bevraging in elk geval de registrar toont. Die registrar is je eerste adres.

Daarna geldt voor .nl een vaste volgorde. SIDN neemt een verzoek tot buitengebruikstelling pas in behandeling als je zelf contact hebt gezocht met de maker van de inhoud, de websitebeheerder, de domeinnaamhouder, de hoster of reseller én de registrar, met kopieën van die correspondentie erbij. Buitengebruikstelling is de uiterste maatregel, en alleen als het misbruik onmiskenbaar is en de maatregel passend.

Start daarom parallel de snelle route: meld het domein bij Netcraft via report.netcraft.com, de partij waarmee SIDN samenwerkt. Netcraft waarschuwt registrar, hoster en houder in intervallen van 18 uur, waarna SIDN op zijn vroegst 66 uur na de eerste melding ingrijpt. Dat werkt: via die route gingen in 2025 333 .nl-domeinnamen offline, gemiddeld binnen 56 uur, en via de identiteitscontrole op de houder verdwenen er dat jaar nog eens 3.600.

Reken op dagen, niet op uren. In die dagen loopt de fraude door, en dat is precies waarom laag 4 geen bijzaak is.

Laag 4: maak je facturen verifieerbaar voor je klant

De inkomende kant is het domein van je klant. Of zijn crediteurenstroom controleert of naam en rekeningnummer bij elkaar horen, en of hij een IBAN-wijziging als aparte mutatie behandelt in plaats van als factuurveld, bepaalt hij zelf. Wat jij kunt doen, is hem een manier geven om binnen tien seconden te controleren of iets echt van jou komt.

Publiceer je betaalgegevens op één plek op je eigen site, met één zin erbij: dit rekeningnummer wijzigt nooit, en een mail die iets anders beweert is vals. Dat is de goedkoopste maatregel in dit hele stuk en de enige die werkt tegen een naamspoof vanaf een gratis mailadres.

Verstuur facturen vanaf één vast adres op je hoofddomein, en zeg erbij welk adres dat is. Drie verschillende afzenders voor offertes, facturen en herinneringen maken jouw eigen mail net zo moeilijk te herkennen als die van de oplichter.

Zet een betaallink in plaats van alleen een IBAN in een pdf. Een betaallink of iDEAL-QR van Mollie of Stripe landt op jouw eigen checkout, met jouw domein in de adresbalk. Een rekeningnummer in een pdf is een reeks cijfers die iedereen kan overtypen; een betaallink verwijst naar iets dat een aanvaller niet kan namaken zonder ook je domein over te nemen.

Ga waar het kan naar e-facturatie. Een UBL- of Peppol-factuur komt als gestructureerd bestand binnen in het pakket van je klant, niet als pdf in een mailbox. Dat haalt de mailbox als aanvalsplek uit de keten, en scheelt je klant het overtypen dat de rest van dit probleem veroorzaakt.

Waarschuw gericht, niet vaag. "Let op voor phishing" helpt niemand. Het IBAN, het gebruikte afzenderadres, de datum en het factuurnummerbereik helpen wel. De sterkste verdediging tegen dit soort aanvallen zit sowieso in je proces en niet in je software, en een afspraak dat een betaalwijziging altijd telefonisch wordt bevestigd, op een nummer dat de klant zelf opzoekt, is meer waard dan elk filter.

Het draaiboek voor de dag dat er al betaald is

Dit is de volgorde als het telefoontje net binnen is. Snelheid telt: hoe langer het geld op de rekening van de fraudeur staat, hoe kleiner de kans dat er iets van terugkomt.

1. Zet je klant meteen aan de telefoon met zijn eigen bank. Alleen de ontvanger kan terugbetalen; de bank kan dat vragen, niet afdwingen.
2. Laat je klant aangifte doen. Zonder aangifte start zijn bank de fraudeprocedure niet: de betaler moet altijd eerst aangifte doen bij de politie, waarna de bank via de PNBF-procedure de ontvanger 21 dagen geeft om terug te betalen en anders naam en adres kan vrijgeven. Voorwaarden: beide IBAN's beginnen met NL en de betaling is minder dan 13 maanden oud.
3. Verzamel het dossier uit laag 1 en bewaar het centraal.
4. Doe zelf aangifte en meld het bij de Fraudehelpdesk. Jij bent geen betalende partij, maar je meldt wel het misbruik van je bedrijfsgegevens, en die meldingen waarschuwen anderen.
5. Informeer je andere klanten binnen een dag, via je eigen kanaal, met de concrete kenmerken erbij.
6. Publiceer je DMARC-record diezelfde dag op p=none met rua. Je hebt vanaf nu twee weken bewijs nodig, en die klok begint pas te lopen als het record er staat.
7. Start de takedown volgens laag 3, met de melding bij Netcraft en de registrar tegelijk.
8. Controleer of het echt spoofing was. Toont de kopregel dmarc=pass op jouw domein, dan zat iemand in een mailbox en heb je een beveiligingsincident, mogelijk met een meldplicht. Dan is dit een ander draaiboek.

Valkuilen die deze klus laten stranden

• p=reject publiceren zonder rapportages te hebben gelezen. Je eigen facturen, offertes en nieuwsbrief verdwijnen dan stilletjes. Twee tot vier weken rapportages is geen formaliteit maar de hele veiligheid van de operatie.
• pct gebruiken als vangnet. De tag is uit de standaard verdwenen en wordt door moderne ontvangers genegeerd, wat betekent dat je volledig handhaaft terwijl je denkt op tien procent te zitten. Gebruik t=y.
• Meer dan tien DNS-lookups in SPF. Het resultaat is een permanente fout waardoor SPF overal faalt en je DMARC volledig op DKIM leunt. Tel opnieuw bij elke tool die je toevoegt.
• Denken dat DMARC lookalikes tegenhoudt. Een ander domein met eigen geldige records komt er gewoon doorheen. Dat is laag 3, en die is nooit klaar.
• Je geparkeerde domeinen vergeten. Elk ongebruikt domein zonder records is een gratis afzender met jouw merknaam erop.
• Een takedown starten zonder papieren spoor. Zonder kopieën van je contact met houder, hoster en registrar stuurt SIDN je terug naar het begin.
• Schrikken van internet.nl. SIDN waarschuwde bij de publicatie van de nieuwe standaard dat de test de nieuwe RFC mogelijk nog niet volledig ondersteunt en correcte records tijdelijk kan afkeuren. Draai een goed record niet terug op één rood vinkje.
• Vaag waarschuwen. Een algemene phishingwaarschuwing verandert het gedrag van niemand. Het IBAN en het afzenderadres wel.

Zelf doen, tool of laten inrichten

Het DNS-werk zelf is niet moeilijk. Het lezen en volhouden is waar het misgaat, en dat is ook de as waarop je kiest.

De vuistregel die ik zelf aanhoud: doe laag 2 zelf als je één domein en een handvol verzenders hebt, want dan leer je onderweg precies wat er in je eigen mailstroom zit. Loopt de fraude nu, dan is de volgorde omgekeerd en begin je bij laag 3 en 4, want die stoppen de schade van deze week. Laag 2 stopt die van volgend kwartaal.

Zo loopt het in de praktijk

Neem een installatiebedrijf met veertien monteurs. Het bedrijf is een voorbeeld; de stappen, de volgorde en de valkuilen zijn die uit de praktijk.

Dag 1. Een klant meldt dat hij 4.180 euro heeft betaald op een rekening die niet van het bedrijf is. Het .eml-bestand komt binnen. In de kopregels staat het eigen domein in de From-regel, met spf=fail en dmarc=fail (p=none). Mechanisme één: een exacte spoof. Diezelfde middag gaat er een DMARC-record de lucht in op p=none met een rua-adres, en wordt er een gratis rapportagedigest aan gekoppeld. De klant belt zijn bank en doet aangifte.

Week 1 tot 3. De rapportages leveren vijf verzenders op. Microsoft 365 lijnt netjes uit. Het boekhoudpakket verstuurt facturen zonder DKIM en faalt dus op uitlijning, wat betekent dat p=reject op dat moment de eigen facturen zou hebben tegengehouden. De nieuwsbrieftool loopt goed via een subdomein. Er staat nog een include in SPF van een offertetool die twee jaar geleden is opgezegd. En er is een vierde categorie: een paar honderd berichten vanaf IP-adressen die nergens bij horen.

Week 3. DKIM aan bij het boekhoudpakket, de dode include eruit, waarmee het aantal DNS-lookups van elf naar zeven gaat. Twee weken schone rapportages later gaat het record naar p=quarantine; t=y;, een week erna naar p=quarantine;, en aan het eind van week zes naar p=reject; sp=reject; np=reject;. Het ongebruikte .com-domein van het bedrijf krijgt v=spf1 -all en p=reject.

Parallel, week 1. dnstwist vindt een variant met een koppelteken erin, elf dagen voor de nepfactuur geregistreerd, mét MX-records. RDAP geeft de registrar. Er gaat een melding naar die registrar en naar Netcraft tegelijk. Vier dagen later is het domein offline.

Week 2 tot 4. Facturen gaan voortaan vanaf één adres, met een betaallink in plaats van alleen een IBAN. Op de site staat één pagina met de echte domeinnamen, het rekeningnummer en de zin dat dat nummer nooit wijzigt. Alle klanten kregen in week 1 al een bericht met het gebruikte IBAN en afzenderadres erin.

De uitkomst is eerlijk gemengd. Vanaf week zes wordt mail die het domein letterlijk in de afzender zet, geweigerd bij Gmail en Outlook. Het lookalike-domein is weg, al kan er morgen een nieuwe worden geregistreerd, en daarom staat die scan nu maandelijks in de agenda. De 4.180 euro kwam niet terug, want de ontvangende rekening was leeg voordat de aangifte rond was. Dat laatste is de reden dat laag 4 er staat.

Deze klus heeft een eigenaardige eigenschap: hij is nooit af, maar hij wordt wel snel goedkoper. De eerste ronde kost je zes weken aandacht. Daarna is het een maandelijkse scan, een blik op de rapportages als je een tool toevoegt, en een pagina op je site die je toch al had moeten hebben. Wat je ervoor terugkrijgt is niet dat er nooit meer iemand jouw naam gebruikt. Het is dat het niet meer werkt, en dat je klant het binnen tien seconden kan zien.