Um sistema pode enviar automaticamente o XML de uma nota, um PDF ou a confirmação de um pedido por e-mail. Quando a mensagem não chega, a falha pode estar na geração, na autenticação, no envio ou na entrega, e cada etapa tem um significado diferente.
Os protocolos
Três protocolos aparecem nas integrações por e-mail:
- SMTP: o protocolo de envio de mensagens.
- IMAP: o protocolo de acesso às mensagens de uma caixa postal, que continuam guardadas no servidor.
- POP3: o protocolo que baixa as mensagens da caixa postal para o programa.
O envio de uma nota ao comprador usa só o SMTP. O IMAP e o POP3 aparecem em integrações que leem uma caixa postal, como a importação de XMLs recebidos de fornecedores.
As portas do SMTP indicam o modo de uso:
25: a troca de mensagens entre servidores;587: o envio por um programa, com a proteção iniciada pelo comando STARTTLS;465: o envio por um programa, com o TLS desde o início da conexão.
O provedor define a configuração efetiva, com a porta, o modo de proteção e o mecanismo de autenticação.
As respostas do servidor
O servidor SMTP responde a cada etapa com um código de três dígitos. Os códigos iniciados por 2 indicam sucesso, os iniciados por 4 indicam uma falha temporária, que permite nova tentativa, e os iniciados por 5 indicam uma falha definitiva:
250: a etapa foi aceita;421: o serviço está indisponível no momento;535: a autenticação falhou;550: a caixa do destinatário não existe ou a mensagem foi recusada por uma política;552: a mensagem excede o tamanho permitido.
O código 250 no fim do envio confirma que o servidor de envio aceitou a mensagem, e não que ela chegou à caixa de entrada do destinatário. A mensagem ainda pode voltar como devolução, cair no filtro de spam ou ficar retida por outra condição. O identificador da mensagem e as devoluções recebidas acompanham a entrega.
A autenticação
O código 535 indica uma autenticação sem sucesso, e os detalhes da resposta orientam a análise. Uma senha incorreta, um mecanismo de autenticação não aceito e uma política da conta são hipóteses diferentes.
Muitos provedores deixaram de aceitar a senha normal da conta em programas que se autenticam só com usuário e senha. Nas contas Google, esse acesso foi desligado em 2025, e o programa precisa usar o OAuth ou uma senha de app, uma senha gerada para um único programa, quando a conta permite. A senha de app depende da verificação em duas etapas ativa, e algumas políticas de conta bloqueiam esse recurso.
Outras falhas
O bloqueio pelo provedor, os limites de envio por dia, um anexo maior que o permitido, um destinatário inválido e os filtros podem afetar o processo. A mensagem de erro e a etapa registrada separam a falha de autenticação do envio aceito sem entrega confirmada.
No suporte
Diante de um e-mail que não chegou, convém conferir a conta, o servidor, a porta, o modo de proteção, o mecanismo de autenticação e a resposta do SMTP. Quando o envio foi aceito, a investigação segue para as devoluções e a entrega, e senhas e tokens ficam fora dos trechos compartilhados no atendimento.
Para guardar
- O SMTP envia, e o IMAP e o POP3 acessam as mensagens recebidas.
- As respostas do SMTP iniciadas por 4 são temporárias, e as iniciadas por 5 são definitivas.
- O aceite do SMTP não confirma a chegada à caixa de entrada.
- Muitos provedores não aceitam mais a senha normal da conta em programas que usam só usuário e senha.
O envio de e-mails do sistema parou com o erro 535 em uma conta Google. O que investigar?
O mecanismo de autenticação usado pelo programa. A senha normal da conta não funciona mais nesse tipo de acesso, e o programa precisa usar o OAuth ou uma senha de app, quando a conta permite.
O sistema registra a mensagem como aceita pelo SMTP, mas o comprador não a recebeu. O que investigar?
O endereço do destinatário, as devoluções, os filtros e a situação da entrega, com o identificador da mensagem. A aceitação pelo servidor de envio é uma etapa anterior à chegada na caixa de entrada.