E-mail transacional: SPF, DKIM, DMARC e deliverability para SaaS

Existe um tipo de e-mail que o seu produto simplesmente não pode errar. Não é a newsletter nem a campanha de marketing, é o e-mail transacional: a confirmação de cadastro, o link de recuperação de senha, o recibo da compra, o código de verificação. São mensagens disparadas por uma ação do usuário, esperadas e urgentes. Quando um desses cai na pasta de spam ou nem chega, o estrago é direto: o cliente não consegue entrar, não confirma a conta, abre um chamado no suporte. Para um SaaS, a deliverability desses e-mails é infraestrutura crítica, não um detalhe operacional.

O problema é que entregar e-mail ficou difícil de propósito. Depois de décadas de spam e phishing, os provedores (Gmail, Outlook e afins) desconfiam de tudo por padrão. Um e-mail só chega de forma confiável à caixa de entrada quando o remetente prova, de forma técnica, que é quem diz ser. Essa prova se apoia em três registros: SPF, DKIM e DMARC. Este guia explica cada um e o que mais define se o seu e-mail chega ou não.

E-mail transacional x marketing

Antes de tudo, vale separar os dois tipos, porque eles têm regras e reputações diferentes:

• Transacional: disparado por uma ação individual (cadastro, compra, redefinição de senha). É esperado, tem alta taxa de abertura e não precisa de opção de descadastro. A prioridade é chegar rápido e sempre.
• Marketing: enviado em massa para uma lista, com fins promocionais. Exige consentimento, opção de descadastro e cuidado redobrado com reputação.

A boa prática é separar os fluxos, muitas vezes usando subdomínios de envio diferentes, para que um problema de reputação no marketing não contamine a entrega dos e-mails transacionais críticos.

O trio da autenticação

O coração da deliverability moderna é provar a autenticidade do remetente. Três mecanismos, complementares, fazem isso. Um resumo antes de detalhar:

Registro	O que faz	Pergunta que responde
SPF	Autoriza quais servidores podem enviar pelo domínio	Este servidor tem permissão para enviar?
DKIM	Assina o e-mail criptograficamente	A mensagem é autêntica e não foi alterada?
DMARC	Define a política e o alinhamento	O que fazer se SPF ou DKIM falharem?

SPF (Sender Policy Framework)

O SPF é um registro DNS que lista quais servidores estão autorizados a enviar e-mail em nome do seu domínio. Quando um provedor recebe uma mensagem, ele consulta esse registro e verifica se o servidor de origem está na lista. É como uma lista de convidados na portaria.

exemplo.com  TXT  "v=spf1 include:_spf.provedor.com include:servico.com -all"

O -all no final é importante: ele diz "rejeite qualquer servidor que não esteja nesta lista". Um cuidado comum é não estourar o limite de consultas de DNS do SPF, o que invalida o registro silenciosamente.

DKIM (DomainKeys Identified Mail)

O SPF diz quem pode enviar, mas não protege o conteúdo. O DKIM resolve isso assinando cada mensagem com uma chave criptográfica privada. O provedor de destino verifica a assinatura usando a chave pública publicada no seu DNS. Se bater, prova duas coisas: o e-mail veio mesmo do seu domínio e não foi alterado no caminho.

O DKIM usa criptografia de chave pública, um conceito que também sustenta autenticação moderna e assinaturas digitais em geral. A chave privada fica no servidor de envio; a pública, no DNS, disponível para qualquer receptor validar.

DMARC (Domain-based Message Authentication)

O DMARC é a peça que amarra as outras duas. Ele faz três coisas: define uma política sobre o que fazer quando um e-mail falha na autenticação, garante o alinhamento (que o domínio visível para o usuário bate com o domínio autenticado) e habilita relatórios que mostram quem está enviando em nome do seu domínio, inclusive fraudadores.

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

A política (p) evolui em etapas:

• p=none: só monitora e envia relatórios, sem agir. É por onde se começa, para enxergar o cenário sem risco.
• p=quarantine: manda para o spam o que falhar.
• p=reject: rejeita de vez o que falhar. É o alvo final, que protege sua marca contra spoofing.

A jornada correta é começar em none, analisar os relatórios até ter certeza de que todo o envio legítimo está autenticado, e só então endurecer para quarantine e reject.

Além da autenticação: reputação e conteúdo

Autenticar é necessário, mas não suficiente. Os provedores também avaliam a reputação do seu domínio e IP de envio, além de sinais do próprio conteúdo. Os fatores que mais pesam:

• Reputação de envio: construída ao longo do tempo pelo comportamento. Enviar para endereços inexistentes, gerar muitas reclamações de spam ou disparar picos súbitos derruba a reputação.
• Aquecimento (warm-up): um IP ou domínio novo não deve começar disparando grandes volumes. A reputação se constrói aumentando o volume aos poucos.
• Higiene de lista: remover endereços que dão erro permanente (hard bounce) e os que nunca engajam. Uma lista suja sinaliza remetente descuidado.
• Facilidade de descadastro e respeito às reclamações, monitoradas por loops de feedback dos provedores.
• Conteúdo equilibrado: evitar assunto em caixa alta, excesso de links, imagens sem texto e outras marcas típicas de spam.

Monitorar a deliverability

Deliverability não é "configurou e esqueceu". Ela precisa ser medida continuamente, com atenção às métricas certas:

• Taxa de entrega: quantos e-mails foram aceitos pelo servidor de destino.
• Taxa de bounce: quantos voltaram, separando bounce temporário (soft) de permanente (hard).
• Taxa de reclamação de spam: proporção de destinatários que marcaram como spam. Precisa ficar bem baixa.
• Colocação na caixa de entrada (inbox placement): dos entregues, quantos foram para a caixa principal e não para o spam. É a métrica que realmente importa.

Os relatórios do DMARC são uma fonte valiosa: eles revelam envios não autenticados, o que pode ser tanto um serviço legítimo esquecido quanto um fraudador tentando se passar pelo seu domínio. Monitorá-los é ao mesmo tempo higiene de deliverability e segurança de marca.

Chegar à caixa de entrada é engenharia

O e-mail transacional é uma daquelas peças que ninguém percebe quando funciona e todo mundo percebe quando falha. Garantir que uma redefinição de senha ou um código de verificação chegue em segundos à caixa de entrada exige autenticação correta com SPF, DKIM e DMARC, uma reputação de envio bem cuidada e monitoramento constante. É trabalho de infraestrutura, invisível e essencial, exatamente como deve ser.

Na ConstructorTI, tratamos a entrega de e-mail como parte da engenharia do produto: configuração completa de SPF, DKIM e DMARC, separação de fluxos transacional e de marketing, estratégia de reputação e monitoramento de deliverability com base nos relatórios certos. Se os e-mails críticos do seu SaaS estão caindo no spam ou gerando chamados de suporte, fale com o nosso time e saia da conversa com um plano claro para colocar as suas mensagens na caixa de entrada, de forma confiável.