- Shipped
- September 5, 2026 at 2:49 AM UTC
- Author
- Kamo
- Commit
- 4ab2cae
The From address was chosen by asking who hosts the organization's MAILBOXES. That is a different question from the one that matters, and it was wrong in both directions at once. chinilaw.com runs on Google Workspace and had added include:spf.kamocrm.com to its SPF — authorizing our relay explicitly, in writing, in DNS — and still got "Ron Chini, PC" <NoReply@kamocrm.com> on every verification and password-reset mail. Meanwhile six organizations whose SPF has never mentioned us were sending as their own domains, because we host their mailboxes: unauthenticated mail claiming a domain we do not send for, which is the configuration receivers spam-folder and reject outright under a strict DMARC policy. So the rule is now the DNS record: owned, and authorizing us. Both halves are required. Ownership without SPF is exactly the unauthenticated mail above; SPF without ownership would let anyone who added an include mechanism borrow a domain. Unknown reads as no — a domain the sweep has not reached yet sends from the platform address, because guessing wrong that way costs branding while guessing wrong the other way costs delivery, silently, on the message that most has to arrive. One row selection feeds both the address and the decision. Reading the flags off one domain while sending as another would authorize something nobody checked, and nothing would look wrong: the message still sends. A hard refusal at the relay now retries once from the platform address rather than losing the mail. That is deliberately NOT the protection against an unauthorized domain, and cannot be: an SPF failure is not a send failure — the relay accepts the message, the receiving server accepts it, and it is quietly spam-foldered or bounced later. The pre-check is the protection; this is for the narrower case where the send actually threw.