It depends, most email relays and mail servers will add headers with the sender's IP. Yet nothing forces them to add the correct IP. A typical email exchange would happen as:
email client -> your mail server -> destination mail server -> addressee's client
Yet, it can pretty well go:
email client -> local mail server -> remote mail server ->
-> destination domain relay -> destination mail server -> addressee's client
Or an even more complex design. SMTP (and its extensions) is pretty robust in terms to proxying/relaying. And although this is not a requirement of SMTP most relays and mail servers simply keep all headers that are currently in the mail and just add their own on top.
This has a couple of interesting side effects, for example it isn't uncommon to find mail with several Received:
headers.
Let's look at a couple of header examples in a rather complex mail path: The following is from a mail that uses google as a the mail server but has its own domain (i.e. the MX
record for the mail domain is mail.google.com
), the email then passes through a relay and then back to mail.google.com
to a different gmail address.
First of all we get:
X-Received: by 10.x.x.x with SMTP id d27mr24214681oib.59.1473677977339;
Mon, 12 Sep 2016 03:59:37 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with
HTTPREST; Mon, 12 Sep 2016 06:59:36 -0400
This is from the client to gmail, note that the IP that google saw is there. Next it goes to the relay:
Received: from mail-it0-f41.google.com ([209.x.x.x]:37883)
by mail.fsf.org with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.69)
(envelope-from <******@hotelquickly.com>)
id 1bjix0-0003Rs-3K
for ******@member.fsf.org; Tue, 13 Sep 2016 04:20:18 -0400
Received: by mail-it0-f41.google.com with SMTP id 183so31757158itf.0
for <****@member.fsf.org>; Tue, 13 Sep 2016 01:20:17 -0700 (PDT)
So we have one of google's mail server's IP talking to the relay at mail.fsf.org
And finally back to google:
Received: from mail.fsf.org (mail.fsf.org. [208.x.x.x])
by mx.google.com with ESMTPS id n48sd14225674qtn.126.2016.09.13.01.20.23
for <******@gmail.com>
(version=TLS1 cipher=AES128-SHA bits=128/128);
Tue, 13 Sep 2016 01:20:23 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning ******@hotelquickly.com does not designate 208.x.x.x
as permitted sender) client-ip=208.x.x.x;
Authentication-Results: mx.google.com;
dkim=pass header.i=@hotelquickly.com;
spf=softfail (google.com: domain of transitioning ******@hotelquickly.com does not designate
208.x.x.x as permitted sender) smtp.mailfrom=******@hotelquickly.com;
dmarc=pass (p=NONE dis=NONE) header.from=hotelquickly.com
Received: from Debian-exim by mail.fsf.org with spam-scanned (Exim 4.69)
(envelope-from <******@hotelquickly.com>)
id 1bjix0-0003Rx-7z
for ******@member.fsf.org; Tue, 13 Sep 2016 04:20:22 -0400
And there is even more because I use procmail
but by then it deals with local IPs only.
In summary
Most machines will add the IPs of the machines they received mail from to mail headers, yet there is nothing forcing the machine to add the correct IPs. If you run your own mail server you can add misguiding IP addresses, yet the next hop in the mail path will add the IP it believes your mail server has to the headers (i.e. the mail server it received the mail from).