golang & postfix - email received header is localhost - email

Question

While trying to setup postfix to allow a website to sent password reset emails I've noticed that when sending emails form the command line using
echo "body" | mail -s "subject" test#example.com
the emails arrive just fine and are not marked as spam. However, when sending from withing the sites server, the header is set as being received from localhost and thus is marked as spam.
Received: from example.com (localhost [127.0.0.1])
by example.com (Postfix) with ESMTPS id CE1299C435
for <my_email#gmail.com>; Tue, 2 Aug 2016 05:28:41 +0000 (UTC)
As a note, dkim, spf and dmarc test all list as passed, so they are not the problem.
I have also tried sending an email with the same content using the above echo method and had it arrive fine (although plaintext as I used it as above and didn't add the content type headers).
Initially this was sent using smtp.SendMail
err := smtp.SendMail(hostname + ":25", nil, sender, recipients, []byte(msgstr))
which provides no way to set sending host, so in an attempt to correct this I switched to using a manual dial, sending a HELO message, then starting tls (attempting to start tls before the HELO resulted in a panic saying the HELO had to be the first call)
c, err := smtp.Dial(host + ":25")
if err != nil {
log.Panic(err)
}
if err = c.Hello(host); err != nil {
log.Panic(err)
}
if err = c.StartTLS(config.TLS()); err != nil {
log.Panic(err)
}
This still sends the email successfully, but as before the received header still shows localhost as the origin, I feel I've misunderstood something as I believed that HELO served to identify where the call was coming from.
Your advice and help is appreciated, this is the first time I've tried to configure an MTA and use it like this, there has been a bit of a learning curve that I'm evidently not over yet.

Answer 1

As Juergen Gmeiner suggested in the comments, my problem ended up being caused by a poorly configured /etc/hosts file, such that it wasn't effecting other services.
The existing entry was:
127.0.0.1 localhost example.com
Changing this to:
127.0.0.1 example.com localhost
solved the problem while not breaking the existing services that needed localhost to evaluate properly.
This solution worked for my locally hosted server process, if the same problem occurs with a remote server, and equivalent like would need to be created with the ip and hostname of the remote. i.e.
<remote ip> <hostname>
note: while I tested that this last part by calling from my local development build to our production server and it worked, its not a 100% tested solution.
Thank you all for your help, and I hope that this mistake on my part helps anyone else who makes a similar error in the future.