Amazon SES, um guia prático com dicas para manter uma boa reputação e entregabilidade de e-mails na AWS

Guia prático de Amazon SES: autenticação SPF/DKIM/DMARC, higiene de lista, monitoramento de bounce e complaint, e reputação do domínio de envio.

Cloud AWS · Publicado em 30 de abril de 2026 · Por Dan Rezende · 8 min de leitura

Na CloudFaster, a gente acompanha o ambiente AWS de vários clientes no dia a dia. E uma coisa que aparece com frequência é o seguinte: o SES tá configurado, o e-mail tá sendo enviado, mas será que está chegando corretamente na inbox? Será que os endereços que estão recebendo são válidos, estão ativos, realmente querem receber aquele conteúdo?

Bounce acumulando sem tratamento, lista nunca higienizada, DMARC publicado com p=none desde o dia da configuração e nunca evoluído, configuration set único pra tudo misturando e-mail transacional com marketing, nenhum alarme, nenhum dashboard.

Resolvi escrever esse guia pra ajudar quem usa o SES a entender o que precisa estar configurado, o que precisa ser monitorado, e o que pode estar silenciosamente prejudicando a reputação do seu domínio de envio.

Autenticação é a base de tudo

Antes de qualquer outra coisa, você precisa garantir que o email que sai do SES está autenticado corretamente. Isso significa SPF, DKIM e DMARC configurados e alinhados.

Pra entender por que isso importa, precisa saber que o DMARC não valida só se o SPF ou o DKIM passaram. Ele valida se o domínio autenticado está alinhado com o domínio que aparece no From: da mensagem. Ou seja, não basta autenticar, precisa autenticar com o domínio certo.

No SES, o DKIM é o ponto principal dessa estratégia. O motivo é simples: o SPF olha pro MAIL FROM, que no SES padrão aponta pra um domínio da própria AWS, não pro seu. Isso faz o SPF passar, mas ficar desalinhado do seu From:. O DKIM, por outro lado, assina a mensagem com o seu domínio e permanece válido mesmo quando a mensagem é encaminhada sem alteração de conteúdo.

O caminho indicado no SES é esse: DKIM ativo sempre, custom MAIL FROM configurado pra alinhar o SPF quando você quiser o pacote completo, e DMARC publicado com evolução gradual da política.

Sobre o DMARC, um erro que eu vejo muito é publicar p=none e nunca mais tocar nisso. O p=none é pra fase de monitoramento, não pra produção estável. Quando você tiver certeza de que todo envio legítimo autentica e alinha corretamente, evolui pra p=quarantine e depois pra p=reject.

; DMARC — comece assim
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; Evolua pra isso quando estiver seguro
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Separe o que é transacional do que é marketing

Esse é um dos erros mais comuns que eu vejo em ambientes que cresceram sem planejamento. Tudo vai pelo mesmo configuration set, pelo mesmo domínio, pelo mesmo pool de IPs. Aí uma campanha de marketing vai mal, a taxa de complaint sobe, e o email de confirmação de cadastro começa a cair no spam.

A solução é direta: subdomínios diferentes e configuration sets diferentes.

txn.example.com    → configuration set: txn-config
mktg.example.com   → configuration set: mktg-config

Com isso, uma campanha que vai mal não derruba o transacional junto. E você consegue enxergar o que tá acontecendo em cada fluxo separado.

Higiene de lista: o maior multiplicador de entregabilidade

A maior parte dos problemas de inbox placement que eu vejo na prática não vem de configuração errada. Vem de lista ruim.

Lista ruim significa: endereços inválidos que geram hard bounce, endereços de pessoas que nunca pediram pra receber o email, endereços de pessoas que pararam de se engajar há meses e nunca foram removidos. Um caso que aparece muito em sistemas legados é o de cadastros sem validação de e-mail no momento do registro, ou bases que nunca passaram por uma limpeza real e têm clientes com dados desatualizados há anos. Esses endereços parecem legítimos no banco de dados, mas na prática já não existem ou pertencem a pessoas que nunca pediram pra receber nada.

O SES tem suppression list nativa. Ative pra bounce e complaint:

aws sesv2 put-account-suppression-attributes \\
  --suppressed-reasons BOUNCE COMPLAINT

Unsubscribe honesto e funcional

Facilitar o unsubscribe parece contraditório, mas é uma das melhores coisas que você pode fazer pela sua reputação. Quando a pessoa não consegue sair da lista facilmente, ela marca como spam. E spam complaint é muito pior pra sua reputação do que um unsubscribe.

Google e Yahoo exigem, pra remetentes de alto volume, one-click unsubscribe e link visível no corpo da mensagem. No SES v2, você consegue implementar isso direto nos headers da API:

"Headers": [
  {
    "Name": "List-Unsubscribe",
    "Value": "<https://example.com/unsubscribe/token>"
  },
  {
    "Name": "List-Unsubscribe-Post",
    "Value": "List-Unsubscribe=One-Click"
  }
]

Monitoramento contínuo: o que você precisa medir

Você não consegue gerenciar o que não mede. E no SES, os dados estão disponíveis, mas você precisa configurar pra receber.

O event publishing é onde você vai buscar os dados. Configure no seu configuration set pra publicar pelo menos: SEND, DELIVERY, BOUNCE, COMPLAINT, DELIVERY_DELAY. Com isso indo pro CloudWatch, você consegue criar dashboards e alarmes.

Os números pra não passar: complaint abaixo de 0,1%, spam rate longe de 0,3%. Hard bounce, quando começar a subir, trate como incidente, não como ruído.

Tem uma coisa que muita gente não sabe: o Gmail não envia complaint data pro SES. O painel do SES não vai mostrar reclamações de usuário Gmail. Pra isso funcionar, você precisa do Google Postmaster Tools, que dá visibilidade de spam rate e reputação de domínio direto do Gmail, de graça.

IP dedicado: quando vale e quando não vale

Essa é uma decisão que muita gente toma cedo demais. IP dedicado não é upgrade automático. É uma responsabilidade.

Em shared IPs, você aproveita a reputação coletiva de uma base grande de remetentes que a AWS gerencia. Não precisa fazer warm-up manual, não precisa se preocupar com delisting em RBL. Pra baixo e médio volume, com lista limpa e autenticação correta, shared IP é a escolha certa.

IP dedicado faz sentido quando o volume é alto e previsível, quando você precisa de isolamento reputacional entre fluxos, e quando você tem capacidade operacional pra gerenciar warm-up e eventuais incidentes de reputação. Porque em IP dedicado, se o seu IP cair numa blacklist, o delisting é responsabilidade sua, não da AWS.

Resiliência: e se a AWS suspender o SES na sua conta?

O SES é altamente disponível, mas tem um risco que pouca gente considera: e se o seu domínio começar a acumular denúncias e a AWS, por segurança, suspender o SES na sua conta? Não é impossível, acontece. E quando acontece, você acorda sem conseguir enviar um e-mail, sem processo de contorno, sem plano B.

A solução que a gente recomenda é ter uma segunda conta AWS com SES já aprovado e em produção ativa, preferencialmente em outra região. Não precisa passar o tráfego todo por ela, mas ela precisa estar pronta: identidades verificadas, DKIM configurado, limites de envio solicitados. Uma conta "quente", esperando.

Já ouviu aquele ditado de quem tem 1? Quem tem 1 não tem nenhum. Quem tem 2, tem 1.

Com isso no lugar, se a conta principal for suspensa, você troca o endpoint SMTP ou a credencial do SDK na aplicação e segue enviando pela conta de backup. Dependendo da maturidade do time, isso vira um processo documentado, com runbook, testado periodicamente. Pra quem precisa de mais resiliência, dá pra ir além: SES ativo em mais de uma região ao mesmo tempo, com roteamento por peso ou por saúde do serviço, multi-região no dia a dia, não só como failover de emergência.

Checklist rápido recomendado

Entregabilidade boa não nasce de um ajuste isolado.
É o resultado de fazer o básico bem feito, de forma consistente.

Se você quer revisar a configuração do SES no seu ambiente, ou tá com problema de entregabilidade e não sabe por onde começar, me chama, a gente aqui na CloudFaster pode te ajudar. 🚀