Hello Thomas, This might help too: These failures are often due to SPFs that have a hard fail (meaning they end with ‘-all’). When I dealt with this in the past, the original sending domain was one where we could modify the SPF. So we had the email sender change “-all” to “~all” and since that makes it a soft fail, the email forwards started operating again.
And it sounds like you already know this but: SPFs are basically TXT records attached to a domain’s DNS that specifies which mail server IPs have permission to send that domain’s emails. Hence the issue with email forwarding; Domain A sends to B which sends to C which makes C grumpy since B isn’t on A’s list of approved IPs. > On Jan 3, 2024, at 1:46 PM, Bill Cole > <sausers-20150...@billmail.scconsult.com> wrote: > > On 2024-01-03 at 14:17:11 UTC-0500 (Wed, 3 Jan 2024 13:17:11 -0600) > Thomas Cameron via users <thomas.came...@camerontech.com> > is rumored to have said: > >> The rub is, I want all emails to presid...@example.org to be forwarded to >> presidents_real_addr...@gmail.com. Since the forward happens at >> mail.example.org, the "from" is from some other domain from example.org, so >> it fails all the tests. > > Indeed: your solution is known as "SRS" (Sender Rewriting Scheme) and it has > multiple implementations. If you forward mail, you will break SPF unless you > fix the envelope sender so that it uses a domain that permits the > example.org server to send for it. > > OR, you could instead deliver to a POP mailbox locally and have users fetch > from there instead of simply forwarding mail to them. This also avoids a > completely distinct problem of places like GMail deciding that your org's > mail server is a spamming service because it is forwarding spam. If users POP > their mail instead of having it forwarded via SMTP, that does not happen. > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire > >
