SMTP: o que é e como configurar o envio de e-mail

O formulário de contato do site funcionou por meses e, numa segunda-feira, parou de avisar quando chega mensagem. Ninguém mexeu no site. Mudou a senha da conta de e-mail usada para enviar, ou a hospedagem passou a bloquear uma porta.

Quase sempre o problema está no SMTP, o protocolo que o site, o Mautic e o sistema de notas fiscais usam para despachar e-mail.

O SMTP só entrega o e-mail ao servidor do outro lado. Quem decide se a mensagem cai na caixa de entrada ou no spam é a reputação do seu domínio.

Como o SMTP leva a mensagem até o outro servidor

A especificação atual está na RFC 5321, publicada em outubro de 2008, que substituiu as versões anteriores do mesmo padrão. A conversa entre as máquinas é curta. O cliente abre a conexão, se apresenta, informa o remetente e o destinatário e transmite o conteúdo.

O caminho tem quatro paradas. Primeiro, o seu programa (o Outlook, o plugin do WordPress, o Mautic) entrega a mensagem ao servidor de envio da sua conta. Esse servidor confere quem você é e aceita o envio.

Depois ele olha o domínio do destinatário, por exemplo empresa.com.br, e pergunta ao DNS qual é o registro MX desse domínio. O MX aponta a máquina que recebe e-mail por aquele endereço. A RFC descreve esse passo como resolver o domínio de destino para um servidor intermediário de correio ou para o servidor final.

Com o endereço em mãos, o servidor de envio abre uma conexão com o servidor de destino e repete a mesma conversa. O destino pode aceitar a mensagem, recusar na hora ou aceitar e mandar para o spam, e o remetente não interfere nessa decisão.

A leitura é outro assunto. Quando a pessoa abre o e-mail no celular, o aplicativo usa IMAP ou POP3 para buscar a mensagem na caixa. Por isso a configuração de um cliente de e-mail pede dois servidores: um de entrada e um de saída. Site e sistema que só disparam mensagem precisam apenas do de saída.

Portas 25, 587 e 465: qual usar

A porta diz em que trecho do caminho você está e como a conexão se protege. A troca entre elas responde por boa parte dos chamados de "o e-mail não sai".

A porta 25 é a original e serve para a troca entre servidores. Quando o servidor da sua conta entrega ao servidor do Gmail, ele usa essa porta. Para quem envia de um site ou de um sistema, ela é a escolha errada. Provedores de nuvem limitam a 25 para conter spam disparado de máquinas comprometidas. A documentação do Amazon SES avisa que o EC2 limita o tráfego de e-mail nessa porta por padrão. A orientação é pedir a remoção do limite ou trocar de porta.

A porta 587 é a de submissão, onde o cliente entrega a mensagem ao servidor da própria conta. A conexão começa sem criptografia e passa para TLS com o comando STARTTLS. A porta 465 faz o mesmo serviço com TLS desde o primeiro pacote, o chamado TLS implícito.

A RFC 8314, de janeiro de 2018, recomenda o TLS implícito para a submissão. Ela também pede que clientes e servidores aceitem as duas formas durante a transição. Segundo o texto, com implementação correta não há diferença relevante de segurança entre STARTTLS na 587 e TLS implícito na 465. Use a que o seu provedor indicar.

Autenticação e TLS: o que protege o envio

O servidor de envio só aceita mensagem de quem prova que tem conta ali. Essa prova é a autenticação: usuário e senha, ou uma chave gerada no painel, no caso dos serviços transacionais. Sem ela, qualquer pessoa usaria o seu servidor para mandar spam. Servidor que aceita mensagem de qualquer um, o chamado open relay, acaba em lista de bloqueio.

O TLS protege a conversa no caminho. Sem ele, usuário, senha e conteúdo trafegam em texto puro e ficam legíveis para quem estiver na mesma rede. A RFC 8314 pede que os provedores tirem os usuários do envio sem criptografia o quanto antes.

Conta do Google com verificação em duas etapas cria um obstáculo a mais. O plugin ou sistema que envia não consegue passar pelo segundo fator. A saída é a senha de app, um código de 16 dígitos gerado para aquele programa.

Três regras pegam muita gente. Ela só existe em conta com verificação em duas etapas ativa. Em conta de trabalho, escola ou outra organização, a opção pode nem aparecer. E toda senha de app é revogada quando você troca a senha da conta, que é a causa clássica do formulário que parou numa segunda-feira.

SMTP do provedor ou SMTP transacional

Existem dois jeitos de ter um servidor de envio. O primeiro é usar o da conta de e-mail que você já tem: Google Workspace, Microsoft 365 ou o e-mail da hospedagem do site. O segundo é contratar um serviço feito para disparar mensagem a partir de sistemas, como Amazon SES, Mailgun, SendGrid e Brevo.

O servidor do provedor de e-mail foi pensado para gente. Ele tem limite de envio por conta, guarda cópia na pasta de enviados e trata volume alto como sinal de abuso. Atende bem o formulário de contato e o aviso interno.

O serviço transacional foi pensado para sistema. Ele recebe a mensagem por conexão autenticada ou por API e registra o que aconteceu com cada envio: entregue, recusado, devolvido ou marcado como spam. Com esse registro dá para saber se o boleto chegou antes de o cliente reclamar. O preço varia por volume e por plano, então confira a página de cada fornecedor antes de decidir.

A escolha depende do que o envio carrega:

• Formulário de contato do site: a conta de e-mail da empresa resolve. O volume é baixo e quem recebe é a própria equipe.
• Mautic e campanhas: use um serviço transacional ou de envio em massa. Uma campanha para milhares de contatos estoura o limite de uma conta comum e expõe o domínio principal. O assunto está detalhado em e-mail marketing com Mautic.
• Sistema que manda nota fiscal ou boleto: serviço transacional, de preferência com um subdomínio só para esse envio. Se uma campanha ruim prejudicar a reputação do marketing, a nota continua chegando.
• Newsletter própria: ferramentas como o listmonk dependem de um servidor SMTP desses para enviar, com os mesmos dados de conexão.

Como configurar o envio num site ou no Mautic

O roteiro é o mesmo para WordPress, Mautic, ERP ou qualquer sistema que tenha uma tela de configuração de e-mail.

1. Escolha o serviço e o remetente. Defina o endereço que vai aparecer no campo De, sempre num domínio que você controla. Remetente @gmail.com enviado por outro servidor costuma ser rejeitado.
2. Separe os quatro dados de conexão. Servidor (host), porta, usuário e senha ou chave. O provedor publica esses valores na documentação, e o painel do serviço transacional gera a credencial.
3. Escolha porta e criptografia juntas. Porta 587 pede STARTTLS, porta 465 pede TLS ou SSL, como alguns painéis ainda chamam. Misturar os dois é a falha mais comum.
4. No WordPress, instale um plugin de SMTP. Sem ele, o WordPress usa a função de e-mail do servidor da hospedagem, sem autenticação no seu provedor. O plugin troca isso pela conexão autenticada.
5. No Mautic, preencha a configuração de e-mail. Em Configurações, na parte de e-mail, informe host, porta, usuário e senha. Para campanhas grandes, ative a fila e agende o cron que processa as mensagens. O passo a passo da instalação está em como instalar o Mautic.
6. Publique o SPF e o DKIM do serviço. O serviço transacional mostra os registros DNS que você precisa criar. Sem eles, o destino recebe a mensagem e desconfia do remetente.
7. Mande um teste para fora da empresa. Envie para uma conta Gmail e uma Outlook e abra o cabeçalho completo. Lá aparece se SPF, DKIM e DMARC passaram.

Os erros que mais aparecem

Os chamados sobre SMTP se repetem, e quase todos têm causa simples:

• Porta e criptografia trocadas: a 465 configurada com STARTTLS, ou a 587 com TLS implícito. A conexão fica pendurada até estourar o tempo limite.
• Porta 25 bloqueada: o site roda numa máquina em nuvem e a conexão de saída não abre. Troque para 587 ou 465.
• Senha da conta no lugar da senha de app: com verificação em duas etapas, o Google recusa a senha normal no plugin.
• SPF sem o serviço novo: o registro do domínio autoriza só o servidor antigo, e o destino trata o envio como suspeito.
• Limite de envio: a conta comum trava no meio da campanha, e o resto da lista fica sem receber.
• Fila parada no Mautic: a fila está ativa, mas o cron não roda, e as mensagens se acumulam sem sair.

Quando nenhum desses explica o sintoma, o post de dúvidas comuns e solução de problemas no Mautic cobre os casos específicos da ferramenta.

Onde o protocolo para

O trabalho do SMTP termina quando o servidor de destino responde que aceitou a mensagem. Daí em diante quem decide é o filtro do outro lado. Ele confere se o domínio publicou SPF, se a mensagem veio assinada com DKIM, se existe política DMARC e como foi o histórico de envio daquele remetente.

Esses registros estão explicados em entregabilidade de e-mail com SPF, DKIM e DMARC. Eles valem para qualquer servidor que você escolher, do Google Workspace ao Amazon SES.

Se o cabeçalho do teste mostra SPF e DKIM aprovados e a mensagem ainda cai no spam, o ajuste que falta está na reputação do domínio, construída com o histórico de envio daquele remetente.