Why Your IP Can Appear in Email Headers Despite a Proxy
Identify which mail hop or header recorded an address before treating an IP inside a delivered email as the network peer of a proxied connection.
An IP address inside a delivered email is application data. It is not automatically the source address that the destination saw for the connection you sent through a proxy.
SMTP servers add Received fields as a message moves through the delivery chain. RFC 5321 says the receiving server should include the source IP determined from its TCP connection, and later SMTP relays prepend their own trace fields while retaining the existing ones.
If the mail client’s SMTP connection actually goes through SOCKS, the first receiving server sees the SOCKS server as that TCP peer. That does not erase an address already written into the message, or an address recorded on a different, earlier submission path.
Start with the exact field containing the address and identify the system that added it. A Received line from an earlier mail hop, a provider-specific originating-address field, and the current receiving server’s peer are different observations. Evaluate the trace added by systems you trust; arbitrary text in a message can also claim an address.
Then identify the connection that was proxied. A browser configured for a web proxy does not establish that a separate desktop mail client’s SMTP submission used it. Webmail also has a browser-to-provider connection followed by the provider’s mail-delivery path.
A SOCKS relay carries the application stream. It does not automatically edit the email’s headers or define the mail provider’s metadata policy. Diagnose those two layers separately before changing proxy protocols.