Uma redefinição de senha precisa chegar enquanto o link ainda funciona. Um recibo precisa descrever o pedido correto sem aparecer de novo depois de uma retentativa.
Esses requisitos começam na sua aplicação e continuam depois que o serviço de e-mail aceita a mensagem.
O que uma mensagem transacional deve conter?
Forneça ao destinatário a informação ou ação necessária para o evento que originou o e-mail. Um recibo confirma um pedido. Uma mensagem de redefinição oferece um caminho para recuperar o acesso.
Use um nome de remetente reconhecível. Escreva um assunto que identifique o evento. Direcione respostas para um endereço que sua equipe monitora quando o fluxo precisa de suporte.
Para um recibo ilustrativo, use um assunto como Receipt for order 8472. Inclua a referência do pedido, os itens comprados e um contato de suporte. Para uma mensagem de redefinição, coloque a ação de redefinição primeiro e informe quando ela expira.
Teste o conteúdo em HTML e em texto simples. Verifique se a ação principal permanece compreensível em tela estreita e com imagens desativadas.
Mantenha promoções separadas de mensagens essenciais da conta. E-mail transacional versus marketing explica como a finalidade da mensagem afeta os controles do destinatário e a política de envio.
Como você deve autenticar e separar remetentes?
Autentique o domínio de envio antes do tráfego em produção. Os requisitos de remetente do Gmail exigem SPF ou DKIM para todos os remetentes que enviam a contas pessoais do Gmail. Remetentes que excedem 5.000 mensagens por dia precisam de SPF, DKIM e DMARC.
Use identidades de envio separadas para e-mails operacionais e de marketing. A orientação do Yahoo recomenda separar marketing em massa do tráfego transacional por IP ou domínio de assinatura DKIM. Ambos carregam sinais de reputação, então um endereço From diferente sozinho não separa a infraestrutura.
Aumente o volume de envio gradualmente. A orientação do Google alerta contra picos repentinos. Verifique adiamentos e bounces durante o aumento para poder reduzir a taxa quando os servidores receptores não acompanharem o tráfego.
O checklist de entregabilidade cobre o trabalho mais amplo de autenticação e reputação de remetente.
Como você deve lidar com supressões e preferências?
Verifique por que um destinatário está bloqueado antes de decidir se outro envio é apropriado. Um opt-out de marketing e um endereço não entregável exigem ações diferentes.
A política de categorias de Bird permite e-mail transacional após um opt-out apenas de marketing. Hard bounces, supressões manuais e um opt-out que cobre todas as mensagens bloqueiam ambas as categorias.
Uma categoria transacional, portanto, não sobrepõe toda restrição de destinatário. Quando Bird reporta recipient_suppressed, inspecione o registro de supressão e as preferências do destinatário. Repetir o mesmo envio não corrige o endereço nem altera essa política.
Como links e códigos de redefinição devem expirar?
Aplique a expiração na aplicação que valida o link ou código. O texto no e-mail não pode impedir que uma credencial expirada seja aceita.
OWASP, a comunidade de segurança de aplicações, recomenda tokens ou códigos de redefinição gerados aleatoriamente com um período de expiração adequado. Também recomenda uso único. Invalide a credencial após o uso bem-sucedido para que a mesma mensagem não possa autorizar outra redefinição.
Escolha um tempo de vida para a ação da conta e mostre esse tempo na mensagem. Considere o tempo gasto em espera na sua aplicação e na entrega. Um e-mail recebido após a expiração precisa de um caminho para solicitar uma nova redefinição.
Antes de retentar um job de redefinição não enviado, verifique se a credencial ainda é válida. Não estenda a expiração de uma credencial apenas porque uma tentativa de envio falhou. Caso contrário, retentativas podem manter a credencial utilizável além do tempo de vida que você escolheu.
Para URLs de redefinição, a OWASP recomenda HTTPS e um domínio de destino confiável. Também recomenda limitar solicitações de redefinição por conta para evitar inundação da caixa de entrada.
Como retentativas evitam envios duplicados?
Mantenha um registro durável do evento de negócio e da sua operação de envio. Um evento de pedido repetido deve encontrar o job de recibo existente em vez de criar outro.
Use a mesma chave de idempotência ao retentar a mesma solicitação API após uma resposta incerta. O contrato de idempotência de Bird mantém uma resposta concluída por três horas. Após essa janela, outra solicitação com a mesma chave pode criar outra mensagem.
Esse limite torna o seu próprio registro de evento necessário para retentativas mais antigas. Salve o ID de mensagem retornado vinculado ao evento antes de tratar o envio como concluído.
Um adiamento de entrega é diferente de uma resposta incerta de API. Bird retenta entregas adiadas automaticamente. Criar outro envio para cada adiamento pode adicionar mensagens duplicadas enquanto o original ainda está em andamento.
O que você deve monitorar e alertar?
Acompanhe cada mensagem esperada ao longo do envio. Registre o resultado de cada destinatário. Meça se o usuário conclui a ação pretendida.
Os eventos de entrega de Bird distinguem aceitação, entrega, adiamento, bounce e rejeição. Entrega significa que o servidor receptor aceitou a mensagem. Isso não confirma posicionamento na caixa de entrada nem leitura.
Registre o horário do evento de negócio junto com o horário de envio e o resultado do destinatário. Para mensagens de redefinição, compare o tempo decorrido com o tempo de vida restante da credencial. Meça redefinições concluídas na sua aplicação. Um evento de rastreamento de abertura não prova que a pessoa leu a mensagem.
Configure alertas em torno dos limites operacionais do fluxo:
- Jobs não enviados se aproximam da expiração.
- Falhas ultrapassam a faixa normal.
- O processamento de webhooks fica atrasado.
Atribua um responsável que possa agir em cada alerta.
| Falha | Evidência a inspecionar | Responsável e próxima ação |
|---|---|---|
| Nenhum envio após evento de pedido | Job da aplicação e registro do evento | Equipe da aplicação: recuperar o job ausente sem duplicar um envio existente |
| Destinatário suprimido | Motivo da rejeição, supressão e preferências | Equipe de suporte ou envio: investigar o bloqueio antes de outra tentativa |
| Adiamentos de entrega em alta | Eventos do destinatário e volume de envio | Equipe de envio: inspecionar respostas dos receptores e reduzir um pico de tráfego |
| Redefinição expirada na chegada | Expiração da credencial e timestamps dos eventos | Equipe da aplicação: investigar o atraso e fornecer um caminho para nova solicitação |
| Entrega repetida de webhook | Identificador do webhook e registro de processamento | Equipe da aplicação: ignorar trabalho já concluído para esse evento |
Verifique as assinaturas dos webhooks antes de aceitar eventos. O guia de webhooks de Bird usa webhook-id para deduplicação, de modo que uma notificação retentada não repita o trabalho da sua aplicação.
O que você deve verificar antes de enviar pelo Bird?
Teste o fluxo de ponta a ponta, do envio ao resultado do destinatário e à recuperação da aplicação, antes de usá-lo para mensagens reais de conta.
- Verifique o domínio de envio. Confirme que o tráfego operacional usa a identidade e o pool pretendidos.
- Publique o template. Teste os detalhes do recibo ou a ação de redefinição com parâmetros representativos.
- Defina
category: "transactional"para conteúdo operacional. Aplique a política de supressão e preferências documentada. - Preserve o registro do evento de negócio e a chave de idempotência. Guarde o ID de mensagem retornado pelo endpoint de envio.
- Exercite o tratamento de falhas com o sandbox de e-mail. Seus resultados simulados passam pelos caminhos normais de evento e webhook sem atingir uma caixa de entrada real.
- Inspecione a linha do tempo por destinatário no log de e-mail. Confirme que sua aplicação trata os mesmos resultados e direciona alertas aos seus responsáveis.