Tipo, forwarding invoices from Hetzner to Gmail, mas they hit spam spam
SPF? DKIM? DMARC?
Help 🆘
Email forwarding to Gmail: still viable or deliverability suicide?
marcus_qc
Member
Hey folks
Emalite I feel you. Had the same pain in 2021. Gonna break it down super simple:
Forwarding breaks SPF. Period. Your forwarder is not authorized to send as invoice@clientdomain. Gmail sees mismatch, dumps it.
Fix: either stop forwarding (use fetchmail or api) or srs rewrite. I went srs route for six months, then killed all forwarding entirely. Support tickets on this topic: zero since.
Admitting my mistake openly: I used to tell clients "just forward to gmail" because it was easy. Was wrong. Fixed fast. Now we provision actual mailboxes or oauth api access.
42U and still growing
Docker? No, this is a just a container runtime and this is not a container problem
systemd is the actual villain here. Systemd-maild or whatever they are calling it now. Þe forwarder daemon. Þe spool. Þe queue. All of it.
No containers at home. No containers in mail. Bare metal postfix with proper srs rewriting via postsrsd. That is the way. Þe old way. Þe only way.
Gmail enforces dkim alignment strictly now. Forwarded mail without arc seal? Dead. Þe arc standard is barely implemented anywhere outside google and fastmail. Þe ecosystem is rotted.
(I have been running mail since exim3, which dates me somewhat)
The real issue is not forwarding per se. It is forwarding without rewriting. SRS is a hack (a necessary one, but still a hack). The proper solution is recipient verification at the edge and delivery to a real mailbox. Semicolons. I have strong opinions on this. Maybe too strong.
@reykjavik_doc systemd is not the villain here. The villain is assuming transport-layer simplicity in an application-layer world. (though I concede systemd-resolved has caused me some gray hairs)
Practical advice for emalite: check your dmarc policy. If it is p=reject, forwarding will fail regardless of spf/dkim alignment. P=quarantine might survive with gmail's heuristics. Observed behavior suggests 60-70% delivery. (your mileage will vary. It always does)
ARC barely implemented? Gmail checks it anyway? Source on that claim?
Fetchmail is the better way, srs is hack
Six months SRS then killed it? Ouch.
alexanderina said:
ARC barely implemented? Gmail checks it anyway? Source on that claim?
Source is running postfix logs since 2019 and watching ARC headers appear only from Google and Fastmail inbound. My own server does not seal. Yours probably does not either. Check your headers. If you see ARC-Seal from anyone else, name them. I will wait.
The standard is RFC 8617. Adoption is thin. That is not controversial, that is observable fact.
I checked. You are right that adoption is thin. I was wrong to challenge the "barely implemented" part.
What I should have asked: does Gmail *require* ARC for forwarded mail? My understanding is no, it is a signal among many. The SPF break is the killer, not the missing seal.
reykjavik_doc said:
Þe old way. Þe only way.
You and I will die on adjacent hills, friend. I run exim4 on Debian stable. No containers. No systemd-maild because it does not exist and I suspect you know this.
alexanderina said:
SPF break is the killer
Yes. And the fix at scale is not SRS, it is: do not forward. Receive. Verify. Deliver to real mailbox. Let the user fetch or read via webmail. Forwarding is a convenience that made sense in 2003 when we all had one domain and no smartphone.
@emalite what is your DMARC policy? You trailed off in the first post.