Zo controleert u een e-mailadres voordat u verzendt

Een e-mail die terugkomt als bounce vertelt u iets wat u vaak al vóór het verzenden had kunnen weten: dat het adres niet bestaat. Bij koude benadering, waar adressen afkomstig zijn van websites, bedrijvengidsen en visitekaartjes in plaats van aanmeldformulieren, is een deel van elke lijst verouderd.

Deze gids is voor iedereen die op het punt staat een lijst te mailen die niet via opt-in is opgebouwd – salesteams, oprichters, bureaus. Wij (Outreach) leggen de drie controles uit die vertellen of een adres e-mail kan ontvangen, waar die controles niet meer werken en hoe u de bouncecodes leest die u krijgt wanneer een bericht toch mislukt.

Het korte antwoord vooraf: u kunt meestal bevestigen dat een adres bestaat zonder er een e-mail naartoe te sturen, maar niet altijd – en weten wanneer u het niet kunt weten is net zo nuttig als het antwoord zelf.

Waarom zou u e-mailadressen controleren voordat u verzendt?

Omdat mailproviders afzenders vragen ongeldige adressen te verwijderen, en elke bounce een bericht is dat niemand heeft bereikt. De aanbevelingen van de Sender Hub van Yahoo zeggen: “Verwijder ongeldige ontvangers snel van uw lijst.” De richtlijnen voor e-mailafzenders van Google zeggen dat u “ontvangers van wie meerdere berichten zijn teruggekomen automatisch moet afmelden,” en: “Als berichten beginnen terug te komen of worden uitgesteld, verlaag dan het verzendvolume totdat het SMTP-foutpercentage afneemt.”

Kortom: providers letten op hoe u met slechte adressen omgaat. Controleren voordat u verzendt betekent minder bounces om achteraf af te handelen, en een scherper beeld van hoeveel echte mensen uw campagne heeft bereikt.

Wat zijn de stappen om een e-mailadres te controleren?

Drie controles, op volgorde: heeft het adres de juiste vorm, heeft het domein een mailserver en zegt die server dat de mailbox bestaat? Elke stap vangt problemen op die de vorige niet kan opvangen.

Een geslaagde stap 3 is het sterkste signaal dat u kunt krijgen zonder te verzenden. Maar zoals we zullen zien, geven sommige servers voor elk adres hetzelfde antwoord, echt of niet.

Hoe controleert u de syntaxis van een e-mailadres?

Controleer dat er precies één @ is, een geldig ogende naam ervoor en een echt domein erachter – binnen de lengtegrenzen van de SMTP-standaard. RFC 5321 stelt “de maximale totale lengte van een gebruikersnaam of ander lokaal deel” (het deel vóór het @) vast op 64 octetten, en de maximale lengte van een domein op 255 octetten.

Syntaxcontroles vangen het voor de hand liggende op: sales@@example.com, info@example, een spatie aan het eind die van een webpagina is gekopieerd, of een komma die in plaats van een punt is getypt. Ze zijn goedkoop en direct, dus voer ze altijd als eerste uit. Wat ze u niet kunnen vertellen, is of er iemand achter het adres zit. jane.doe@example.com heeft een perfecte vorm, of Jane daar nu werkt of niet.

Hoe werkt een MX-lookup?

Het vraagt aan de DNS welke server e-mail ontvangt voor het domein; als die er niet is, kan geen enkel adres bij dat domein e-mail ontvangen. Het MX-record (mail exchanger) wijst naar de server die e-mail voor een domein accepteert. Door het op te zoeken weet u of het domein überhaupt is ingesteld om e-mail te ontvangen.

Drie uitkomsten, volgens de standaarden:

• MX-records gevonden. Het domein heeft een mailserver – ga door naar stap 3.
• Het domein bestaat niet. RFC 5321 zegt: “Als een foutmelding voor een niet-bestaand domein wordt teruggegeven, MOET deze situatie als fout worden gemeld.” Het adres is dood.
• Geen MX-record, maar het domein bestaat. RFC 5321 zegt dat het adres “wordt behandeld alsof het met een impliciete MX is verbonden” – e-mail gaat naar het eigen adresrecord van het domein. Een ontbrekende MX is dus niet automatisch een doodlopende weg.

Er is ook een expliciet “we accepteren geen e-mail”-signaal. RFC 7505 definieert een “null MX” – een enkel MX-record met voorkeur 0 en een “.” als servernaam – dat “ervoor zorgt dat alle pogingen om e-mail naar een domein te bezorgen onmiddellijk mislukken.” Als u het ziet, stop dan: het domein heeft verklaard dat het geen e-mail ontvangt.

Hoe werkt een SMTP-mailboxcontrole zonder een e-mail te verzenden?

De checker maakt verbinding met de mailserver van het domein en start een bezorging, noemt de ontvanger, leest het antwoord van de server en verbreekt daarna de verbinding voordat er berichtinhoud wordt verzonden. In SMTP-termen: verbinden, EHLO, MAIL FROM, RCPT TO:<address>, de antwoordcode lezen en dan QUIT – de DATA-stap, waar het eigenlijke bericht zou komen, vindt nooit plaats.

Het antwoord op RCPT TO is wat telt. RFC 5321 definieert de codes:

Waarom vraagt u het de server niet gewoon rechtstreeks met de opdracht VRFY? Omdat servers die mogen uitschakelen. RFC 5321 sectie 7.3 staat toe dat sites VRFY om veiligheidsredenen uitschakelen, en zegt dat een server die dat doet “een 252-antwoord MOET teruggeven” – een antwoord dat noch ja noch nee betekent. Daarom gebruiken checkers in plaats daarvan de route via RCPT TO.

In onze eigen test in september 2026 herkende de RCPT-methode alle 6 adressen in een kleine bekende set correct: 3 adressen waarvan we wisten dat ze waren teruggekomen, 2 werkende adressen en 1 op een catch-all-domein dat we terecht als niet-bevestigbaar markeerden.

Wat is een catch-all-domein en waarom kan het niet worden geverifieerd?

Een catch-all-domein accepteert e-mail voor elk adres – echt of verzonnen – dus de server antwoordt “250 OK” voor elke ontvanger, en een controle vóór het verzenden leert niets. Sommige bedrijven stellen hun e-mail zo in dat verkeerd gespelde adressen toch iemand bereiken. Anderen gebruiken gateways die eerst alles accepteren en het achteraf uitsorteren.

U herkent een catch-all door de server te vragen naar een adres dat vrijwel zeker niet bestaat, zoals een lange willekeurige reeks tekens bij hetzelfde domein. Als de server dat ook accepteert, is elk “ja” van die server betekenisloos.

Hoe vaak komt het voor? In een test van september 2026 hebben wij (Outreach) RCPT-controles met verzonnen adressen verstuurd naar 25 maildomeinen die waren geselecteerd uit 200 bedrijfscontacten die we hadden verzameld (voornamelijk Koreaanse bedrijven). Ongeveer 74% van de domeinen antwoordde eerlijk en weigerde het nepadres; ongeveer 25% accepteerde het – dat waren catch-all-domeinen. Beschouw dat als één steekproef van één markt, niet als een algemeen percentage. Het punt is dat het niet zeldzaam is.

Voor catch-all-adressen is het eerlijke resultaat “kan niet worden geverifieerd.” Verzenden is de enige manier om het te weten, en dat is een afweging: een adres dat op de eigen website van het bedrijf staat, is een betere gok dan een adres dat is geraden op basis van een naampatroon.

Waarom weigeren sommige mailservers verificatiecontroles?

Sommige mailservers beperken wie naar ontvangers mag vragen, dus in plaats van te antwoorden vertragen ze, weigeren ze tijdelijk of verbreken ze de verbinding. Weigeringen zien er meestal zo uit:

• Een tijdelijk 4xx-antwoord voor elke ontvanger, met het verzoek het later opnieuw te proberen.
• Een 5xx-antwoord dat verwijst naar beleid of reputatie in plaats van naar de mailbox – bijvoorbeeld een uitgebreide code 5.7.1, die RFC 3463 omschrijft als “Bezorging niet geautoriseerd, bericht geweigerd.”
• Helemaal geen antwoord, of een verbinding die wordt verbroken.

Geen van deze signalen vertelt u of de mailbox bestaat. Een goede verificatietool meldt ze als “onbekend,” niet als “ongeldig” – een echt adres als dood markeren omdat de server voorzichtig was, zou een goed contact weggooien.

Sommige hostingproviders blokkeren ook uitgaande verbindingen op poort 25, de SMTP-poort, wat betekent dat een checker die daar draait helemaal geen mailservers kan bereiken. Ook dan is het juiste antwoord “kan niet verifiëren,” niet “bestaat niet.”

Hoe leest u bouncecodes na het verzenden?

Kijk naar het eerste cijfer van de uitgebreide statuscode: 5 betekent permanent, 4 betekent tijdelijk. Het middelste cijfer vertelt vervolgens wat voor soort probleem het is. RFC 3463 definieert codes in de vorm class.subject.detail:

• 5.x.x – Permanente fout: “waarschijnlijk niet op te lossen door het bericht in de huidige vorm opnieuw te verzenden.”
• 4.x.x – Aanhoudende tijdelijke fout: “verzenden in de toekomst kan succesvol zijn.”

De codes die u het vaakst ziet wanneer het adres het probleem is:

Die laatste rij is belangrijk. Een 5.7.x-code betekent meestal dat de ontvangende server u heeft geweigerd, niet dat de mailbox ontbreekt. Controleer uw SPF-, DKIM- en DMARC-instellingen voordat u het contact verwijdert.

Hoe controleert u gratis één enkel adres?

Voer het in onze gratis checker voor e-mailadressen in; die voert de controles op syntaxis, MX en mailbox uit en vertelt u een van drie dingen. Aanmelden is niet nodig. De checker is beschikbaar in het Engels en Koreaans; voer het adres in dat u wilt controleren. Het resultaat is een van deze:

• Dit adres kan e-mail ontvangen – de mailserver heeft de ontvanger geaccepteerd.
• Dit adres bestaat niet – het adres heeft niet de juiste vorm, het domein heeft geen mailserver of de server zei dat zo'n mailbox niet bestaat.
• Dit kunnen we niet verifiëren – het domein is catch-all, de server weigerde de controle of er was geen controle mogelijk. De tool vertelt u welke reden van toepassing was.

Om te voorkomen dat de tool voor massale controles wordt gebruikt, staat hij een beperkt aantal controles per dag toe. Voor een hele lijst verifieert u binnen uw verzendproces in plaats van één adres tegelijk.

Wat moet u doen met adressen die niet kunnen worden geverifieerd?

Houd ze apart, verzend naar deze adressen in kleinere partijen en verwijder elk adres dat terugkomt met een 5.x.x-code. Een praktische volgorde:

1. Laat alles vallen wat de syntaxiscontrole niet doorstaat of geen mailserver heeft.
2. Verwijder adressen waarvan de server zei dat ze niet bestaan.
3. Verzend eerst naar bevestigde adressen.
4. Verzend voorzichtiger naar adressen met de uitkomst “Dit kunnen we niet verifiëren”, en verwijder elk adres dat terugkomt met een permanente bounce – zoals Yahoo en Google beide adviseren.

Bedenk ook dat een geldig adres niet betekent dat de ontvanger bereid is. Spamklachten tellen tegen u mee, of het adres nu bestaat of niet; de cijfers behandelen we in waarom koude e-mails in de spam belanden.

De korte versie

• Controleer in drie stappen: syntaxis → MX-lookup → SMTP-mailboxcontrole (RCPT, zonder inhoud te verzenden).
• Het deel vóór het @ mag maximaal 64 tekens lang zijn (RFC 5321); een null MX betekent dat het domein geen e-mail accepteert (RFC 7505).
• Catch-all-domeinen accepteren elk adres – in onze test met 25 domeinen deed ongeveer 25% dat – dus sommige adressen kunnen alleen de uitkomst “Dit kunnen we niet verifiëren” krijgen.
• Bij bounces is 5.x.x permanent en 4.x.x tijdelijk; 5.1.1 betekent dat de mailbox niet bestaat; 5.7.x wijst op een beleidsprobleem, niet op een slecht adres.
• Probeer een enkel adres met onze gratis checker voor e-mailadressen.