Whether you write in-house documentation, software documentation for wide distribution, security or system administration articles for TR, or just satire, you may find yourself making up an email address on the spot. Unfortunately, sometimes people actually use our example addresses, and sometimes those examples aren't as unique as we might think.
Email address harvesting bots and Web spiders, pranksters, people who misunderstand your satire and are maybe a little stalkerish in their devotion to you, and even people honestly just trying to follow the directions of your otherwise excellently written documentation or howto may pick up an example address in what you write. If that address happens to correspond with an email address used by a real, live human being, the person could conceivably receive spam, hate mail, or confusing test emails as a result of your poor choice in example email address. There have even been cases of people following directions in a howto and accidentally sending confidential information to someone that actually uses the example email from the howto.
It is specifically to address this sort of problem that RFC 2606 was published by the IETF. Of particular interest when dealing with email examples is Section 3, which addresses the use of second-level domain names with existing, real-world top-level domains in examples. The three second-level domain names have been reserved by the IANA for use as example domains are:
When presenting example email addresses, or any example domain names, these are generally your best options. There are also reserved example TLDs specified in RFC 2062, if you need them.
Section 5 of RFC 2062, Security Considerations, has this to say:
Confusion and conflict can be caused by the use of a current or future top level domain name in experimentation or testing, as an example in documentation, to indicate invalid names, or as a synonym for the loop back address. Test and experimental software can escape and end up being run against the global operational DNS. Even examples used "only" in documentation can end up being coded and released or cause conflicts due to later real use and the possible acquisition of intellectual property rights in such "example" names.
The reservation of several top level domain names for these purposes will minimize such confusion and conflict.
Don't let a poor choice of example email address, or other use of an example domain name, become a security issue for anyone. Make it your policy to use the example domains specified in RFC 2606.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.