[pfx] Re: Postfix not able to forward emails

NOTE: PLEASE ONLY REPLY ON-LIST.

On 2026-06-07 at 15:49:22 UTC-0400 (Sun, 07 Jun 2026 15:49:22 -0400)
Al via Postfix-users <[email protected]>
is rumored to have said:

> Hi,
>
> I setup a new postfix server and I am getting errors. Also, 
> postfix-users keeps disabling my account, so please CC me directly.

That's most likely because mail to you from the postfix list is being 
rejected as failing some form of authentication. This is an inherent 
problem between mailing lists and the mechanisms used to authenticate 
email. The major mailbox providers like Yahoo, MS, and Google have 
deployed stringent authentication requirements as an alternative to 
competent spam filtering and policy enforcement staffing, which makes 
many traditional email practices difficult.

> Everything worked just fine on the old server and I was able to 
> forward all the emails. On the new server, pretty much everything is 
> bouncing.

As others have mentioned, this sounds like a problem whose solution, IF 
ONE EXISTS is in DNS.

>
> The errors I am getting with forwarded emails are:
>
> host mta7.am0.yahoodns.net[67.195.204.79] said: 554 5.7.9
>     This mail has been blocked because it failed authentication checks 
> against
>     the sending domains DMARC policy. See
>     https://senders.yahooinc.com/smtp-error-codes#dmarc-fail for more
>     information. (in reply to end of DATA command)
>
> and
>
> host mx-att.mail.am0.yahoodns.net[98.137.26.68] said: 554
>     5.7.9 This mail has been blocked because it failed authentication 
> checks
>     against the sending domains DMARC policy. See
>     https://senders.yahooinc.com/smtp-error-codes#dmarc-fail for more
>     information. (in reply to end of DATA command)

DMARC is a complex tool, but generally speaking a DMARC failure is 
related to the domain in the From *header* address. To pass, a message 
must either be DKIM-signed with a key from that domain OR it must use an 
envelope sender in the same domain as the from header and pass SPF, 
which means the connecting IP is in the domain's SPF record.

Generally speaking, forwarding email breaks SPF unless you use a tool 
like SRS to transform the sender address to one in a domain you can 
publish SPF for. This can be avoided if the *sender's* domain has used 
DKIM to sign the message and there has been no modification in transit.

> Recently, I started getting a new error and this is with emails that I 
> am sending:
>
> host gmail-smtp-in.l.google.com[172.217.215.26] said: 550-5.7.25
>     [173.248.207.241] The IP address sending this message does not 
> have a
>     550-5.7.25 PTR record setup, or the corresponding forward DNS 
> entry does
>     not 550-5.7.25 match the sending IP. As a policy, Gmail does not 
> accept
>     messages 550-5.7.25 from IPs with missing PTR records. For more
>     information, go to 550-5.7.25
>     https://support.google.com/a?p=sender-guidelines-ip  550-5.7.25 To 
> learn
>     more about Gmail requirements for bulk senders, visit 550 5.7.25
>     https://support.google.com/a?p=sender-guidelines.
>     956f58d0204a3-65d96cd6331si1249115d50.291 - gsmtp (in reply to end 
> of DATA
>     command)

That's a different problem which needs a very simple solution: make sure 
your IP address has a PTR ("reverse DNS") record which resolves back to 
a name which resolves "forward" (with an A record) to the same IP.

> Please let me know what I need to change to fix these issues. Thanks 
> in advance!

1. Don't automatically forward email from an external source to an 
external destination using the traditional mechanisms that preserve the 
envelope sender address. It's an antique mechanism that is inconsistent 
with the authentication people expect email to fulfill in the modern 
world. There are workarounds but the fundamental problem is simplistic 
forwarding itself.

2. Make sure you have a correct PTR record for the IP of your mail 
server. Without this, you *cannot* run a functional outbound mail 
server. Many people will reject your mail or simply bitbucket it 
silently without a PTR and many will also do so if the PTR yields a 
wrong name.

3. Make sure you have a proper SPF record for your own domain.

4. Run strong anti-spam measures such as rspamd or SpamAssassin to 
prevent you from forwarding spam.

5. If you must forward email that you did not originate, deploy SRS. 
This makes the envelope sender address usable as authentication (SPF) so 
that you don't get rejections for non-passing SPF alone.

6. DKIM-sign all mail that you originate OR forward. This won't satisfy 
DMARC for forwarded mail, since the From header is someone else's, but 
it will protect the mail you send and makes it possible in principle for 
the receiving side to use the authentication of DKIM from your domain as 
a basis of trust for forwarded email. I don't think major providers do 
this in any automated way at this time.

Items 2-4 are best practices for all mail systems, as is DKIM signing 
all local-origin mail.

Doing all of 2-6 is unlikely to solve all of your problems with 
forwarding to any of the behemoth mailbox providers.


-- 
  Bill Cole
  [email protected] or [email protected]
  (AKA @[email protected] and many *@billmail.scconsult.com 
addresses)
  Please keep discussion mailing list replies *on-list*
  Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]