- 已装运
- 2026年9月23日 18:42 UTC
- 作者
- Kamo
- 提交
- 99fda5d
Two new steps after the existing SPF one, written for a non-technical owner the same way SpfCard already is — plain language, a "why this matters" box, and never asking for a change we don't actually need: - DkimCard: SecurityService generates a signing key for the domain the first time this loads, then reads whether the TXT record is published. Only two real states (nothing published yet, or something published that doesn't match) since a DKIM record can never collide with anything the customer already has — unlike SPF, there's no "add vs. edit" distinction to make. - DmarcCard: read-only. Because Kamo's mail always uses the org's domain as both envelope sender and visible From, DMARC's alignment check is already satisfied once SPF is done, whatever policy the org has chosen — so this only shows what's published (or suggests a starting point), never asks for a change. Both new **************** proxies follow the existing spf/route.ts exactly — no catch-all here, so a path without its own route file 404s before reaching SecurityService. DnsSetupStudio now shows 6 steps instead of 4; step numbering throughout updated for both the ownership-token and no-ownership-token cases. Depends on kamo-translation-dictionary 2f143f94 (the setup.dns.studio.dkim.* and setup.dns.studio.dmarc.* copy) and securityservice's advisory endpoints.