I'm trying to hide the client IP from emails sent from postfix.

here is an example of what I mean:

Received: from mail.[removed].com (adsl-75-37-61-254.dsl.frs2ca.sbcglobal.net [])
    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by mail.[removed].com (Postfix) with ESMTP id D50C7BF185DD
    for <[removed]@gmail.com>; Thu,  2 Aug 2012 16:14:21 +0900 (JST)
Date: Thu, 02 Aug 2012 07:14:08 +0000

Notice this line (adsl-75-37-61-254.dsl.frs2ca.sbcglobal.net [])

I want to remove that line from the email.

I've tried doing this:

/etc/postfix/main.cf :

smtp_header_checks = regexp:/etc/postfix/smtp_header_checks

smtp_header_checks :

/^((.*) [(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])])/    IGNORE

But my IP address is still inside of the received part of the email. If I send email off the smtp server locally the IP address becomes localhost.localdomain []

How can I remove client IPs from the header?

5 Answers 5


In main.cf:

smtp_header_checks = pcre:/etc/postfix/smtp_header_checks

In dynamicmaps.cf:

# Use your real path to dict_pcre.so, below
pcre    /usr/lib/postfix/dict_pcre.so           dict_pcre_open

You should put this in your /etc/postfix/smtp_header_checks:

/^Received: .*/     IGNORE
/^X-Originating-IP:/    IGNORE

Then run

# /etc/init.d/postfix reload
  • My ip address is still displayed. I appreciate the efforts.
    – Kyle
    Aug 2, 2012 at 7:43
  • It is not necessary to have postfix-pcre. Regexp works the same way.
    – Kyle
    Aug 2, 2012 at 7:45
  • Alright. I have made sure pcre was install on the system. I have changed regexp:/etc/postfix/smtp_header_checks to pcre:/.... I have then restarted postfix and monitored maillog for any errors. No errors were displayed. The email still displays my ip. XD Thanks for the efforts, Mike.
    – Kyle
    Aug 2, 2012 at 7:51
  • Hmm... I get an error but I found this irbs.net/internet/postfix/0404/1097.html I tested the regex with this postfix.org/pcre_table.5.html using argument: postmap -q "Received: from mail.[removed].com (adsl-75-37-61-254.dsl.frs2ca.sbcglobal.net [])" pcre:/etc/postfix/smtp_header_checks and the output was IGNORE so it is working. However it is not making changes in the email... Is the field inside main.cf wrong?
    – Kyle
    Aug 2, 2012 at 7:57
  • 1
    Shit man. I just wasted your time. It's my fault in the very beginning. smtp_header_checks was supposed to be header_checks... It works now. I'm so sorry I wasted your time. I appreciate your efforts. Thank you. pcre also works too. I'm on centos. Thanks again, bro.
    – Kyle
    Aug 2, 2012 at 8:03

To remove the sender IP from the Received header for new mail submissions, use the header_checks key instead of the smtp_header_checks option:

header_checks = regexp:/etc/postfix/header_checks_submission

The smtp_header_checks option only applies to mail that is sent from Postfix to external servers whereas the header_checks option applies to incoming mail sent from your client to Postfix.

See also the How Postfix receives mail at http://www.postfix.org/OVERVIEW.html for an overview of the components, mail goes from smtpd -> cleanup -> incoming queue. The smtpd process receives mail and injects the Received header with the sender IP address. The header_checks(5) option is processed by the cleanup(8) component which sanitizes email headers.

It is not recommended to set such a header_checks option globally in your main.cf as this would modify the Received header in all emails, even those received from external servers. Instead, you should configure your client to send email through a dedicated submission service on port 587, and configure Postfix to rewrite the headers for these authenticated submissions only.

In /etc/postfix/master.cf, add the following -o lines after the submission line:

submission inet n       -       y       -       -       smtpd
  # Require SASL authentication
  -o smtpd_sasl_auth_enable=yes
  # Require TLS transport security, do not leak your credentials in plaintext.
  -o smtpd_tls_security_level=encrypt`
  # Disallow unauthenticated users from sending mail through this port.
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  # Use a different cleanup service (see below)
  -o cleanup_service_name=ascleanup

Time to configure the cleanup service for authenticated submissions. I pick the name ascleanup to keep it short and aligned, but any name works. To do so, duplicate the cleanup service line in the same master.cf file, but rename the first field and add a new option to select the filter file:

cleanup   unix  n       -       y       -       0       cleanup
ascleanup unix  n       -       y       -       0       cleanup
  -o header_checks=pcre:/etc/postfix/header_checks_submission

(Use of the pcre table requires installing postfix-pcre on Debian, that will automatically take care of updating the dynamicmaps.cf file. No further changes are needed for this.)

The final piece is the actual filter configuration in /etc/postfix/header_checks_submission. You could potentially use something like:

/^Received: .*/ IGNORE

which will remove full Received header line, but instead you can also just drop the from helo.host (reverse.host.name []) part while preserving other information:

/^Received: from [^ ]+ \([^ ]+ \[[IPv0-9a-f:.]+\]\)\s+(.* \(Postfix\) with .+)$/ REPLACE Received: $1

If you did change the mail_name option, do change the Postfix word to match your configuration. (This pattern is accurate based on the Postfix source code, smtpd/smtpd.c.)

I tested this with postfix 3.4.7-0+deb10u1 on Debian buster. For another great description with the same approach, see When sending email with Postfix, how can I hide the sender’s IP and username in the Received header?

With the above modification, the following is turned into Received: by ...:

Received: from debian (unknown [IPv6:fe80::b036:2ff:fe6e:73f4])
        by mail.example.nl (Postfix) with ESMTPSA id 1571B910B
        for <some@example.com>; Sun, 12 Jan 2020 02:23:15 +0000 (UTC)
  • this does not work on ubuntu 20. results in email sending failure Feb 17, 2021 at 8:27
  • Note: you also need to add -o cleanup_service_name=ascleanup to the smtps service in master.cf, otherwise Received-Headers are only removed for email submitted over port 587, but not for email submitted over port 465.
    – Zulakis
    Aug 6, 2021 at 8:21

Open /etc/postfix/master.cf and find:

cleanup unix n - n - 0 cleanup

Add below those line and become:

cleanup unix n - n - 0 cleanup -o header_checks=pcre:/etc/postfix/header_checks

Edit /etc/postfix/header_checks and add below codes:

/^Received:/ IGNORE

Now restart postfix. Let say on CentOS:

service postfix restart

  • 1
    Unfortunately, this will also strip the Received header on incoming mail.
    – user152253
    May 5, 2019 at 17:36
  • then got error: 451 4.3.0 Error: queue file write error
    – user956584
    Aug 5, 2021 at 1:14

Using IGNORE causes trouble with mail signing filters, such as OpenDKIM. So, postfix documentation suggests us to use REPLACE clause instead. See the documentation for REPLACE clause usage.

Step 1:

Create a regular expressions file in /etc/postfix/header_checks and add the following information.

/^Received:.*with ESMTPSA/  REPLACE Received: You can't see me ;-)
/^X-Originating-IP:/        IGNORE
/^X-Mailer:/                IGNORE
/^Mime-Version:/            IGNORE

Since I only sent emails through port 465 (and don't allow SASL via port 25), I'm matching ESMTPSA—which works fine for me.

Step 2:

Add these two lines in /etc/postfix/main.cf

mime_header_checks = regexp:/etc/postfix/header_checks
header_checks = regexp:/etc/postfix/header_checks

Step 3:

Rebuild the hash table for postfix.

$ postmap /etc/postfix/header_checks
$ postfix reload

Now, try sending a test email, you'd see Received: You can't see me ;-) as the Received header. Cheers.


use this:

/^Received: from .***/ IGNORE

only use single * in both ends

  • Or more like it? /^Received: from .*127\.0\.0\.1.*/ IGNORE
    – Jack B.
    Feb 27, 2019 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.