In this post:
Contact verification is de check of het e-mailadres, het telefoonnummer en de functie van een contact nog echt en actueel zijn, voordat iemand in je team contact opneemt.
Het klinkt als administratie, en zo behandelen de meeste teams het ook. Het probleem is dat slechte contactdata zichzelf nooit aankondigt. Een export van een dataprovider ziet er net zo netjes uit als een vijfde ervan dood is als wanneer alles klopt. Welke van de twee je hebt gekocht, merk je pas als de bounces binnenkomen en je verzenddomein de klappen opvangt.
Het gaat meestal mis op twee punten: wat je checkt en wanneer. Teams checken het e-mailadres één keer, bij de import, en zien het groene vinkje als blijvend. Een e-mailcheck zegt niets over de vraag of de persoon er nog werkt. En een check uit maart zegt weinig over een lijst die je in september verstuurt.
TL;DR
E-mailchecks lopen in een vaste volgorde: eerst de syntax, dan het domein en de MX-records, en dan een mailboxcheck die met de mailserver van de ontvanger praat zonder iets te versturen. Catch-all-domeinen en servers die het antwoord verbergen, komen terug als onbekend. Dat is iets anders dan geldig.
Een goede verificatieronde geeft elk record een oordeel (geldig, ongeldig, riskant of vertrokken). Zo hoef je niet te varen op een vaag gevoel dat de lijst er wel goed uitziet. Alleen de groep die geldig en actueel is, gaat direct een sequence in.
E-mailvalidatie dekt één veld. Contact verification checkt ook het telefoonnummer, de functietitel en of de persoon nog bij het bedrijf werkt. Een werkende inbox van iemand die zes maanden geleden is vertrokken, bereikt namelijk niemand.
Tussen twee checks verouderen lijsten, omdat mensen van baan wisselen en bedrijven fuseren, van naam veranderen of stoppen. Elke bounce uit een verouderde lijst telt mee tegen je sender reputation. Dat raakt daarna al je mail, ook wat je naar goede contacten stuurt.
Behandel elk oordeel anders: verwijder ongeldige adressen, zet spamtraps en bekende klagers op je suppressielijst, verstuur naar catch-all-adressen apart in kleine batches, vervang rolgebonden adressen zoals info@ door een persoon met een naam, en check onbekende adressen opnieuw voordat je beslist.
Verifieer in bulk als je een lijst bouwt en nog een keer vlak voor de lancering. Bouw de check in je Clay-tabel of enrichment-flow in, zodat hij op elk nieuw record draait zonder dat iemand eraan hoeft te denken. Telefoonnummers en functietitels vragen om dezelfde gewoonte: voor elke campagne checken en opnieuw verrijken.
Wat een verificatietool doet als hij een e-mailadres checkt
Tools voor e-mailverificatie volgen allemaal ongeveer dezelfde volgorde. Als je de stappen kent, kun je de resultaten beter lezen. Het verklaart ook waarom sommige adressen nooit een duidelijk ja krijgen.
Syntax. De tool checkt of het adres goed is opgemaakt. Zo vang je typfouten en mislukte imports meteen af.
Domein en MX-records. De tool zoekt op of het domein bestaat en MX-records publiceert die aangeven welke servers mail voor dat domein aannemen. Dit deel heet vaak MX-validatie, en het vangt dode en verkeerd gespelde bedrijfsdomeinen af.
Mailboxcheck. De tool begint een gesprek met de mailserver van de ontvanger, geeft het adres op als ontvanger en verbreekt de verbinding voordat er een bericht wordt verstuurd. Weigert de server die ontvanger, dan bestaat de mailbox niet.
Risicovlaggen. Ook adressen die bestaan, kunnen problemen geven. De tool markeert catch-all-domeinen, bekende spamtraps, wegwerpadressen en rolgebonden adressen zoals info@ of sales@.
Persoonscheck. Betere setups bevestigen daarna de mens: werkt deze persoon nog bij dit bedrijf, in deze functie? Daarvoor heb je verse data nodig uit een enrichment-bron of een profiel-lookup. Een mailserver kan die vraag niet beantwoorden.
Waarom sommige adressen terugkomen als onbekend
De mailboxcheck werkt alleen als de ontvangende server een eerlijk antwoord geeft, en veel servers doen dat niet. De SMTP-standaard zelf, RFC 5321, vermeldt dat sommige servers ontvangers pas controleren nadat de tekst van het bericht binnen is. Andere zijn ingericht als catch-all-domein dat elk adres accepteert, zodat ze nooit prijsgeven welke mailboxen echt bestaan.
De documentatie van ZeroBounce is er duidelijk over: catch-all-adressen kun je niet valideren zonder een echte e-mail te sturen en op een bounce te wachten. Een catch-all-resultaat betekent dus dat de tool het niet kon achterhalen. Behandel het ook zo.
Rolgebonden adressen zijn een ander probleem. Ze zijn echt, en RFC 2142 standaardiseert zelfs namen als INFO, SALES en SUPPORT om delen van een organisatie te bereiken. Alleen horen ze bij een functie, en achter een functie zit geen vaste persoon. Je bericht komt dus terecht bij wie die gedeelde inbox toevallig beheert, en die persoon drukt veel eerder op de spamknop dan dat hij een meeting inplant.
Vier records uit één "schone" lijst, door die checks gehaald
Zo ziet dat eruit op echte data. Deze vier rijen kwamen uit een lijst die er in de spreadsheet perfect uitzag: namen ingevuld, functietitels ingevuld, elk e-mailadres in een logisch formaat.
Sofia, VP of Operations, komt overal doorheen. Haar mailbox bestaat, ze heeft de functie nog en de bedrijfsgegevens kloppen. Van de vier is zij de enige die je zonder nadenken in een sequence zet.
Jan is de verraderlijke. Zijn e-mailadres bij zijn oude werkgever neemt nog mail aan, dus een simpele e-mailcheck keurt hem goed. Alleen is hij zes maanden geleden vertrokken, en wie die inbox nu leest (als iemand dat al doet), gaat niet reageren op een bericht over growth tooling. Er komt geen bounce terug die je waarschuwt, dus zo'n record kan jarenlang in je CRM blijven staan.
De mailbox van Amira bestaat niet meer. Mail je haar, dan krijg je een hard bounce, en mailboxproviders lezen dat als een teken dat je je data niet goed bijhoudt.
Het adres van Tom is info@ op een domein dat mail voor elk adres aanneemt. Misschien komt het in een gedeelde inbox terecht, misschien bij niemand, en de verificatietool kan je niet vertellen welke van de twee. Dat oordeel is riskant. Geldig is het niet.
Eén lijst, vier verschillende antwoorden. Contact verification draait erom dat je die antwoorden krijgt voordat je verstuurt, nu ze nog weinig kosten.
E-mailvalidatie checkt een adres. Contact verification checkt een persoon
De twee termen worden door elkaar gebruikt, en dat is onterecht. E-mailvalidatie beantwoordt één vraag: kan dit adres mail ontvangen? Formaat, domein, mailbox, risicovlaggen. Dat zijn stap één tot en met vier hierboven.
Contact verification doet dat allemaal en neemt de rest van het record erbij. Werkt het telefoonnummer nog, heeft de persoon nog de functietitel die jij hebt opgeslagen, werkt hij überhaupt nog bij het bedrijf, en klopt de firmografische data die aan hem hangt (bedrijfsgrootte, branche, locatie) nog? Je personalisatie is maar zo waar als die velden.
Jan uit het voorbeeld laat zien waarom het verschil telt. Zijn e-mailadres komt door de validatie. Pas de bredere check ziet dat hij weg is. Draai je outbound op enig volume, dan hoort een flink deel van je "geldige" e-mailadressen bij mensen zoals Jan. E-mailvalidatie alleen laat je nooit zien welke dat zijn.
Waarom contactdata tussen twee checks veroudert
Een geverifieerde lijst is een momentopname. Zodra de check klaar is, gaan de mensen erop gewoon door met van baan wisselen, promotie maken en vertrekken.
Baanwisselingen richten de meeste schade aan. Als iemand vertrekt, wordt zijn zakelijke e-mailadres meestal uitgezet of doorgestuurd naar een collega. De functietitel in je record klopt dan niet meer, en niets in je spreadsheet verandert om je dat te laten weten. Promoties en interne overstappen vallen nog minder op, omdat het e-mailadres blijft werken terwijl de rol waar je naartoe schrijft is verdwenen.
Ook de bedrijven waar die mensen werken, veranderen. Na een overname zit iedereen op een nieuw domein, een rebrand zet het oude domein buiten gebruik, en als een bedrijf stopt, verdwijnt in één keer een hele groep contacten. Dit is data decay, en het stopt nooit.
De kosten komen op drie plekken terecht. Reps besteden tijd aan contacten die ze niet kunnen bereiken. Ongeldige adressen drijven je bounce rate op. En die bounces slijten de sender reputation uit die je e-mail deliverability bepaalt voor elk bericht dat je verstuurt, ook de berichten aan prima contacten. Een nieuw verzenddomein voelt dit het snelst, omdat het geen historie heeft die een slechte eerste week opvangt.
Wat je doet met elk resultaat van contact verification
Verificatietools geven geen simpel geslaagd of gezakt terug. Ze geven categorieën, en elke categorie vraagt om een andere beslissing. De namen verschillen per leverancier. Zo gaan wij om met de gebruikelijke set.
Resultaat | Wat het betekent | Wat wij ermee doen |
|---|---|---|
Geldig | De mailbox bestaat en accepteerde de check | Versturen, zolang de persoonscheck ook slaagt |
Ongeldig | De server weigerde het adres | Verwijderen en via enrichment een nieuw adres zoeken |
Catch-all of accept-all | Het domein accepteert alles, dus de mailbox is niet te bevestigen | In een aparte, kleine batch versturen vanuit een goed opgewarmde inbox en de bounces nauwlettend volgen |
Rolgebonden | Een gedeeld adres zoals info@ of sales@ | Buiten cold sequences houden en bij het account een persoon met naam zoeken |
Spamtrap of bekende klager | Door de leverancier gemarkeerd als adres dat verzenders schaadt | Permanent op de suppressielijst zetten |
Wegwerpadres | Een tijdelijke inboxdienst | Op de suppressielijst zetten |
Onbekend | De server gaf geen antwoord, vaak omdat hij offline was of achter een antispamsysteem zat | Een paar dagen later opnieuw checken voordat je beslist |
Twee kanttekeningen. Spamtraps opsporen lukt altijd maar gedeeltelijk. Volgens de eigen documentatie van ZeroBounce kent het veel traps, al ontbreken er altijd een paar. En het oordeel "geldig" zegt alleen iets over de mailbox. Ook een geldig adres heeft dus eerst de persoonscheck nodig voordat het in de buurt van een sequence komt.
Wanneer je verifieert, en hoe je niet meer afhankelijk bent van wie eraan denkt
Bulkverificatie schoont een hele lijst in één keer op. Zo bereid je een campagne efficiënt voor, en het hoort thuis in de list building zelf, zodat slechte records worden afgevangen voordat ze ooit je CRM of sequencer bereiken.
Realtime verificatie checkt een contact op het moment dat je het gebruikt: als er een formulier wordt ingevuld, als er een record wordt aangemaakt of vlak voordat het een sequence ingaat. Een versere check bestaat niet.
Wij gebruiken allebei. Bulk bij het bouwen, dan een tweede ronde vlak voor de lancering, en nog een als een lijst langer dan een paar weken ongebruikt heeft gelegen. De tweede ronde vangt af wat er in de tussentijd is verouderd, en bij oudere lijsten is dat zelden niks.
De setups die standhouden, zijn de setups waarin niemand hieraan hoeft te denken. In een Clay-tabel is verificatie gewoon een extra kolom die op elke nieuwe rij draait. Gekoppeld aan waterfall enrichment doet die kolom meer dan slechte adressen markeren: zakt het e-mailadres van de ene provider voor de check, dan krijgt de volgende provider de kans om een beter adres te vinden. Zo worden verificatie en data enrichment één lus die vindt, bevestigt en vervangt.
Door volume wordt de automatisering onmisbaar. Een klein deel slechte adressen op een paar honderd verzendingen is vervelend. Hetzelfde deel op duizenden verzendingen per week drijft je bounce rate naar een niveau waarop providers je gaan filteren. Bouw je de check in de systemen die sales prospecting automatiseren, dan is elk contact geverifieerd voordat je het gebruikt, op welk volume je ook draait.
Telefoonnummers en functietitels hebben hun eigen checks nodig
E-mail krijgt de meeste aandacht, omdat e-mailbounces zichtbaar zijn. Telefoondata faalt zonder dat je het hoort: een nummer dat eindeloos overgaat, bij een receptie uitkomt of bij de vorige werkgever van iemand hoort, lijkt gewoon op een rep die niemand aan de lijn krijgt.
Telefoonverificatie checkt of een nummer actief is en, het liefst, of het een direct nummer of mobiel nummer is in plaats van het algemene nummer van een kantoor. Dat verschil bepaalt of een cold call de persoon bereikt. De praktische kant behandelen we in onze gids over leads die klaar zijn om te bellen.
Functiedata verdient dezelfde behandeling. Een titel die klopte toen je het record verrijkte, kan na een promotie of overstap fout zijn. Je bericht leest dan vreemd voor iemand die dat werk niet meer doet. Functietitels opnieuw verrijken voor een campagne is de persoonsversie van e-mailadressen opnieuw verifiëren, en het is de stap die de meeste teams overslaan.
Samenvatting
Een contactlijst vertelt je alleen wie iemand was toen de data werd verzameld. Met contact verification ontdek je wie er nog zit, nog bereikbaar is en nog de functie heeft waar je naartoe schrijft. En dat moet dicht genoeg bij de verzending gebeuren om iets te betekenen.
De techniek is bekend. Mailservers bevestigen of weigeren veel mailboxen, catch-all-domeinen zijn helemaal niet te bevestigen, en rolgebonden adressen zijn echt, al zijn ze zelden een cold email waard. Het oordeel zit in wat je met elk antwoord doet, en in het checken van de persoon naast het adres.
Teams die dit goed doen, praten er zelden over, want bij hen gebeurt niets dramatisch. Hun bounce rates blijven laag, hun domeinen blijven gezond en hun reps besteden de dag aan mensen die kunnen reageren. Daarom behandelen de beste outbound-experts het als een vaste stap, en het ligt als onopvallende basis onder elk serieus go-to-market-systeem.
Wil je die stap voor je laten bouwen? Wij zetten verificatie op in je eigen Clay en CRM, gekoppeld aan enrichment en aan de sequencer, en dragen het over zodat het blijft draaien als wij weg zijn.
Veelgestelde vragen
Maakt contact verification je outreach trager?
Niet op een manier die ertoe doet. Een lijst van een paar duizend contacten verifiëren duurt meestal een paar minuten, en een check die in je enrichment-tabel zit, draait zonder dat iemand er iets voor hoeft te doen. Wat pas echt vertraagt, is de check overslaan: reps die dode contacten bewerken, een bounce rate die oploopt en weken werk om een verzenddomein te herstellen na één slechte campagne. Een korte check voor de lancering beschermt de snelheid van alles wat daarna komt.
Stuurt het verifiëren van een e-mailadres een e-mail naar het contact?
Nee. Een verificatietool maakt verbinding met de mailserver van de ontvanger, vraagt of die mail voor dat adres wil aannemen en verbreekt de verbinding voordat er een bericht wordt verstuurd. Het contact ziet helemaal niets. De uitzondering is een catch-all-domein, waar de server elk adres accepteert. Dan weet je het alleen zeker door een echte e-mail te sturen en te kijken of die bounct, en dat vermijden verificatietools bewust.
Is het veilig om cold email naar catch-all-adressen te sturen?
Soms, als je voorzichtig bent. Catch-all-adressen zijn vaak echt, maar een verificatietool kan ze niet bevestigen, dus een deel zal bouncen. Verstuur ze in een aparte, kleine batch vanuit een opgewarmde inbox met een gezonde reputatie, en houd de bounce rate van alleen die batch in de gaten. Loopt die op, stop dan en laat de rest vallen. Meng nooit een groot blok catch-all-adressen in je hoofdverzending vanaf een nieuw domein.
Waarom bouncen e-mails die door de verificatie kwamen toch?
Daar zijn een paar redenen voor. De mailbox kan na de check zijn verwijderd, wat vaak gebeurt bij lijsten die weken hebben stilgelegen. Sommige servers accepteren de ontvanger tijdens de check en weigeren het bericht later alsnog. Catch-all-domeinen kunnen door een soepele tool komen en daarna bouncen. En een volle mailbox of een tijdelijk serverprobleem geeft een soft bounce. Als je vlak voor verzending opnieuw verifieert en catch-alls apart behandelt, verdwijnen de meeste van deze gevallen.
Kan een tool voor e-mailverificatie spamtraps herkennen?
Maar gedeeltelijk. Verificatieleveranciers houden lijsten bij van adressen die volgens hen spamtraps zijn en markeren die. Niemand heeft een complete lijst, omdat de organisaties achter spamtraps ze met opzet geheimhouden. De betere bescherming zit in de herkomst van je data. Traps zitten vooral in gescrapete, gekochte of erg oude lijsten. Lijsten bouwen uit betrouwbare bronnen en oudere data opnieuw checken, helpt dus meer dan welke losse markering ook.
Als een dataprovider zegt dat de e-mailadressen geverifieerd zijn, moet ik ze dan nog zelf checken?
Ja. Het label geverifieerd van een provider beschrijft het adres op het moment dat de provider het voor het laatst heeft gecheckt, en dat kan weken of maanden zijn voordat jij de lijst downloadt. Het zegt ook zelden iets over de vraag of de persoon de functie nog heeft. Doe je eigen check als je de lijst bouwt en nog een keer voor de lancering. Dat kost weinig en vangt alles af wat er sinds de laatste ronde van de provider is veranderd.
Moet je contacten verifiëren die al in je CRM staan?
Ja, zeker voor een reactivatie- of win-backcampagne. Records die een jaar of langer in een CRM staan, zitten vol met mensen die van baan zijn gewisseld en bedrijven die van domein zijn veranderd. Verifieer de e-mailadressen opnieuw, ververs functietitels via enrichment en markeer vertrokken contacten in plaats van ze te verwijderen. De persoon die vertrok, kan nu namelijk ergens anders een koper zijn.
Hoe verifieer je een telefoonnummer voor een cold call?
Gebruik een dienst voor telefoonvalidatie of een enrichment-provider die laat zien of een nummer actief is en wat voor nummer het is, zoals mobiel, direct nummer of algemene receptie. Een actief mobiel of direct nummer is het bellen waard. Bij een receptie moet je eerst langs een gatekeeper. Nummers die als inactief gemarkeerd zijn, verwijder je, en nummers zonder resultaat zoek je opnieuw op voordat een rep er tijd aan besteedt.
Hoe nauwkeurig zijn tools voor e-mailverificatie?
Ze zijn betrouwbaar bij duidelijke gevallen, zoals een mailbox die bestaat of een domein dat niet bestaat. De nauwkeurigheid daalt bij catch-all-domeinen en bij servers die de check blokkeren of vertragen, en daar verschillen tools ook het meest van elkaar. Voordat je voor één leverancier kiest, haal je dezelfde steekproef van een paar honderd contacten door twee tools. Vergelijk dan hoe elke tool met de riskante en onbekende resultaten omgaat.
Deel dit bericht
Verification
Data
Begrippenlijst
Gerelateerde begrippen
De basis GTM-concepten begrijpen
Klaar om je pipeline te bouwen
