A equipe de engenharia de uma startup construiu sua aplicação para enviar emails diretamente de seus servidores web. Funcionou bem em desenvolvimento. Em produção, os emails começaram a desaparecer. O Gmail os rejeitou. A Microsoft aplicou throttling. Os endereços IP não tinham reputação, os servidores não estavam configurados para entrega de email, e eles estavam aprendendo da maneira difícil que enviar email é mais difícil do que parece.
Eles migraram para um serviço de email relay. Em um dia, seus problemas de entrega desapareceram. O relay cuidou da autenticação, gerenciou a reputação de IP, lidou com throttling e reenvios, e, de modo geral, fez todas as coisas que seus servidores web não conseguiam fazer bem.
Email relays existem porque enviar email de forma confiável é um problema especializado. A maioria das aplicações não deveria tentar resolver isso por conta própria.
O que um relay realmente faz
Um email relay aceita emails de um sistema e os encaminha para outro. Sua aplicação envia o email para o relay; o relay o envia para o servidor de email do destinatário. O relay fica no meio do caminho, lidando com a complexidade da entrega de fato.
Isso pode parecer uma indireção desnecessária, mas o relay fornece serviços cruciais. Ele mantém relacionamentos com grandes provedores de email. Gerencia a reputação de IP entre todos os seus clientes. Trata a autenticação (SPF, DKIM, DMARC) corretamente. Implementa lógica de reenvio adequada para falhas temporárias. Gerencia throttling para evitar sobrecarregar os servidores dos destinatários.
Sua aplicação só precisa repassar o email. O relay cuida do resto.
O termo "relay" pode se referir a coisas diferentes em contextos distintos. Um SMTP relay é qualquer servidor que encaminha email. Um smart host é um relay que um servidor de email é configurado para rotear todo o email de saída através dele. Serviços de email transacional como SendGrid, Mailgun ou Amazon SES são essencialmente serviços de relay gerenciados com recursos adicionais.
Por que aplicações precisam de relays
Enviar email diretamente de servidores de aplicação cria problemas que os relays resolvem.
Reputação de IP é o maior problema. Provedores de email avaliam remetentes pelo histórico do endereço IP. Um novo IP sem histórico é tratado com suspeita. Um IP que vem enviando spam (mesmo de locatários anteriores em um ambiente de nuvem) é bloqueado. Construir e manter reputação de IP requer volume de envio consistente e boas práticas ao longo do tempo — algo que a maioria das aplicações não consegue fornecer.
A configuração de autenticação é complexa. Registros SPF precisam autorizar seus IPs de envio. DKIM requer geração de chave, registros DNS e assinatura adequada. DMARC amarra tudo isso. Acertar isso em servidores de aplicação, especialmente em ambientes de nuvem dinâmicos onde os IPs mudam, é desafiador.
O tratamento da entrega exige sofisticação. Quando um servidor do destinatário retorna um erro temporário, você precisa tentar novamente com backoff apropriado. Quando aplica throttling, você precisa desacelerar. Quando rejeita de forma permanente, você precisa parar de tentar. Implementar isso corretamente não é trivial.
Monitoramento e depuração exigem infraestrutura. Quando emails falham, você precisa saber o porquê. Relays fornecem logs, analytics e ferramentas de depuração que seriam caras de construir por conta própria.
Tipos de email relays
Configurações de relay diferentes atendem a necessidades diferentes.
Serviços gerenciados de email transacional (SendGrid, Mailgun, Postmark, Amazon SES) são a escolha mais comum para aplicações. Eles fornecem APIs e endpoints SMTP, tratam toda a complexidade de entrega e oferecem analytics e ferramentas de depuração. Você paga com base no volume.
Relays auto-hospedados (Postfix, Exim configurados como relays) oferecem controle, mas exigem expertise. Você gerencia os servidores, mantém a reputação, configura a autenticação. Isso faz sentido para organizações com requisitos específicos de compliance ou volumes muito altos em que os custos do serviço gerenciado se tornam significativos.
Relays de ISP ou provedor de hospedagem às vezes estão disponíveis como parte de pacotes de hospedagem. A qualidade varia muito. Alguns são bem mantidos; outros são compartilhados com spammers e têm reputação péssima. Avalie cuidadosamente antes de depender deles.
Relays internos dentro de organizações roteiam emails entre sistemas internos e o mundo externo. Eles podem adicionar cabeçalhos de compliance, escanear por dados sensíveis ou impor políticas. Tipicamente encaminham para outro relay ou diretamente para os destinatários.
SMTP relay vs API
Serviços modernos de email oferecem duas formas de envio: SMTP relay e HTTP API. Ambos alcançam o mesmo objetivo, mas funcionam de maneira diferente.
SMTP relay usa o protocolo tradicional de email. Sua aplicação se conecta ao servidor SMTP do relay, autentica e envia o email usando comandos SMTP padrão. Isso funciona com qualquer sistema que possa enviar email — aplicações legadas, plugins de WordPress, dispositivos de rede, qualquer coisa com suporte a SMTP.
HTTP APIs são mais modernas. Sua aplicação faz uma requisição HTTP POST com o conteúdo do email como JSON ou dados de formulário. Isso geralmente é mais fácil de integrar em aplicações web, fornece respostas de erro mais ricas e pode oferecer recursos além do envio básico de email.
Para novas aplicações, APIs são geralmente preferíveis. São mais fáceis de usar, fornecem melhor feedback e se integram naturalmente às práticas modernas de desenvolvimento. Para sistemas legados ou dispositivos que só suportam SMTP, o acesso via relay é essencial.
Muitos serviços oferecem ambos, permitindo que você escolha com base em suas necessidades. Alguns recursos podem estar disponíveis apenas por uma interface ou pela outra.
Configurando aplicações para usar relays
A maioria das aplicações e frameworks tem uma configuração de relay simples.
Para SMTP relay, você normalmente configura: o hostname do relay, a porta (geralmente 587 para submissão com TLS), credenciais de autenticação (username e password ou API key) e as configurações de TLS. A aplicação então envia todo o email de saída por meio desse relay.
Para integração via API, você usa o SDK do serviço ou faz requisições HTTP diretamente. A configuração envolve API keys e URLs de endpoint. A integração normalmente exige mais código, mas oferece mais controle e melhor tratamento de erros.
Configuração específica por ambiente é importante. Ambientes de desenvolvimento podem usar um serviço como o Mailtrap que captura emails sem entregá-los. Staging pode usar o relay de produção, mas enviar para endereços de teste. Produção usa o relay real com entrega real.
Gerenciamento de credenciais importa. API keys e senhas de SMTP devem ser armazenadas com segurança, não hardcoded. Use variáveis de ambiente ou sistemas de gerenciamento de secrets. Rotacione credenciais periodicamente.
Quando usar seu próprio relay
A maioria das aplicações deve usar serviços de relay gerenciados. Mas há situações que justificam operar o seu próprio.
Volume extremo pode tornar serviços gerenciados caros. Se você está enviando centenas de milhões de emails por mês, os custos por email se acumulam. Operar sua própria infraestrutura pode ser mais econômico, embora você troque dinheiro por complexidade operacional.
Requisitos de compliance às vezes exigem controle sobre a infraestrutura de email. Organizações de saúde, finanças e governo podem precisar garantir que emails nunca passem por sistemas de terceiros, ou precisam de capacidades específicas de auditoria que serviços gerenciados não fornecem.
Requisitos técnicos específicos podem não ser atendidos por serviços gerenciados. Esquemas de autenticação personalizados, protocolos incomuns ou integração com sistemas legados podem exigir uma solução auto-hospedada.
Se você operar seu próprio relay, espere uma sobrecarga operacional significativa. Você precisará gerenciar reputação de IP, lidar com problemas de blacklist, manter a configuração de autenticação, monitorar a entrega e se manter atualizado com padrões de email em evolução. Isso é um conjunto de habilidades especializado.
Considerações de segurança para relays
Relays são alvos atraentes para abuso. Um relay comprometido pode enviar spam que danifica sua reputação e potencialmente o coloca em blacklists.
Autenticação é essencial. Nunca opere um open relay que aceite email de qualquer um. Exija autenticação para todas as submissões. Use credenciais fortes e rotacione-as periodicamente.
Rate limiting previne abuso a partir de credenciais comprometidas. Se um atacante obtém um conjunto de credenciais, limites de taxa contêm o dano enquanto você responde.
Monitorar anomalias detecta problemas cedo. Picos repentinos de volume, padrões incomuns de destinatários ou envio em horários estranhos podem indicar comprometimento. Gere alertas para esses padrões.
Verificação de remetente garante que apenas endereços autorizados possam enviar. Se seu relay deve enviar a partir de @yourcompany.com, rejeite tentativas de enviar de outros domínios.
Frequently asked questions
Usar um relay é a mesma coisa que encaminhamento de email?
Não exatamente. Forwarding pega emails recebidos e os envia para outro lugar. Relaying pega emails de uma aplicação ou servidor e os entrega aos destinatários. O relay faz parte do caminho de envio, não do caminho de recebimento.
Usar um relay vai melhorar minha entregabilidade?
Geralmente sim, e significativamente. Bons serviços de relay mantêm forte reputação de IP, tratam a autenticação corretamente e gerenciam a entrega de forma profissional. Isso quase sempre supera o que servidores de aplicação conseguem fazer diretamente.
Posso usar Gmail ou Outlook como relay?
Serviços de email para consumidores têm limites de envio rígidos e não foram feitos para uso por aplicações. Google Workspace e Microsoft 365 oferecem recursos de SMTP relay para seus clientes, mas com limitações. Para email de aplicação sério, use um serviço dedicado.
Qual é a diferença entre um relay e um MTA?
Um MTA (Mail Transfer Agent) é qualquer servidor que transfere email. Um relay é um MTA especificamente configurado para encaminhar email de outros sistemas, em vez de ser a origem ou o destino final. Todos os relays são MTAs, mas nem todos os MTAs são relays.