Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I opened cmd and typed ping It shows me:


Pinging [] with 32 bytes of data:
Reply from bytes=32 time=6ms TTL=56
Reply from bytes=32 time=6ms TTL=56
Reply from bytes=32 time=6ms TTL=56
Reply from bytes=32 time=215ms TTL=56

Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 215ms, Average = 58ms


I have a Gmail account, so I emailed myself but instead of I used email@


This is an automatically generated Delivery Status Notification



Delivery to the following recipient has been delayed:


Message will be retried for 2 more day(s)

Technical details of temporary failure: The recipient server did not accept our requests to connect. Learn more at [ (1): Connection refused]

----- Original message -----

MIME-Version: 1.0 Received: by with SMTP id w4mr3261626fam.44.1309944998035; Wed, 06 Jul 2011 02:36:38 -0700 (PDT) Received: by with HTTP; Wed, 6 Jul 2011 02:36:37 -0700 (PDT) Date: Wed, 6 Jul 2011 17:36:37 +0800 Message-ID: Subject: test From: Joseph To: xxxxxx@ Content-Type: multipart/alternative; boundary=20cf3054a49348815504a763560c


I did not receive the email. Why?

Why can't I just substitute the part with

share|improve this question
up vote 150 down vote accepted

Because isn't the MX (mail exchange) for

If you ping, ping uses the A record to perform its task, but sending emails (often) incorporates other servers.

You can use the tool dig (on Windows: nslookup -q=mx as grawity mentioned in the comments) to see those DNS records:

Probe:~ trurl$ dig -t ANY

; <<>> DiG 9.6.0-APPLE-P2 <<>> -t ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65087
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 9

;         IN  ANY

;; ANSWER SECTION:      3519    IN  MX  30      3519    IN  MX  5      74086   IN  NS      3519    IN  MX  10      74086   IN  NS      3   IN  A      3519    IN  MX  40      3   IN  A      3   IN  A      74086   IN  NS      3   IN  A      3519    IN  MX  20      74086   IN  NS

As you can see, there are even multiple servers handling email for and each of those have different priorities (the number in the last column).

And if you proceed further, you'll see that (the first mx in the list above) points to a different IP address:

;    IN  ANY


So you'd have to use recipient@[] (this is the right syntax as JdeBP mentioned in the comments).

BUT Google won't accept these mails:

Jul  6 13:25:15 lofi postfix/smtp[31213]: C6FXXXXXXX: to=<REMOVED@[]>,
relay=[]:25, delay=3.4, delays=0.16/0.01/0.15/3.1, dsn=5.1.1,
status=bounced(host[] said:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 REMOVEDg.99
(in reply to RCPT TO command))

Thinking further about this: Google won't or can't accept these mails because they don't know to whom you like to send it. The server behind could handle emails for,, (etc., etc...), so there's no way to distinguish the user.

share|improve this answer
You forgot to mention that email@ would be the wrong syntax anyway, per RFC 5322 § 3.4.1. – JdeBP Jul 6 '11 at 12:40
Relevant RFC section. – Humphrey Bogart Jul 6 '11 at 13:51
nslookup will give similar information on Windows machines. – MikeJ-UK Jul 6 '11 at 14:16
nslookup -q=mx to be precise. – grawity Jul 6 '11 at 21:42

When you send email to, the outgoing mail server uses the DNS MX record of the destination domain to determine which IP address is responsible for handling mail at that domain. This may not be the same IP address returned during a normal ping.

Using the 'dig' tool on Linux I can determine that the MX record for resolves to the following set of servers:

which produce completely different ping results:

$ ping
PING ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=50 time=12.8 ms

Whether you can actually send email directly to that IP address likely depends on your email client and mail server, and you may need to put the address in square brackets as per slotishtype's answer.

share|improve this answer

Try to use:

share|improve this answer
This might not work, as the guys analysis illustrates but maybe worth a try. – slotishtype Jul 6 '11 at 11:22
The address "xxxxx@[]" in the "To" field was not recognized. Please make sure that all addresses are properly formed. – Pacerier Jul 6 '11 at 11:38
I know, that is a gmail specific setting. You can send it from a different mail client but it may not send. – slotishtype Jul 6 '11 at 11:39
btw i'm curious what's the reason that made you think that that would work? – Pacerier Jul 6 '11 at 11:43
@[ip] is a special syntax in the RFC that is defined as bypassing MX lookup. – Random832 Jul 6 '11 at 13:15 is not a Gmail gateway. If you go direct yourself to the IP address in your browser it won't go to the Gmail website; it'll go to Google, so that could be one point.

share|improve this answer
so what's the gmail gateway? to rephrase, what numbers must i type in the browser to get the page that i usually see at ? – Pacerier Jul 6 '11 at 11:41
@Pacerier, web servers will display different pages depending on which domain name you use to access them. For instance, I administer and They're on the same server at the same IP address, but what web page you see depends on which name you type. If you just use the IP address you will always see – CarlF Jul 6 '11 at 12:24

First, that IP address itself is not going to be listed as a DNS MX record (even if you used the mail server's correct IP address), as the others said, so it is not going to find the server in the first place (it is also not going to route based on that IP address as the @thedomain is just used for lookups). Even if you used telnet to connect to the server directly (this is how experts test email directly), it would still fail for the following reason:

Whenever I configure a mail system, and I do a lot of them, with Microsoft Exchange or others, you always have to tell it what are the domains it will accept. I always enter, which means it will only accept emails for that domain. Since @ is not a domain, and certainly not in the accepted domains list, even if you were directly connected to the mail server, it will still reject it.

share|improve this answer
Actually, is a domain (per RFC 5322 § 3.4.1 it's not the syntax of an IP address in an addr-spec). It's a nonexistent domain, but it is a domain, much to the annoyance of several content DNS server operators. Note also that several MTSes will automatically accept mail addressed to their SMTP Relay servers' IP addresses (in the syntactically correct manner). Older versions of exim did this. So does qmail. – JdeBP Jul 6 '11 at 13:10
@JdeBP I am not an expert on that RFC, and when I looked at it, by head wanted to explode, but shouldn't it have a .com or .net to actually be a domain? In any case, for all practical purposes, it is not a domain, and certainly is not in the given question. – KCotreau Jul 6 '11 at 13:17
That's part of the problem: It is a domain in the question, especially for practical purposes. It's just that the questioner is like you, and doesn't realize that. In an addr-spec the sequence of characters is a domain, with the labels 55, 235, 125, and 74 in descending order from the root. In 2008, Duane Wessels et al. put such nonexistent domain names as causing some 3.8% of the queries at ICANN's "K" root content DNS server. It's now time for you to read RFC 4697 § 2.9. ☺ – JdeBP Jul 6 '11 at 13:38
I should have said "resolvable" domain in my first comment. Yes, it is trying to be resolved, but without the .com, etc. it will always fail. – KCotreau Jul 6 '11 at 13:50

The issue is what an email address actually is.

In many protocols schemes, the address syntax means just "connect to Internet host and specify (for the relevant protocol) user xxx". SSH, FTP, SCP and other follow this pattern: is just a fancy name for an IP address (which is resolved the same as when doing a ping). For emails, it's different. The full string is here an email address, the domain is part of the address, is not just the server to which a connect to send it; this server is called the "relay", and it is obtained, from that host part, by a special DNS request (MX records) as explained in other answers, but, bear in mind:

  1. it might coincide or not with the "normal" IP address for (A record). frequently they are different.

  2. once the client discover the relay and connects to it, it still must tell the full mail address "I want to send a mail to" (the same relay can process mails for different domains).

BTW, the second point (but not the first) also applies to HTTP, since 1.1: the domain is used to resolve the host IP address, but it's also used for specifying the resource.

share|improve this answer

Remember that destination mail servers look at the whole address, including the name that follows the @ sign. The Gmail mail servers will only route messages that end in, discarding or rejecting all other addresses[1].

Gmail's mail server IP address is But the address is not the same thing as tyler@ Gmail would say "I know who is, but I've never heard of the name tyler@", and decide that it couldn't deliver to the second address.

[1] Yes, I know that's not exactly true, and yes, I know about Google Apps.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .