- Enviado
- 23 de setembro de 2026 às 18:42 UTC
- Autor
- Kamo
- Confirmação
- 99fda5d
Dois novos passos após o SPF existente, escrito para um proprietário não técnico da mesma forma que o SpfCard já é — linguagem simples, uma caixa "por que isso importa", e nunca pedir uma mudança que não precisamos. - DkimCard: SecurityService gera uma chave de assinatura para o domínio o primeiro tempo isso carrega, em seguida, lê se o registro TXT é publicado. Apenas dois. estados reais (nada publicado ainda, ou algo publicado que não uma vez que um registro DKIM nunca pode colidir com nada do cliente já tem — ao contrário do SPF, não há distinção "adicionar vs. editar". - DmarcCard: somente leitura. Porque o correio do Kamo usa sempre o domínio da org como tanto remetente de envelopes quanto visível De, a verificação de alinhamento da DMARC já está satisfeito uma vez que o SPF é feito, qualquer que seja a política que o org tenha escolhido — por isso esta apenas mostra o que é publicado (ou sugere um ponto de partida), nunca pede Uma mudança. Ambas as novas... as proxies seguem o spf/route.ts existentes exatamente — nenhum catch-all aqui, então um caminho sem o seu próprio arquivo de rota 404s antes de chegar ao SecurityService. DnsSetupStudio agora mostra 6 passos em vez de 4; numeração de passos ao longo actualizados tanto para os processos relativos à propriedade como para os processos relativos à não propriedade. Depende do dicionário de tradução-kamo 2f143f94 (o setup.dns.studio.dkim.* e setup.dns.studio.dmarc.* copy) e os endpoints consultivos do serviço de segurança.