Site, caixa postal e e-mail transacional são coisas diferentes

"Preciso de e-mail profissional" pode querer dizer três coisas, e cada uma se contrata de um jeito.

Uma é ter contato@suaempresa.com.br para a equipe ler e responder. Outra é o sistema mandar confirmação de pedido e código de acesso. A terceira, às vezes vendida no mesmo pacote, é o site. As três usam o mesmo domínio e quase mais nada em comum.

O site entrega páginas

Hospedagem guarda páginas e arquivos e os entrega ao navegador. O HTTPS do site protege a conexão de quem visita e não faz nada pelo seu e-mail: certificado válido em www não ajuda mensagem nenhuma a chegar.

Plano de "site com e-mail" é comum e pode servir. Antes de assinar, pergunte quantas caixas vêm, se dá para exportar as mensagens e como é sair. A última pergunta é a que ninguém faz e a que dói na migração.

A caixa postal é para gente

Caixa postal é onde uma pessoa recebe, lê e responde: webmail, aplicativo no celular, Outlook ou Thunderbird por IMAP. O que importa aqui é humano. Recuperar a senha, ter verificação em duas etapas, guardar o histórico, dar acesso a quem entra e tirar de quem sai.

Antes de comparar planos, liste as pessoas e os endereços. Caixa individual, apelido e grupo se comportam diferente. Um apelido como vendas@ pode só encaminhar para a caixa do João, e quando o João sai da empresa o histórico vai junto, se ninguém pensou nisso antes.

O transacional é para sistemas

Recuperação de senha, nota fiscal, confirmação de pedido. Quem manda é a aplicação, disparada por um evento, e quem recebe está esperando aquela mensagem específica.

Mandar isso pela caixa da equipe funciona até o dia em que para de funcionar. É o limite diário de envio, a senha trocada que derruba o sistema, a falta de qualquer registro de qual aviso saiu para quem. Serviço transacional existe para isso: API ou SMTP próprio, um identificador por mensagem e eventos dizendo se o servidor do destino aceitou, recusou ou adiou.

Uma distinção que evita briga com o atendimento: aceitar não é entregar, e entregar não é ler. O SMTP da RFC 5321 só informa a primeira parte.

Como os três convivem

Pense numa loja pequena. O site fica em www.loja.com.br, na hospedagem. A equipe atende em atendimento@loja.com.br, numa caixa do Google Workspace ou do Microsoft 365. O sistema da loja manda de pedidos@loja.com.br por um serviço transacional. Três fornecedores, um domínio, e tudo convive bem enquanto cada um tem seus registros no DNS sem pisar nos do outro.

Um detalhe que passa batido: o cliente vai responder a confirmação do pedido. Aponte o Reply-To, campo da RFC 5322, para uma caixa que alguém lê. naoresponda@ só empurra a dúvida para o telefone.

Decida pela tarefa, não pelo pacote

• Publicar páginas: hospedagem ou plataforma de site. Confira HTTPS, backup e se dá para publicar sem depender de alguém de fora.
• Gente conversando: caixa postal com duas etapas, recuperação de conta e exportação.
• Sistema avisando: transacional com API ou SMTP, autenticação do domínio e eventos por mensagem.
• Sistema lendo respostas: recepção por webhook ou API. É outra função, e vale perguntar separado.

Na hora do orçamento, descreva cada tarefa com volume. "O sistema manda umas 3 mil confirmações por dia, com pico na Black Friday" rende uma conversa útil. "Preciso de e-mail" rende uma proposta de pacote.

Migre uma coisa de cada vez

Trocou de hospedagem? Mexa nos registros do site e deixe o MX quieto. Trocou de caixa postal? Mude o MX num horário calmo e deixe a conta antiga ativa por alguns dias, para pegar o que chegar atrasado. Trocou de serviço transacional? Publique o DKIM novo antes de virar a chave na aplicação.

Fazer tudo no mesmo fim de semana parece eficiente. Na segunda-feira, quando algo não chegar, você vai ter três suspeitos e nenhuma pista.

Se o que importa é o sistema mandando, o próximo passo é o guia de SPF, DKIM e DMARC. Se o DNS ainda parece terreno estranho, volte ao primeiro guia.