So I've wondered this for a long time.

Where does email sent to *@example.com go? If I accidentally sent sensitive information to *@example.com would some evil person (potentially at the IANA) be able to retrieve it someday?

  • 2
    If you're running Postfix as your SMTP server you can use discard (postfix.org/discard.8.html) to throw away emails to RFC 2606 domains (rather than a bounce).
    – HTTP500
    Nov 22, 2011 at 3:17
  • 9
    Can someone explain why this was migrated here and then closed? I started the question on Stack Overflow since I thought it was a more general issue, but I guess it makes sense that it should be on here related to email and networking. But obviously some experienced people disagreed. How and where can I get this question reopened? Nov 22, 2011 at 19:28
  • If its off topic here I'm sure it would be fine at pro webmasters. Nov 23, 2011 at 3:22
  • This is probably best fit for Super User.
    – MDMarra
    Nov 23, 2011 at 11:51
  • 1
    If you visit example.com, it says it's reserved for illustrative purposes & links to iana.org/domains/reserved
    – user
    Jun 7, 2014 at 18:33

4 Answers 4


If you attempt to send an email to *@example.com

  1. Your SMTP will check the domain exists.
  2. Your SMTP server will lookup for a MX record at example.com.
  3. There is none: Your SMTP will fall back on the A record. The IP is (as of today)
  4. The IANA has registered the domain, but has not set up a SMTP server listening on port 25 on
  5. Then the behaviour depends on your SMTP. Most servers will send you a warning, and try again later. Eventually (usually in 3 days), the SMTP will discard the message and send you a notification of failure.

Bottom line: It depends on your own configuration. But if IANA set up a server today, they might be able to receive messages you tried to send 3 days ago.


If there's no MX record, mail servers will attempt deliver to the A record.

example.com's servers don't listen on port 25, so the mail server won't establish a TCP connection and won't even begin delivery.


example.com has no MX record, so your SMTP server on the sending domain should bounce the message if configured as most SMTP servers are.

EDIT: for clarity to those who find this answer in the future, here is an explanation of what an MX record is: (from http://en.wikipedia.org/wiki/Mx_record retrieved November 21, 2011)

A mail exchanger record (MX record) is a type of resource record in the Domain Name System that specifies a mail server responsible for accepting email messages on behalf of a recipient's domain and a preference value used to prioritize mail delivery if multiple mail servers are available. The set of MX records of a domain name specifies how email should be routed with the Simple Mail Transfer Protocol.

So, basically, example.com, example.net, and example.org have no server appointed to handle incoming mail, and therefore any mail sent to them should be returned to the sender as "undeliverable" (may vary based on SMTP server configuration, but returning to sender as "undeliverable" is a very common behaviour for this situation).

EDIT 2: Someone brought up the RFC 5321 defined behaviour of falling back to using the A record in the case of a missing MX record. I searched this RFC ( https://www.rfc-editor.org/rfc/rfc5321 ) and found no such thing, but it's possible that some MTAs (Mail Transfer Agent, such as exim, postfix, sendmail, and Microsoft Exchange Server, among others) may try to deliver mail via SMTP to the address defined in the A record. For posterity, here is what happens when you attempt to establish an SMTP connection to the defined A record address for example.com ( at time of writing):

$ telnet 25
telnet: Unable to connect to remote host: Connection timed out

EDIT 3: see replies below for clarifications on relevant RFCs and fallback behaviour.

  • 18
    Your answer is incorrect -- RFC 5321 does specify that resolution falls back to A records when no MX record exists (the "implicit MX rule"); see section 5.1. If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
    – josh3736
    Nov 22, 2011 at 4:50
  • 1
    Also, SMTP has always had a fallback to A rule -- it wasn't introduced with 5321.
    – josh3736
    Nov 22, 2011 at 4:59
  • 2
    From RFC 974 (973 & 974 introduced the MX record) It is possible that the list of MXs in the response to the query will be empty. This is a special case. If the list is empty, mailers should treat it as if it contained one RR, an MX RR with a preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its only MX).
    – Chris S
    Nov 22, 2011 at 14:47
  • 3
    @josh3736 SMTP never specified that it fell back from MD & MF records to A RRs. In fact, RFC 821 makes no mention of how exactly to use the HOSTS file (DNS didn't exist at the time) to lookup the remote server. You are however correct that MX are required to fall back to A records, per RFC 974. This was codified because it was a common practice already, the MD and MF records being overly complicated and commonly unused.
    – Chris S
    Nov 22, 2011 at 14:53
  • Thank you all for your clarifications -- I learned quite a bit from this.
    – seanp2k
    Nov 22, 2011 at 20:40

According to the Internet Assigned Number Authority's IANA-managed Reserved Domains:

Example domains

As described in RFC 2606 and RFC 6761, a number of domains such as example.com and example.org are maintained for documentation purposes. These domains may be used as illustrative examples in documents without prior coordination with us. They are not available for registration or transfer.

  • 18
    Your answer is not responsive to the question.
    – George
    Nov 22, 2011 at 6:38
  • 8
    @George Why not? IANA owns the domains so even if there's no MX as of today, IANA may set up one in the future and start receiving emails for example.* domains. This is the best answer in my opinion. Nov 22, 2011 at 8:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.