- Verschifft
- 23. September 2026 um 18:27 UTC
- Autor
- Kamo
- Ausschuss
- 8e81af7
Once SecurityService confirms a domain's DKIM record is published (org_domains.dkim_verified), password resets, invitations and other transactional letters sent as NoReply@{org domain} now carry a DKIM signature alongside the existing SPF authorization — reusing the same DkimSigner campaign mail is already signed with, unmodified. EmailSmtpService gets a new send(...) overload taking a MessageSigner, mirroring sendVia's signed path: saveChanges() once, sign, then a manually-managed Transport, since the static Transport.send() used by every other send() calls saveChanges() again internally and would mint a new Message-ID after the signature was computed over the old one. The existing 6-arg send(...) now delegates to it with a null signer, so every other caller is byte-for-byte unchanged. **************** gates on dkimVerified specifically (not just a key existing) and only ever applies when we are already sending as the org's own domain — never under the platform's domain, and never on the platform-address retry when the org's own send fails. Depends on kamo-shared-library 5de57705 and securityservice's DKIM advisory endpoint, which generates and verifies the key this reads.