Estou trabalhando em uma ferramenta que ajuda os usuários a enviar e-mails. Pretendo usar um MTA (Mail Transfer Agent) no back-end como AWS-SES ou Sendgrid etc. Para que os e-mails cheguem com sucesso nas caixas de entrada das receitas, os usuários terão que configurar o DKIM/SPF configurando o DNS configurações de seus respectivos domínios.
Agora, se eu pegar o SES por exemplo, sei que eles têm uma API que me permite adicionar uma "Identidade" e recuperar todos os registros DNS necessários para isso usando a API. Tenho certeza de que o Sendgrid e outros MTAs têm APIs semelhantes que permitem adicionar identidades e devolver os registros DNS para o usuário aplicar.
Eu mostro as configurações de DNS DKIM retornadas para o usuário, e eles as adicionam ao seu provedor de DNS e, depois disso, quando enviam e-mails, as receitas as obtêm corretamente (sem qualquer coisa "via amazonses.com" nos cabeçalhos)
Agora, por exemplo - vamos supor que a ferramenta que estou construindo esteja hospedada em chillybilly.xyz e um dos usuários que usa minha ferramenta, eles têm um domínio chamado frankthetank.xyz que eles querem usar para enviar e-mails através da minha plataforma .
Quando o usuário tentar verificar seu domínio por meio da minha plataforma, acessarei a API mencionada acima no AWS SES - e mostrarei algo assim para o usuário:
Depois disso, eles podem adicionar esses registros CNAMES e TXT para DKIM/SPF bem-sucedidos e podem começar a enviar e-mails. Mas se você olhar de perto, eles podem ver que estou usando SES por causa dos valores desses registros CNAMES e TXT. E isso é algo que eu quero evitar, em vez disso, eu quero ter aqueles chamados algo como 7nuk24xywyawocu6ctqjxmjasiaiq3vq.dkim.chillybilly.xyzo que mostraria minha marca, mas no fundo ainda apontará para o SES correto.
Agora estou ciente de que isso é possível porque quando me inscrevi no ConvertKit, eles me mostraram algo assim:
Esses dois valores, como você pode ver, estão apontando para converkit.com, MAS quando eu os executo através de uma pesquisa de DNS:
Eu posso ver que no fundo ele aponta para os registros MX e TXT que pertencem ao Sendgrid. Como posso conseguir isso? (Acredito que os mesmos princípios se aplicarão ao SES ou a qualquer outro MTA também)
EDIT:
Eu tentei algumas coisas - E eu configurei o CNAME, MX e TXT em chillybilly.xyz (domínio do meu projeto) e apontei dois CNAMES para ele de frankthetank.xyz chamado spf.frankthetank.xyzedkim.frankthetankxyz
https://dnschecker.org/all-dns-records-of-domain.php?query=spf.frankthetank.xyz&rtype=ALL&dns=google
Como você pode ver, consegui obter resultados muito semelhantes ao que o ConvertKit está fazendo com o Sendgrid. Mas não está sendo verificado dessa maneira. :(
A única diferença que vejo quando verifico essas pesquisas de DNS (links acima) é que os CNAMEs também aparecem na pesquisa para mim, mas não no caso do convertkit. Então, acho que estou perto de uma solução, mas não tenho certeza do que estou perdendo, alguma ideia? :)
Primeiro SPF: se você substituir, por exemplo. O registro SPF de saída do sendgrid, que está incluído no seu registro SPF, com sua própria marca, você ao mesmo tempo assumiu o trabalho de seguir todas as coisas dinâmicas que o sendgrid pode fazer com os nomes e endereços do servidor de e-mail de saída. Você não quer fazer isso, então se você estiver enviando via sendgrid você precisa incluir o SPF do sendgrid. Portanto, como você usa o sendgrid, não há como se livrar desse "include: sendgrid.net" em seu registro SPF sem infligir dor a si mesmo.
DKIM é semelhante, o exemplo amazonses é criar CNAMEs para registros que existem no DNS da Amazon. Se você quiser substituí-lo pelo seu próprio (o que você pode, sem problemas), você deve colocar esses registros em seu próprio DNS. O que não é problema, no entanto, você precisa transferir de alguma forma a chave de assinatura para quem assina esses e-mails, e isso pode ser um problema. Com a solução da Amazon, eles criam a chave e fornecem o link para a chave pública que colocam em seu DNS que se encaixa na chave privada com a qual assinam seu e-mail.
No entanto, se você deseja remover a "marca" dos servidores de e-mail da Amazon ou do sendgrid, a única maneira é comprá-los, porque isso é feito pelo DNS reverso, e eles NUNCA apontarão seus servidores de saída para nomes em seu namespace DNS.
Assim, você poderia apenas fazer registros CNAME que apontem para o registro de origem original ou apenas colocar o SPF correto, como o exemplo do convertkit, mas sob seu domínio.
ou ter um middleware que passe pelo processo de verificação de domínio no sendgrid/AWS, criando os registros DNS em seu domínio, que você informa ao seu cliente para CNAME para os novos registros DNS que você criou e conclui a verificação assim que o cliente clicar em um botão para dizer que eles fizeram isso
isso não interromperá os cabeçalhos de e-mail ou seguirá os registros DNS para encontrar o provedor original, mas para uma pessoa comum isso provavelmente é bom.
No entanto, quero advertir isso - as camadas de ofuscação realmente prejudicam a camada DNS.
Por exemplo, o SPF tem um limite explícito de 10 pesquisas codificadas no RFC - o próprio Sendgrid escreve sobre isso - https://docs.sendgrid.com/ui/account-and-settings/spf-limitations
pesquisas de DNS adicionais aumentarão os tempos de resposta para qualquer pesquisa baseada em DNS no fluxo de entrega de e-mail e/ou em seu aplicativo - isso pode causar muita dor em muitos níveis, especialmente porque os MTAs estão processando em tempo real, qualquer atraso tem um enorme impacto potencial.
Para colocar um pouco de matemática nisso, imagine que um único e-mail leve 20 ms para ser processado e enviado por meio de um MTA com DNS - isso é o melhor exemplo, assumindo que essa lógica é verdadeira. Você pode enviar aproximadamente 180 mil e-mails por hora. Se precisarmos dobrar isso adicionando pelo menos 1 pesquisa de dns extra, isso reduzirá para 90 mil e-mails por hora. Se você depende do volume, precisa agora lançar o dobro da quantidade de hardware para manter a mesma taxa de transferência.
O SG tem uma opção chamada
automatic_securityna API Autenticar um Domínio . O que essa opção eu acho no back-end é que ela permite que o SG gerencie/gire chaves DKIM e outros registros usando seus registros DNS. Conseqüentemente, quando você torna essa opção verdadeira, eles retornam registros CNAME em vez de registros MX e TXT. E os registros MX/TXT são gerenciados nos bastidores pela SG.A parte conveniente dos registros CNAME é que outros registros CNAME podem facilmente apontar para eles. Então apontei
chillybilly.xyz -> SG CNAME recordsque voltei do SG, e aponteifrankthetank.xyz records -> chillybilly.xyz CNAME recordse, assim, criei uma espécie de middleware no meio.Por favor, não
chillybilly.xyzé o domínio do meu aplicativo efrankthetank.xyzé o domínio do cliente. Essa é a suposição em que estamos operando enquanto resolvemos o problema.Agora, é claro, como uma das respostas apontou que isso aumentará a pesquisa de DNS por causa de outra camada intermediária, ainda precisamos avaliar se isso realmente faz sentido para nós ou se aumentará os tempos de entrega de e-mail ao escalar eventualmente. Mas a solução funciona. Eu acho que é apenas uma implementação SG, eu acho. Não consegui fazê-lo funcionar com o AWS SES. Eu tenho uma ligação com eles em breve - Se eu souber melhor, editarei esta resposta :)