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]
