I opened cmd and typed ping gmail.com. It shows me:

C:\Windows\system32>ping gmail.com

Pinging gmail.com [] 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 email@gmail.com 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 http://mail.google.com/support/bin/answer.py?answer=7720 [ (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 gmail.com part with

Ben N
  • 40,045
  • 17
  • 140
  • 181
  • 26,733
  • 82
  • 197
  • 273

7 Answers7


Because isn't the MX (mail exchange) for gmail.com.

If you ping gmail.com, 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 gmail.com as grawity mentioned in the comments) to see those DNS records:

Probe:~ trurl$ dig -t ANY gmail.com

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

;gmail.com.         IN  ANY

gmail.com.      3519    IN  MX  30 alt3.gmail-smtp-in.l.google.com.
gmail.com.      3519    IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.      74086   IN  NS  ns4.google.com.
gmail.com.      3519    IN  MX  10 alt1.gmail-smtp-in.l.google.com.
gmail.com.      74086   IN  NS  ns3.google.com.
gmail.com.      3   IN  A
gmail.com.      3519    IN  MX  40 alt4.gmail-smtp-in.l.google.com.
gmail.com.      3   IN  A
gmail.com.      3   IN  A
gmail.com.      74086   IN  NS  ns1.google.com.
gmail.com.      3   IN  A
gmail.com.      3519    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
gmail.com.      74086   IN  NS  ns2.google.com.

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

And if you proceed further, you'll see that gmail-smtp-in.l.google.com (the first mx in the list above) points to a different IP address:

;gmail-smtp-in.l.google.com.    IN  ANY

gmail-smtp-in.l.google.com. 42  IN  A

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 http://mail.google.com/support/bin/answer.py?answer=6596 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 gmail.com, google.com, picasa.com (etc., etc...), so there's no way to distinguish the user.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
  • 2,172
  • 1
  • 13
  • 16

When you send email to user@domain.com, 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 gmail.com resolves to the following set of servers:


which produce completely different ping results:

$ ping gmail-smtp-in.l.google.com.
PING gmail-smtp-in.l.google.com ( 56(84) bytes of data.
64 bytes from wy-in-f27.1e100.net ( 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.


Try to use:

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
  • 3,025
  • 1
  • 18
  • 19
7 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.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
Sandeep Bansal
  • 6,354
  • 1
  • 29
  • 34
  • 1
    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 gmail.com ? – Pacerier Jul 06 '11 at 11:41
  • 2
    @Pacerier, web servers will display different pages depending on which domain name you use to access them. For instance, I administer iconsf.org and iconsfinc.com. 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 iconsf.org. – CarlF Jul 06 '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 @thedomain.com, 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.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
  • 25,519
  • 5
  • 48
  • 72
  • 2
    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.](http://exim.org./exim-html-3.30/doc/html/spec_11.html#SEC254) [So does qmail.](http://qmail.org./qmail-manual-html/man8/qmail-smtpd.html) – JdeBP Jul 06 '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 06 '11 at 13:17
  • 1
    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.](http://caida.org./publications/papers/2008/root_internet/root_internet.pdf) 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 06 '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 06 '11 at 13:50

The issue is what an email address actually is.

In many protocols schemes, the address syntax xxx@example.com means just "connect to Internet host example.com and specify (for the relevant protocol) user xxx". SSH, FTP, SCP and other follow this pattern: example.com 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 xxx@example.com 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 example.com (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 xxx@example.com" (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.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
  • 655
  • 1
  • 6
  • 18

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 @gmail.com, discarding or rejecting all other addresses[1].

Gmail's mail server IP address is But the address tyler@gmail.com is not the same thing as tyler@ Gmail would say "I know who tyler@gmail.com 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.

  • 2,155
  • 1
  • 15
  • 21