É necessário configurar um relay SMTP separado ou o seu servidor de email pode enviar diretamente os seus emails transacionais e as suas campanhas? Um relay SMTP é um servidor intermediário que assume o encaminhamento dos seus emails em vez do seu próprio servidor, para preservar a deliverability e absorver volumes que o seu servidor de email não consegue gerir sozinho. Atua depois do funcionamento do SMTP, na parte de transporte da mensagem.
Relay SMTP e servidor SMTP do seu email: dois elos distintos
O servidor SMTP do seu email (Outlook, Gmail ou a ferramenta interna do seu CRM) é o ponto de partida da mensagem. O relay SMTP é o elo seguinte: recebe essa mensagem e encaminha-a, por vezes alterando o IP de envio ou a autenticação aplicada. Confundir os dois leva a um erro frequente: tentar corrigir a deliverability do lado do email quando o estrangulamento está do lado do relay. Um não substitui o outro. Para saber qual dos dois está a causar o problema, comece por encontrar o servidor SMTP utilizado pelo seu email. Se aguentar a carga e a reputação se mantiver boa, um relay separado não traz mais nenhuma vantagem.
O smart host, um relay com uma missão precisa
Um smart host é um relay SMTP configurado para resolver um problema identificado: contornar um bloqueio da porta 25 por parte de um fornecedor de acesso ou evitar um endereço IP de saída já degradado. Encaminha a mensagem para um servidor terceiro de confiança em vez de tentar uma entrega direta. A porta importa nesta fase: a maioria dos relays autentica na porta 587, raramente na 25. Se a sua configuração ainda bloquear neste ponto, a porta SMTP a utilizar consoante o seu caso determina-se antes de qualquer ajuste do relay.
Open relay: a falha que vira o relay contra si
Um open relay aceita e transmite emails sem verificar quem os envia. Qualquer pessoa pode então utilizá-lo para enviar spam ou phishing em nome do seu domínio. A definição técnica de um relay mantém-se, no entanto, neutra: em substância, a RFC 5321 (IETF, 2008) descreve um sistema SMTP relay como um servidor que recebe uma mensagem de um cliente SMTP e a transmite, sem alterar os dados da mensagem exceto o acréscimo de informações de rasto, a outro servidor SMTP tendo em vista um novo relay ou a entrega final. A RFC existe apenas em inglês e não tem nenhuma versão portuguesa oficial, isto é uma reformulação. O protocolo não o exige. É a ausência de verificação que transforma um relay legítimo num open relay. As listas de bloqueio como a XBL da Spamhaus detetam e inscrevem automaticamente os IPs comprometidos ou mal configurados, incluindo open relays. Uma vez listado, o IP passa a ter as suas mensagens filtradas como spam ou rejeitadas pela maioria dos grandes mailbox providers, incluindo as enviadas legitimamente por outros utilizadores do mesmo relay partilhado. Fechar o acesso anónimo e exigir autenticação (credenciais de acesso ou chave de aplicação) elimina este risco na origem.
Quando é que uma empresa precisa de um relay SMTP
Primeiro, o volume: para além de alguns milhares de emails por dia, a maioria dos mailbox providers para o público em geral ou dos servidores internos não especializados atinge um limite ou degrada a deliverability. Depois, a natureza do tráfego: os emails transacionais (confirmação de encomenda, redefinição de palavra-passe, fatura) exigem uma entrega quase imediata e não toleram ser misturados com uma campanha de marketing que, essa, pode esperar várias horas. Um CRM ou um ERP que despoleta envios automatizados acrescenta mais uma exigência: um ponto de entrada SMTP estável, independente da caixa de correio de um colaborador que muda de função ou de palavra-passe.
Segue-se a questão do endereço IP. Um IP partilhado divide a sua reputação com todos os clientes do mesmo relay: um sender descuidado degrada a deliverability de todos os outros, mesmo os que enviam de forma correta. Um IP dedicado isola essa reputação. Constrói-se do zero, o que leva tempo. Dedicado ou partilhado, a reputação do seu endereço IP deve verificar-se regularmente: condiciona diretamente a taxa de chegada à caixa de entrada. Um IP dedicado justifica-se a partir de envios regulares e sustentados, quando a empresa consegue absorver o tempo de construção da reputação.
Relay SMTP ou API de envio: duas lógicas de expedição
O relay SMTP transporta a mensagem através do protocolo histórico, numa ligação que dialoga comando a comando com o servidor remoto. Uma API de envio funciona de forma diferente: a aplicação transmite o conteúdo da mensagem através de um pedido HTTP e recebe em troca um identificador de mensagem e um estado estruturado, utilizável diretamente no código. O relay integra-se sem desenvolvimento, num cliente de email ou num CMS que já saiba falar SMTP. A API exige uma integração técnica. Em troca, devolve eventos em tempo real (abertura, clique, rejeição) que o protocolo SMTP por si só não fornece. Um site WordPress ou um software de contabilidade que precise de enviar uma fatura passa geralmente por um relay. Uma aplicação que reage a cada falha de envio ganha em passar por uma API.
Aumentar o volume sem queimar a reputação do IP
Um IP novo ou pouco utilizado não tem nenhum histórico aos olhos dos grandes mailbox providers. Um envio massivo logo no primeiro dia parece um comportamento de spammer. O warm-up do IP consiste em aumentar o volume progressivamente, começando pelos contactos mais envolvidos, para construir essa reputação antes de atingir o volume-alvo. As boas práticas formalizadas pelo grupo de trabalho antiabuso M3AAWG recomendam uma subida gradual e uma separação clara dos fluxos: o tráfego transacional não segue a mesma curva que a prospeção ou o envio em massa.
Uma progressão realista segue um esquema próximo deste:
- Semana 1: algumas dezenas a algumas centenas de emails por dia, enviados prioritariamente aos recipients mais ativos.
- Semana 2: aumento progressivo do volume, com monitorização do bounce rate e das reclamações em cada patamar.
- Semanas 3 e 4: alargamento a segmentos menos envolvidos, sempre por patamares.
- A partir daí: subida até ao volume-alvo, com um controlo contínuo assim que a reputação estiver estabelecida.
O ritmo é mais importante do que o volume. Dois limiares mantêm a linha durante todo o período. O Gmail fixa um limite a nunca atingir, 0,3% de taxa de reclamações medida através do Postmaster Tools. O limiar recomendado mantém-se abaixo de 0,1% (Google, email sender guidelines). Uma vez ultrapassados os 0,3%, a deliverability mantém-se degradada até a taxa voltar a ficar abaixo desse limiar durante sete dias consecutivos. Um warm-up demasiado rápido faz subir essa taxa antes mesmo de a reputação estar estabelecida.
Autenticar o relay no seu domínio
Um relay que envie em nome do seu domínio deve basear-se numa autenticação alinhada com esse domínio: o SPF deve cobrir o endereço ou o nome do relay, o DKIM deve assinar com uma chave própria do domínio remetente e a política DMARC aplica-se ao resultado de ambos.
Escolher um relay SMTP: os critérios que contam
A natureza do IP fornecido conta em primeiro lugar: dedicado ou partilhado, com a possibilidade de migrar de um para o outro sem ter de reconstruir tudo. O acompanhamento do warm-up pesa quase tanto: um relay que deixa o sender gerir sozinho o aumento de volume transfere um risco que o fornecedor devia, em parte, absorver. Resta o reporting disponibilizado, muitas vezes negligenciado no momento da escolha: o bounce rate e a taxa de reclamações devem continuar consultáveis em tempo real, não apenas numa exportação mensal. O registo das rejeições também deve ficar acessível sem demora. Estes números alimentam depois os seus indicadores de desempenho de email mais amplos.
Uma lista de contactos degradada faz subir a taxa de hard bounce mesmo através do relay mais irrepreensível. A list hygiene precede sempre a escolha do relay. Para comparar soluções de emailing completas em vez de um simples relay técnico, consulte o nosso comparativo de softwares de emailing.
A escolha decide-se antes do envio. O seu relay atual apresenta uma taxa de reclamações abaixo de 0,1% ou já se aproxima dos 0,3% que despoletam a limitação do Gmail?
