Por que seus e-mails do Amazon SES caem no spam?
O Amazon SES é um bom serviço de envio que entrega uma mensagem mal configurada à pasta de spam em escala enorme sem hesitar. Ele é deliberadamente neutro: você entrega uma mensagem, ele entrega a mensagem ao destinatário e não opina sobre se o seu domínio merece a caixa de entrada.
Esse design é o motivo de os e-mails do SES caírem no spam por razões que não têm nada a ver com o SES. Três causas cobrem quase todos os casos, e vale verificá-las em ordem, porque a primeira é ao mesmo tempo a mais comum e a menos óbvia.
Causa um: o MAIL FROM padrão quebra o alinhamento DMARC do e-mail
Esta é a falha específica do SES, e ela alcança configurações que parecem perfeitas em todo o resto.
Toda mensagem tem dois endereços From. O que o leitor vê, no cabeçalho From:, e o remetente do envelope invisível em MAIL FROM, que é para onde os bounces vão. O SPF é verificado contra o remetente do envelope, não contra o visível.
Por padrão, o SES define o remetente do envelope como um subdomínio de amazonses.com. Seu destinatário vê isto nos cabeçalhos:
Return-Path: <0100018f2c@eu-west-1.amazonses.com>
From: hello@example.com
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of 0100018f2c@eu-west-1.amazonses.com
designates 54.240.8.1 as permitted sender)
dkim=pass header.i=@example.com
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.comLeia a linha spf=pass com atenção. O SPF passou, para o amazonses.com. Esse domínio não tem nada a ver com example.com, então, para fins de DMARC, o SPF não está alinhado e não contribui com nada. Naquele cabeçalho o DMARC ainda passa, mas só porque o DKIM está fazendo todo o trabalho sozinho.
Isso funciona bem, até que uma mensagem seja encaminhada, um gateway de segurança reescreva algo ou o DKIM falhe por qualquer outro motivo. Nesse ponto você não tem a segunda perna para se apoiar, e a mensagem falha no DMARC por completo.
A correção é um domínio MAIL FROM personalizado: um subdomínio como mail.example.com que você configura na identidade do SES e sustenta com os registros MX e SPF que o SES fornece. Depois disso, o SPF passa para o seu próprio subdomínio, que se alinha ao seu domínio From, e as duas pernas se sustentam.
Faça isto: cole os cabeçalhos brutos de uma mensagem do SES no analisador gratuito de cabeçalhos de e-mail e veja qual domínio a linha spf=pass nomeia. Se aparecer amazonses.com, configure um MAIL FROM personalizado hoje.
Causa dois: reputação de IP compartilhado que você não controla
A menos que você tenha pago por um IP dedicado, seus e-mails do SES saem por um pool compartilhado. A reputação do seu domínio é sua. A reputação do IP é compartilhada com todo mundo que estiver enviando por aquele endereço hoje.
Isso produz um sintoma específico e confuso: seu domínio está limpo em todos os lugares, todos os registros passam, e o e-mail ainda cai no spam em um provedor e em outro não. Esse padrão aponta para o IP, não para você.
Vale deixar claro o que você pode fazer aqui, porque a resposta honesta é “pouco diretamente”. Você não pode limpar um IP que compartilha. O que você pode fazer é confirmar que o problema é realmente o IP antes de procurá-lo na sua própria configuração, e garantir que seus sinais no nível do domínio sejam fortes o bastante para carregar a mensagem apesar de um IP mediano.
Verificar essa divisão é rápido. Uma verificação gratuita de blocklists no seu domínio consulta o domínio e os IPs do seu servidor de e-mail separadamente nas principais listas, então uma listagem em um e não no outro diz qual problema você tem.
O instinto neste ponto costuma ser comprar um IP dedicado. Abaixo de aproximadamente 100,000 mensagens por mês, isso geralmente piora as coisas em vez de melhorar: um IP dedicado não tem reputação até você construir uma, e ela decai em qualquer período de silêncio. O pool compartilhado é o padrão melhor para a maioria dos remetentes, justamente porque está sempre aquecido.
Faça isto: rode a verificação de blocklists e anote se a listagem, se houver, está no domínio ou no IP do servidor de e-mail. Só a primeira é sua para corrigir.
Causa três: a lista e os dois números que a AWS observa
O SES publica um painel de reputação no console com dois números que importam: taxa de bounce e taxa de reclamação. A AWS pede que remetentes de volume mantenham a taxa de bounce abaixo de 5% e a taxa de reclamação abaixo de 0.1%.
Esses são os limites em que a AWS começa a prestar atenção na sua conta. Os provedores de caixa de entrada começam a prestar atenção consideravelmente antes. Uma taxa de bounce de 3% não coloca sua conta do SES em revisão, e com certeza afeta onde o Gmail coloca seu e-mail.
Os dois números decorrem de uma coisa: quem está na sua lista e como chegou lá. Uma lista comprada, um export antigo ou um formulário de cadastro sem etapa de confirmação vão produzir bounces e reclamações que nenhuma configuração de DNS compensa.
Faça isto: abra o account dashboard do SES, anote as taxas de bounce e reclamação de hoje e remova cada hard bounce da sua lista antes do próximo envio.
Verificando a correção
Depois de alterar o MAIL FROM ou o DKIM, espere o TTL do DNS expirar, envie uma mensagem para você mesmo e leia os cabeçalhos de novo. A linha spf=pass deve nomear o seu próprio subdomínio, e o dmarc=pass deve contar com SPF e DKIM em vez de apenas DKIM.
O check gratuito de saúde de e-mail lê seus registros SPF, DKIM, DMARC e MTA-STS publicados direto do DNS junto com o status de blocklists, que é o caminho mais rápido para confirmar que os registros que você configurou no console do SES realmente chegaram à sua zona.
Isso responde por um domínio, no momento em que você pergunta. Aí está a lacuna real.
A configuração do SES não é algo que permanece fixa. Um MAIL FROM personalizado depende de um registro MX que uma migração de DNS pode descartar em silêncio. O DKIM depende de três CNAMEs que uma limpeza bem-intencionada pode remover. A reputação de IP do pool compartilhado muda por causa do envio de outra pessoa, num dia em que você não estava olhando. Nada no SES vai avisar: a chamada de API ainda retorna um message ID, o envio ainda tem sucesso, e o e-mail começa a cair no spam silenciosamente.
Fechar essa lacuna é o que o LitInboxes faz. Cada domínio monitorado é reverificado a cada 6 horas em registros DNS, 8 blocklists de alto sinal em todos os planos e 24 no Pro, relatórios agregados de DMARC e reputação do Google Postmaster, com histórico datado para você ver exatamente quando algo mudou e alerta na mudança em vez de num cronograma. Alertas por e-mail estão em todos os planos; alertas por Slack, Discord e webhook estão no Pro. Há uma demonstração ao vivo se você quiser ver a tela primeiro.
Se o SES não for o problema, o diagnóstico completo de spam percorre as outras causas em ordem de probabilidade.
O checklist
- Leia os cabeçalhos de uma mensagem real do SES e confira qual domínio a linha
spf=passnomeia. - Se nomear
amazonses.com, configure um subdomínio MAIL FROM personalizado e publique os registros MX e SPF que o SES fornece. - Confirme que o Easy DKIM está verificado e que os três CNAMEs resolvem.
- Publique um registro DMARC com
p=nonee um endereçoruae comece a ler os relatórios. - Confira o domínio e os IPs de envio em blocklists separadamente.
- Anote as taxas de bounce e reclamação de hoje no painel do SES.
- Remova cada hard bounce e cada endereço sem engajamento há meses.
- Releia os cabeçalhos depois que o TTL expirar e confirme que o SPF agora se alinha.
Como impedir que e-mails do Amazon SES caiam na pasta de spam
- Configure um domínio MAIL FROM personalizadoNo console do SES, abra a identidade do seu domínio verificado e configure um subdomínio MAIL FROM personalizado, como mail.example.com. Publique os registros MX e SPF que o SES fornece. Sem isso, o SPF passa para o amazonses.com e falha no alinhamento DMARC.
- Confirme que o Easy DKIM está ativado e verificadoPublique os três registros CNAME que o SES fornece e aguarde a identidade aparecer como verificada. O DKIM assinado com o seu próprio domínio é o que mantém o DMARC passando quando uma mensagem é encaminhada.
- Publique um registro DMARC e leia os relatóriosComece com p=none e um endereço rua para ver quais fontes passam no alinhamento. Sem os relatórios, você está apenas adivinhando qual dos seus remetentes está falhando.
- Verifique o painel de reputação do SESAbra o Account dashboard no console do SES. A AWS pede que remetentes de volume mantenham a taxa de bounce abaixo de 5% e a taxa de reclamação abaixo de 0.1%. Acima disso, a entrega piora antes de a AWS tomar qualquer ação.
- Confira seu domínio e seus IPs de envio em blocklistsNo pool compartilhado do SES, a reputação do seu IP está parcialmente fora do seu controle. Confirme se a listagem está no seu domínio, que é seu para corrigir, ou no IP, que não é.
- Limpe a lista antes do próximo envioRemova os hard bounces imediatamente e descarte endereços sem engajamento há meses. As taxas de bounce e reclamação são os dois números em que a AWS realmente age.
Perguntas frequentes
O Amazon SES tem uma má reputação de envio?
Não. O SES é usado por remetentes legítimos muito grandes. O que ele não faz é proteger você da sua própria configuração ou da qualidade da sua lista, e no pool de IP compartilhado seus vizinhos afetam a reputação do seu IP sem afetar a reputação do seu domínio.
Por que o e-mail do SES falha no DMARC quando o SPF passa?
Porque, por padrão, o SES usa amazonses.com como domínio MAIL FROM. O SPF passa para aquele domínio, não para o seu, então ele não se alinha ao seu endereço From. Configurar um subdomínio MAIL FROM personalizado resolve.
Preciso de um IP dedicado no SES?
Normalmente não. Abaixo de aproximadamente 100,000 mensagens por mês, um IP dedicado é um passivo, porque você precisa mantê-lo aquecido e um período de silêncio o danifica. O pool compartilhado é o padrão melhor para a maioria dos remetentes.
Quais taxas de bounce e reclamação a AWS espera?
A AWS pede que remetentes de volume mantenham a taxa de bounce abaixo de 5% e a taxa de reclamação abaixo de 0.1%. Taxas sustentadas acima disso colocam a conta em revisão, e a entrega geralmente piora bem antes desse ponto.