Porque é que o email transacional vai para spam — e como melhorar a entregabilidade

O email transacional vai para spam quase sempre por causa de autenticação mal configurada ou em falta — não porque a palavra "grátis" aparece no seu recibo. Se as suas reposições de palavra-passe, confirmações de encomenda e notificações do formulário de contacto estão a cair na pasta de lixo, a solução quase nunca é reescrever texto; é configurar bem o SPF, o DKIM e o DMARC, enviar a partir de um domínio verificado e garantir que o Return-Path está alinhado. Este é o guia prático de entregabilidade de email transacional que gostaríamos de ter tido, baseado na configuração exata de Resend-sobre-PHP que usamos na Amplified Creations.

Porque é que o email transacional vai para spam

Os servidores de receção de email — Gmail, Outlook, Apple iCloud, tenants empresariais de Microsoft 365 — não leem o seu email e decidem que "parece spam". Primeiro executam um conjunto de verificações automáticas, e as mais importantes são sobre quem você diz que é versus quem você realmente é. Um recibo que falha a autenticação é tratado como potencial spoofing, e o spoofing é exatamente aquilo que os filtros de spam existem para travar. Por isso o recibo de uma caixa de chocolate de 40 € recebe a mesma suspeita que uma tentativa de phishing, e vai parar à pasta de spam.

Os três registos que transportam essa autenticação são o SPF, o DKIM e o DMARC. Vivem no DNS, são aborrecidos de configurar e são a coisa de maior impacto que pode fazer pela entregabilidade. Configure-os mal e até conteúdo perfeito cai no spam. Configure-os bem e até conteúdo medíocre chega à caixa de entrada. Vamos definir cada um tal como um fornecedor de email o usa de facto.

SPF (Sender Policy Framework)

O SPF é um registo DNS TXT no seu domínio que lista quais os servidores autorizados a enviar email por esse domínio. Quando um servidor de receção recebe uma mensagem que diz vir de noreply@oseudominio.com, consulta o registo SPF e verifica se o IP de envio está na lista aprovada. Um registo típico tem este aspeto:

oseudominio.com.  TXT  "v=spf1 include:_spf.resend.com ~all"

O mecanismo include: delega no SPF do seu fornecedor de email (aqui, o do Resend). O ~all no fim é um "soft fail" — tudo o que não está listado é suspeito mas não é rejeitado de imediato. Duas coisas tramam as pessoas: só pode ter um registo SPF por domínio (vários registos é um erro grave, tem de fundir as entradas include:), e o SPF verifica o remetente oculto do envelope (o Return-Path), não o cabeçalho From: que o seu utilizador vê. Mais sobre isto abaixo.

DKIM (DomainKeys Identified Mail)

O DKIM acrescenta uma assinatura criptográfica a cada mensagem. O seu fornecedor guarda uma chave privada e assina o email de saída; você publica a chave pública correspondente no DNS sob um seletor. O servidor de receção obtém essa chave pública, verifica a assinatura e confirma que o corpo da mensagem e os cabeçalhos-chave não foram adulterados em trânsito. O registo DNS parece uma chave longa sob um subdomínio de seletor:

resend._domainkey.oseudominio.com.  TXT  "p=MIGfMA0GCSqGSIb3DQ...chave-publica-longa...AQAB"

A parte resend._domainkey é o seletor — permite a um fornecedor rodar chaves e correr várias em paralelo. O DKIM é o que prova que o email veio genuinamente de alguém que detém a chave do seu domínio, e por isso é a espinha dorsal do registo seguinte.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

O DMARC junta o SPF e o DKIM e diz aos recetores o que fazer quando uma mensagem falha. É um registo TXT em _dmarc.oseudominio.com com uma política:

_dmarc.oseudominio.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@oseudominio.com; adkim=s; aspf=s"

A política p= tem três valores. p=none significa "apenas monitorizar, entregar normalmente mas enviar-me relatórios" — onde se começa. p=quarantine significa "enviar as falhas para spam". p=reject significa "devolver as falhas de imediato" — o mais forte, e onde os remetentes credíveis acabam. O conceito crucial que o DMARC acrescenta é o alinhamento: não basta o SPF ou o DKIM passar, o domínio para o qual passam tem de coincidir com o domínio no cabeçalho From: visível. adkim=s e aspf=s pedem alinhamento estrito. Este requisito de alinhamento é exatamente a razão pela qual acontece o "envia bem a partir do meu script mas o Gmail marca-o" — a autenticação subjacente passa para o domínio do fornecedor, não para o seu.

O endereço rua= é para onde vão os relatórios agregados. Esses relatórios são ouro e falamos deles no fim.

Configuração de SPF DKIM DMARC: as partes que as pessoas falham

Publicar três registos é os 80% fáceis. Os 20% que realmente decidem se chega à caixa de entrada estão abaixo, e é onde gastámos mais horas de depuração.

Use um domínio de envio verificado ou um subdomínio dedicado

Enviar "a partir de" um domínio que não verificou com o seu fornecedor é o caminho mais rápido para o spam, porque nenhuma das autenticações pode alinhar. Um domínio de envio verificado significa que provou o controlo publicando os registos DNS do fornecedor e o fornecedor confirmou que resolvem. Nós vamos um passo mais longe e enviamos email transacional a partir de um subdomínio dedicado — algo como mail.oseudominio.com ou send.oseudominio.com — em vez do domínio nu. Isto isola a reputação: se alguma vez um envio de marketing ou um formulário descontrolado incendiar a reputação do subdomínio de envio, o seu domínio de raiz (e o email que os seus humanos enviam do Gmail) mantém-se limpo. A reputação de um subdomínio é em grande parte separada da do pai.

Return-Path e alinhamento de envelope

Cada email tem na verdade dois endereços "de". Há o cabeçalho From: que o destinatário vê, e há o remetente oculto do envelope — o Return-Path, também chamado MAIL FROM — que o SPF verifica de facto e para onde vão as devoluções. Quando envia através de um fornecedor, o Return-Path assume muitas vezes por defeito o domínio do próprio fornecedor, o que significa que o SPF passa para eles, não para si, e o alinhamento DMARC pode falhar apesar de o "SPF ter passado". A solução é deixar o fornecedor definir um Return-Path no seu próprio subdomínio (o Resend faz isto através dos registos de bounce/feedback que pede para publicar). Quando o Return-Path está no seu domínio e o SPF passa aí, obtém SPF alinhado e o DMARC fica feliz.

DNS reverso, IPs partilhados e reputação

Dois factos de infraestrutura moldam a entregabilidade e em grande parte herda-os do seu fornecedor. Primeiro, o DNS reverso (PTR): o IP de um servidor de email bem comportado resolve de volta para um nome de host, e esse nome de host resolve em frente para o mesmo IP. Email de um IP sem registo PTR é fortemente penalizado. Segundo, IPs partilhados vs dedicados: a maioria dos remetentes, nós incluídos, está num conjunto de IPs partilhados gerido pelo fornecedor. Isso é bom — o conjunto tem reputação já "aquecida" que não conseguiria construir sozinho com pouco volume — mas também significa que um mau ator no mesmo conjunto pode prejudicar a sua entrega. Este é o verdadeiro argumento a favor de um fornecedor credível: policia os seus conjuntos, trata do PTR, aquece IPs e gere os feedback loops para que não tenha de correr um servidor de email na OVH e implorar à Microsoft para o tirar da lista negra.

Conteúdo e noções básicas de gatilhos de spam

O conteúdo importa muito menos do que a autenticação, mas não é zero. Mantenha um rácio texto-imagem sensato (um email só com imagens lê-se como suspeito), inclua sempre uma alternativa em texto simples ao lado do HTML, não ligue a encurtadores ou domínios de má reputação, e não grite em MAIÚSCULAS com filas de pontos de exclamação. Para email genuinamente transacional — uma reposição de palavra-passe, um recibo de encomenda — isto raramente é o problema. Passa a ser o problema no momento em que um template "transacional" começa a transportar marketing, o que leva ao ponto seguinte.

List-Unsubscribe para tudo o que seja em massa

No instante em que o seu email é em massa ou promocional — newsletters, emails "temos saudades suas", qualquer coisa enviada para uma lista — o Gmail e o Yahoo exigem um cabeçalho List-Unsubscribe, e desde 2024 uma versão de um clique (List-Unsubscribe-Post: List-Unsubscribe=One-Click). Email puramente transacional está isento, mas a fronteira é imposta pelo comportamento: se enfiar uma promoção num recibo e as pessoas o marcarem como spam, o seu fluxo transacional paga o preço de reputação. Mantenha transacional e marketing em subdomínios separados e fluxos separados. Nós fazemos.

Como enviamos: Resend sobre PHP na Amplified Creations

Eis o que realmente corremos, honestamente. A Amplified Creations é um pequeno estúdio independente em Leiria e Lisboa; o nosso site é PHP 8.3 renderizado no servidor, em alojamento partilhado OVH, atrás da Cloudflare, com um Cockpit CMS headless e sem passo de build. Para email usamos o Resend com um domínio de envio verificado. A verificação no Resend é o mesmo processo descrito acima: adiciona o domínio no painel deles, ele entrega-lhe um conjunto de registos DNS — a chave DKIM sob um seletor, um include: de SPF e os registos de Return-Path/bounce para o alinhamento de envelope — e você publica-os no seu fornecedor de DNS. Assim que ficam verdes, o email está autenticado e alinhado.

Essa única configuração alimenta duas coisas. A primeira é o formulário de contacto do site: uma submissão dispara um pequeno handler PHP que chama a API do Resend para nos notificar. A segunda é o email transacional dos clientes — as mensagens de ciclo de vida que as nossas aplicações enviam. O exemplo mais claro é a suite Stripe que construímos para a Delicious Diamonds, uma chocolataria de luxo em Leiria. A loja deles trata de encomendas avulsas, encomendas à medida, edições limitadas numeradas à mão e subscrições mensais com pausa, cancelamento e mudança de escalão — tudo movido por webhooks de ciclo de vida do Stripe. Cada um desses eventos que precisa de chegar a um humano — uma confirmação de encomenda, uma subscrição em pausa, um pagamento que precisa de atenção — sai pelo mesmo domínio Resend autenticado. Para além da loja, o nosso trabalho vai de recomendadores de machine learning (Jofit) a captura 3D e VR acessível e médica, mas os princípios de email são idênticos em todo o lado: autenticar bem, alinhar o Return-Path e manter os fluxos separados.

Monitorizar com relatórios agregados DMARC

Assim que o p=none está ativo com um endereço rua=, os recetores começam a enviar-lhe diariamente relatórios agregados em XML. São ilegíveis em bruto, por isso alimente-os a um dashboard de DMARC (há níveis gratuitos). Cada relatório diz-lhe, por fonte de envio, quanto email passou no SPF, passou no DKIM e alinhou para o DMARC. É assim que descobre o plugin de WordPress esquecido ou o CRM que ainda envia como o seu domínio e falha o alinhamento — as coisas que silenciosamente arruinariam a sua reputação. Só quando os relatórios mostram que as suas fontes legítimas estão 100% alinhadas é que aperta a política: p=none para p=quarantine, observe umas duas semanas, depois p=reject. Aperte antes de estar limpo e começará a bloquear os seus próprios recibos.

Versão curta

• Autenticação, não palavras. O email transacional cai no spam porque o SPF, o DKIM ou o DMARC falharam — corrija isso primeiro.
• SPF: um registo TXT que lista os remetentes autorizados; verifica o Return-Path do envelope, não o From: visível.
• DKIM: uma assinatura criptográfica; publique a chave pública sob um seletor como resend._domainkey.
• DMARC: política p=none → quarantine → reject; exige alinhamento entre o domínio de autenticação e o domínio From:.
• Domínio verificado + subdomínio dedicado isola a reputação e deixa os três alinhar.
• Return-Path tem de estar no seu domínio, ou o SPF passa para o fornecedor e o DMARC falha.
• List-Unsubscribe (um clique) é obrigatório para tudo o que seja em massa; mantenha transacional e marketing separados.
• Leia os seus relatórios agregados DMARC antes de apertar para p=reject.

Perguntas frequentes

Porque é que o meu email transacional vai para spam mesmo com conteúdo bom?

Porque a entregabilidade é decidida pela autenticação antes de o conteúdo sequer ser lido. Se o SPF, o DKIM ou o DMARC falham — ou passam mas não alinham com o seu domínio From: visível — o servidor de receção trata a mensagem como possível spoofing e arquiva-a como spam independentemente do que diz. Corrija primeiro a autenticação e o alinhamento.

Preciso dos três, SPF, DKIM e DMARC?

Sim. O SPF e o DKIM provam cada um um aspeto da autenticidade, e o DMARC junta-os com uma regra de alinhamento e diz aos recetores o que fazer em caso de falha. O Gmail e o Yahoo exigem agora, na prática, os três para qualquer volume significativo, por isso trate-os como um conjunto, não como um menu.

Qual é a diferença entre o Return-Path e o cabeçalho From?

O cabeçalho From: é o endereço que o destinatário vê; o Return-Path (remetente do envelope) é o endereço oculto que o SPF verifica e para onde voltam as devoluções. Podem diferir, e essa discrepância é a razão por que "o SPF passou" pode ainda assim falhar o DMARC — o alinhamento exige que o domínio do Return-Path coincida com o domínio do From:. Configure o seu fornecedor para definir o Return-Path no seu próprio domínio.

Como funciona a verificação de domínio no Resend?

Adiciona o seu domínio no painel do Resend e ele dá-lhe registos DNS para publicar: uma chave pública DKIM sob um seletor, um include: de SPF e registos de Return-Path/bounce para o alinhamento. Assim que resolvem e o Resend marca o domínio como verificado, o seu email está assinado e alinhado. Usamos exatamente esta configuração para o nosso formulário de contacto e para o email transacional dos clientes.

O email transacional e o de marketing devem usar o mesmo domínio?

Não — use subdomínios separados para que a reputação fique isolada. Se uma campanha de marketing apanhar queixas de spam, não quer que arraste consigo as suas reposições de palavra-passe e recibos. Um subdomínio transacional dedicado mantém esse fluxo crítico limpo e permite-lhe aplicar-lhe uma política DMARC mais estrita.