Decidi mover o envio do Garfim do Resend para a Cloudflare.

Quando um cliente responde a um e-mail do Garfim, a resposta volta com erro. Os e-mails transacionais saem pelo Resend, do endereço noreply@updates.garfim.com.br, no plano gratuito, e não há Reply-To na mensagem. O subdomínio updates não recebe e-mail porque não tem registro MX, que é o registro que indica onde um domínio recebe mensagens.

O envio transacional do Garfim é o último que ainda fica fora da Cloudflare. Domínio e recebimento de e-mail já estão lá, como contei nos textos sobre domínios e e-mail dos produtos. Em 30 de outubro decidi migrar esse envio para o Cloudflare Email Sending. A migração ainda está em planejamento, e este texto explica o motivo, o que se ganha, o que se perde e o que falta resolver antes da troca.

Uma resposta que volta com erro é uma falha que o cliente percebe. Antes de decidir, pesei o custo, as peças que saem e o que se perde com a troca.

Sair do Resend tira peças do caminho e evita um recurso pago

No Resend, o plano gratuito atende um time, e esse time é o do Garfim. Cada produto a mais pediria um segundo time, recurso do plano Pro, que custa US$ 20 por mês. O Email Sending está dentro do Workers Paid, plano que eu já pago, e inclui 3.000 envios por mês. Cada mil envios adicionais custa US$ 0,35.

Ou seja, todos os produtos enviam por um plano que já existe, e nenhum produto novo abre uma conta paga.

A troca também deixa um provedor a menos no caminho do e-mail. Saem uma conta externa, com os segredos que ela exige, e o webhook público de eventos. Menos peças são um dos motivos da decisão, porque cada peça a mais precisa ser configurada e mantida.

O Pagenello já envia pelo Email Sending, e outro produto nasceu assim

O Pagenello já envia pelo Email Sending, a partir de mail.pagenello.com. Quando alguém pede um first look no site, o Worker manda um aviso para a caixa do Pagenello e uma confirmação para o cliente. No teste de lançamento, em 30 de outubro, os dois e-mails chegaram.

Um produto que ainda não lancei também teve o envio trocado do Resend para o Email Sending no código, em 29 de outubro. Os dois usam o mesmo caminho que o Garfim vai usar depois da troca.

O padrão tem regras fixas. O transacional sai de mail. e o de marketing de news., cada um com DKIM, SPF e DMARC com p=reject publicados pela Cloudflare. DKIM e SPF autenticam quem envia pelo domínio. O DMARC com p=reject pede ao destinatário que rejeite a mensagem que falhar nessa checagem.

O Reply-To aponta para a caixa humana do produto, e o envio usa o binding send_email do Worker. Com a troca, o Garfim seguiria essas mesmas regras de remetente, autenticação e resposta.

O Email Sending não mostra aberturas e não evita repetições sozinho

Aceito duas perdas. Não há evento de abertura no Email Sending, então não há como saber se a pessoa abriu o aviso. Também não há chave de idempotência no envio.

Uma chave de idempotência é o identificador que permite ao sistema reconhecer que um pedido é repetição de outro. Sem ela, se uma tentativa for repetida, o próprio sistema precisa evitar o e-mail duplicado. Isso fica sob responsabilidade do código do Garfim.

Mesmo assim, aceito as perdas porque o ganho em custo e em peças justifica a troca. Registro as duas aqui para que nenhuma apareça depois como surpresa.

Antes da troca, a cota e o Reply-To precisam estar resolvidos

Dois itens precisam estar prontos antes da troca, e um terceiro vem depois dela:

1. A cota diária da conta começa em 200 envios e é dividida entre todos os produtos que enviam por ela, inclusive o webmail.
2. O envio novo passa a ter Reply-To: contato@garfim.com.br, para que a resposta do cliente chegue a uma pessoa.
3. Depois da troca, saem do DNS os registros do Resend no subdomínio updates.

A cota exige mais atenção, porque a conta é compartilhada. Os 200 envios diários precisam ser planejados para o conjunto de produtos e para o webmail.

O Reply-To é a correção mais simples. Ele é o endereço para onde vai a resposta quando alguém clica em responder, e pode ser diferente do remetente. Hoje a resposta volta com erro. Com o endereço de contato, ela chega a uma pessoa.

A ordem importa: os registros do Resend saem do DNS só depois da troca.

A decisão de 30 de outubro ainda espera a troca

A decisão de migrar foi tomada em 30 de outubro. A troca, porém, ainda não aconteceu. Até lá, o Garfim segue enviando pelo Resend, do mesmo endereço e sem Reply-To.

Registrar a decisão antes da execução tem uma utilidade. Quando a troca acontecer, dá para comparar o que foi planejado com o que de fato saiu, incluindo a cota e as perdas listadas acima.

Quando todos os produtos enviam do mesmo lugar, o padrão de remetente, autenticação e resposta é um só. O Garfim é o último caso que falta para isso. Na parte 8, a série passa ao método de busca para Google e IAs.