E-mail Generator - Fictieve e-mailadressen genereren voor developers
Genereer realistische fictieve e-mailadressen voor software testing, formulier validatie en test automation. Bulk generatie met directe export naar Excel, CSV en JSON. Geen echte mailboxen — puur testdata.
Let op:alle gegenereerde gegevens zijn volledig fictief en mogen niet worden gebruikt als echte persoonsgegevens.
Waarom fictieve e-mailadressen gebruiken voor testen?
Het gebruik van echte e-mailadressen in test- en ontwikkelomgevingen brengt serieuze risico's met zich mee. Testmails kunnen onbedoeld bij echte gebruikers terechtkomen, wat leidt tot verwarring, spamklachten of zelfs datalekken. Fictieve e-mailadressen voorkomen deze problemen volledig.
RFC 2606 gereserveerde domeinen
De Internet Engineering Task Force (IETF) heeft in RFC 2606 een aantal domeinen gereserveerd die specifiek bedoeld zijn voor documentatie en testdoeleinden. De bekendste zijn example.com, example.org en example.net. E-mail verstuurd naar deze domeinen wordt nooit afgeleverd, waardoor ze veilig zijn voor gebruik in testomgevingen.
Veelvoorkomende use cases
- Formulier validatie— Test of e-mailvelden correct worden gevalideerd op formaat en verplichte invoer.
- API testing— Gebruik fictieve adressen bij het testen van registratie-endpoints en gebruikersbeheer API's.
- Load testing— Genereer duizenden unieke e-mailadressen voor performance tests zonder risico op echte mailaflevering.
- Demo omgevingen— Vul demo-accounts met realistische maar fictieve contactgegevens voor klantpresentaties.
Combineer gegenereerde e-mailadressen met een fictieve naam voor realistische testprofielen, of gebruik de dataset generator om complete testrecords te genereren inclusief e-mail, BSN, IBAN en meer.
Voorbeeld e-mailadressen voor testdoeleinden
Hieronder een set fictieve e-mailadressen op RFC 2606-gereserveerde domeinen. Deze kun je direct in je testomgeving plakken zonder risico op echte mailaflevering:
| E-mailadres | Testscenario |
|---|---|
jan.vandijk@example.com | Formulier-validatie met realistische Nederlandse naam |
test+tag@example.org | Plus-addressing / sub-adressering test |
noreply@example.net | Systeem-e-mails en transactional notifications |
tester-123@test.example | Subdomein en cijfer/koppelteken in local-part |
info.nl@example.com | Landspecifieke test met punt in local-part |
RFC 2606 en RFC 6761 garanderen gezamenlijk dat deze domeinen (example.com, example.org, example.net, .test, .example) nooit aan een echte eigenaar worden toegewezen en dus nooit echte e-mail ontvangen.
E-mailvalidatie in software
E-mailvalidatie is berucht lastig: de officiële RFC 5322-grammatica is dermate complex dat een volledige parser honderden regels code kost. In de praktijk kiezen de meeste systemen voor een pragmatische regex zoals ^[^@\s]+@[^@\s]+\.[^@\s]+$, eventueel aangevuld met een DNS MX-lookup voor domein-validatie.
Veelvoorkomende edge cases
- Plus-addressing —
user+tag@domain.comis geldig, maar sommige regexes wijzen het ten onrechte af. - IDN / Unicode — domeinen als
bedrijf.みんなof een local-part met niet-ASCII tekens (EAI, RFC 6531) vereisen Punycode-ondersteuning. - Quoted local-part — technisch geldig:
"hello world"@example.com, maar in de praktijk vrijwel altijd afgewezen. - Lengte-limieten — local-part max 64, domain max 255, totaal 254 octetten.
Een pragmatisch alternatief voor echte validatie: stuur een verification-mail naar een fictief @example.com adres — die landt gegarandeerd bij niemand, dus je kunt bounce-handling en queue-logica testen zonder spam-risico. Voor realistische testprofielen combineer je e-mailadressen met een fictieve naam of vul je complete records via de dataset generator.