[pfx] Re: Postfix not able to forward emails

On 07/06/2026 5:27 pm, Bill Cole via Postfix-users wrote:
> 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.

I didn't relize the amount of reconfiguration of postfix, dspam, 
procmail, and dovecot this would take and this is just to add SRS. Along 
with some small changes in DNS. Although, since I don't own the IP it is 
kinda a large problem. I may need to find someone who understands the 
postfix config better than I do to make these changes. Does anyone know 
where I can find a consultant?

Kind Regards,
Al
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]