Todo site envia e-mails. Confirmações de pedidos, redefinições de senha, mensagens de formulários de contato e lembretes de reservas fazem parte do e-mail transacional, uma área que ninguém planeja, mas da qual todos dependem. Em geral, quem desenvolveu o site faz a configuração uma vez e ela nunca mais é revisada.
Até que os clientes deixam de receber as confirmações de pedidos e alguém descobre que elas estão caindo no spam há oito meses. Este artigo explica por que isso acontece, independentemente da plataforma usada, e qual configuração evita o problema.
Por que o e-mail transacional de um site falha sem dar sinais
Na configuração padrão, a maioria das plataformas envia e-mails diretamente pelo servidor web, usando a função de correio disponível na linguagem de programação. Nos testes, tudo parece funcionar porque você consulta a própria caixa de entrada e seu provedor já confia em você.
Em produção, o envio falha por um motivo que não tem relação com o código. O servidor web não possui reputação como remetente, seu endereço IP é compartilhado com outros serviços da hospedagem e a mensagem afirma vir do seu domínio, embora tenha partido de um local que o domínio nunca autorizou. Os provedores de destino tratam esse padrão como falsificação porque, na maioria dos casos, é exatamente disso que se trata. Por esse motivo, as diretrizes do Google para remetentes exigem autenticação.
Do seu lado, a falha passa despercebida. O site informa que o e-mail foi enviado, os registros não mostram erro algum e nada indica que a mensagem foi parar na pasta de spam do destinatário. O e-mail transacional de sites é particularmente ruim em avisar quando não funciona, por isso o problema costuma ser descoberto meses depois, quando um cliente reclama.
O mesmo problema em todas as plataformas
Esse problema não é exclusivo do WordPress, embora ele leve a culpa com mais frequência por ser a plataforma mais comum. O mecanismo é igual em todos os lugares.
O WordPress usa por padrão a função de correio do PHP, ou seja, envia diretamente pelo servidor e sofre com todos os problemas já mencionados. Um plugin SMTP substitui essa função e é a solução mais usada.
Shopify, Wix e Squarespace enviam seus próprios e-mails transacionais por uma infraestrutura que costuma ser bem administrada. O que nem sempre fazem é permitir o envio pelo seu domínio com a autenticação correta sem uma configuração adicional. Assim, a mensagem diz que veio da sua empresa, mas o destinatário não consegue confirmar essa origem.
Webflow, Ghost e aplicações próprias funcionam de maneiras diferentes, mas seguem o mesmo padrão: o método de envio predefinido raramente está autenticado para o seu domínio.
A solução comum a todas essas plataformas é encaminhar o e-mail transacional do site por uma conexão SMTP autenticada, usando um domínio cujos registros DNS autorizem essa conexão a enviar mensagens.
Uma solução em três partes
São necessários três elementos. Se apenas dois estiverem configurados, as mensagens ainda poderão cair no spam.
Uma conta SMTP para fazer o envio. Em vez de enviar diretamente pelo servidor web, o site se autentica em um servidor de e-mail e entrega a mensagem a ele. Todas as plataformas permitem fazer isso, de forma nativa ou por meio de um plugin.
Registros DNS que autorizem o envio. É preciso ter um registro SPF que identifique o servidor remetente e uma assinatura DKIM que permita verificar a mensagem. Sem eles, até um envio autenticado parecerá não autorizado para quem recebe. Nossos guias de SPF e DKIM explicam como configurar esses registros.
Um endereço de remetente que exista. Enviar mensagens de noreply@seudominio.com quando essa caixa postal não existe é um sinal negativo, ainda que pequeno, e também faz com que as respostas desapareçam. Aqui, criar essa caixa não tem custo adicional, pois a cobrança não é feita por usuário.
Separe esses e-mails da sua correspondência
Quando o volume começa a crescer, vale a pena adotar uma rota exclusiva para o e-mail transacional do site.
E-mails automáticos e mensagens escritas por pessoas se comportam de formas diferentes e também são avaliados de maneiras distintas. Uma sequência de quinhentas redefinições de senha depois de um incidente de segurança não se parece em nada com a correspondência de uma pessoa. Se ambos os tipos de mensagem saírem pela mesma rota, a reputação do tráfego automatizado passará a ser também a reputação do e-mail da sua equipe.
Perfis SMTP por domínio facilitam essa separação: encaminhe o domínio usado pela aplicação por uma rota e o domínio usado pela equipe por outra. Assim, um problema de um lado permanece restrito a ele. Veja os detalhes em nosso guia de SMTP personalizado por domínio.
Algumas empresas vão além e usam um subdomínio separado para todas as mensagens automáticas. Isso isola completamente a reputação, embora deixe o endereço do remetente um pouco menos elegante. A escolha depende do volume enviado.
Quando um provedor de e-mail transacional é a escolha certa
É importante deixar claro onde está o limite: para volumes realmente altos, os serviços especializados em e-mail transacional existem por bons motivos.
Se você envia dezenas de milhares de mensagens por dia, precisa acompanhar os eventos de entrega de cada mensagem, receber notificações por webhook em caso de devolução, gerenciar modelos e consultar análises detalhadas. Esses recursos são a principal finalidade de tais serviços, e nenhuma hospedagem de e-mail os oferece no mesmo nível.
Nossos limites diários foram definidos para correspondência, não para campanhas: são 1.000 mensagens por caixa postal por dia no plano Starter e até 2.500 no Agency. O e-mail transacional de uma pequena loja ou de um sistema de reservas cabe tranquilamente nesses limites. Uma plataforma de alto volume, não. Nesse caso, a arquitetura adequada é conectar um provedor transacional por meio de um perfil SMTP personalizado. Assim, a hospedagem das caixas postais e os envios em massa ficam separados sem que seja necessário contratar dois provedores de e-mail.
Confira se realmente funciona
Como esse tipo de falha não dá sinais, o hábito mais valioso é verificar a entrega em vez de simplesmente presumir que tudo está funcionando.
Gere uma mensagem real: faça um pedido de teste ou solicite a redefinição de uma senha. Envie a mensagem para endereços de dois grandes provedores diferentes. Abra os cabeçalhos e confirme que o SPF e o DKIM foram aprovados e que o DMARC indica alinhamento. Se os três resultados estiverem corretos, a configuração está de fato concluída.
Repita essa verificação a cada três meses e sempre que alguém alterar o DNS ou mudar a hospedagem. O e-mail transacional de um site raramente deixa de funcionar durante a configuração inicial. Isso costuma acontecer quando algum componente relacionado muda e ninguém se lembra de testar novamente as confirmações de pedidos depois de trocar os servidores de nomes.
Se as mensagens estão chegando, mas caem no spam, as estatísticas de entrega do próprio domínio e os relatórios DMARC normalmente apontam a causa com muito mais rapidez do que tentativas aleatórias de alterar o conteúdo.
