- Shipped
- 5 de setembro de 2026 às 02:49 UTC
- Author
- Kamo
- Commit
- 4ab2cae
O endereço De foi escolhido perguntando quem hospeda o MAILBOXES da organização. Essa é uma pergunta diferente da que importa, e foi errado em ambos instruções imediatas. chinilaw.com roda no Google Workspace e tinha adicionado incluem:spf.kamocrm.com seu SPF — autorizando nosso relé explicitamente, por escrito, em DNS — e ainda tem "Ron Chini, PC" <NoReply@kamocrm.com> em cada verificação e reset de senha Correio. Enquanto isso, seis organizações cujo SPF nunca mencionou nós estavam enviando como seus próprios domínios, porque hospedamos suas caixas de correio: correio não autenticado reivindicando um domínio que não enviamos, que é os receptores de configuração spam-pasta e rejeitar totalmente sob uma política rigorosa DMARC. Então a regra agora é o registro DNS: possuído, e autorizando-nos. Ambas as metades são requerido. Propriedade sem SPF é exatamente o correio não autenticado acima; SPF sem propriedade deixaria qualquer um que adicionasse um mecanismo include emprestado um domínio. Desconhecido lê como não — um domínio que a varredura ainda não atingiu o endereço da plataforma, porque adivinhar errado dessa forma custa a marca enquanto adivinhando errado a outra maneira custa entrega, silenciosamente, na mensagem que a maioria Tem de chegar. Uma linha de seleção alimenta tanto o endereço quanto a decisão. A ler as bandeiras um domínio ao enviar como outro autorizaria algo que ninguém verificou, e nada pareceria errado: a mensagem ainda envia. Uma recusa dura no relé agora volta uma vez do endereço da plataforma em vez do que perder o correio. Isso não é deliberadamente a proteção contra um domínio não autorizado, e não pode ser: uma falha SPF não é uma falha de envio — o relé aceita a mensagem, o servidor recebe-a, e é silenciosamente spam-dobrado ou saltado mais tarde. O pré-controlo é a protecção. Caso mais estreito onde o envio realmente jogou.