- Enviado
- 23 de septiembre de 2026 a las 18:42 UTC
- Autor
- Kamo
- Commit
- 99fda5d
Dos nuevos pasos después del SPF existente, escrito para un propietario no técnico de la misma manera que SpfCard ya es — lenguaje claro, una caja "por qué esto importa", y nunca pidiendo un cambio que en realidad no necesitamos: - DkimCard: SecurityService genera una clave de firma para el dominio el primero tiempo esta carga, entonces lee si el registro TXT se publica. Sólo dos. estados reales (nada publicado aún, o algo publicado que no coincidencia) ya que un registro DKIM nunca puede collide con nada del cliente ya tiene —a diferencia de SPF, no hay ninguna distinción "add vs. edit" que hacer. DmarcCard: sólo lectura. Porque el correo de Kamo siempre utiliza el dominio del org como tanto el remitente de sobre como visible Desde, el control de alineación de DMARC ya está satisfecha una vez que se hace el SPF, cualquiera que sea la política que el org haya elegido, de modo que esto sólo muestra lo que se publica (o sugiere un punto de partida), nunca pide un cambio. Los dos nuevos... los proxies siguen existente spf/route.ts exactamente — no atrapar-all aquí, por lo que un camino sin su propio route file 404s antes de llegar a SecurityService. DnsSetupStudio ahora muestra 6 pasos en lugar de 4; número de paso a través de actualizado para los casos de propiedad y no propiedad. Depende de kamo-translation-dictionary 2f143f94 (the setup.dns.studio.dkim.* y configuración.dns.studio.dmarc.* copia) y puntos finales de asesoramiento del servicio de seguridad.