Autenticação e integridade de e-mail: SPF, DKIM e DMARC

Por que autenticação e integridade de e-mail importam

Quando um e-mail chega à caixa de entrada, o cliente de e-mail exibe um “De:” amigável (nome e endereço) que pode ser facilmente falsificado. A infraestrutura de e-mail (SMTP) foi criada em uma época em que a confiança entre servidores era maior, e por isso não exigia, por padrão, provas criptográficas de que o remetente tinha permissão para usar um domínio. Para reduzir falsificação de domínio (spoofing) e aumentar a confiabilidade do ecossistema, surgiram três padrões complementares: SPF, DKIM e DMARC.

Esses mecanismos não “impedem” que alguém envie um e-mail com qualquer texto no campo “De:”, mas permitem que servidores receptores verifiquem se o domínio do remetente autorizou aquele envio e se o conteúdo foi assinado de forma verificável. Na prática, isso afeta: entrega (deliverability), classificação como spam, exibição de avisos de segurança e, em alguns casos, rejeição do e-mail.

Visão geral: o que cada um faz

SPF (Sender Policy Framework)

SPF é uma política publicada em DNS que lista quais servidores (IPs ou serviços) estão autorizados a enviar e-mails em nome de um domínio. O servidor que recebe o e-mail compara o IP do servidor que entregou a mensagem com a política SPF do domínio indicado no envelope (MAIL FROM), também chamado de “Return-Path”. O resultado é um veredito como pass, fail, softfail, neutral ou none.

Pontos importantes: SPF valida o caminho de entrega (quem enviou), não garante integridade do conteúdo e pode “quebrar” com encaminhamentos (forwarding) tradicionais, porque o IP do encaminhador pode não estar autorizado no SPF do domínio original.

DKIM (DomainKeys Identified Mail)

DKIM adiciona uma assinatura criptográfica ao e-mail. O servidor de envio assina partes do cabeçalho e do corpo da mensagem com uma chave privada; o receptor busca a chave pública no DNS do domínio e valida a assinatura. Se a assinatura for válida, o receptor tem evidência de que o e-mail não foi alterado após a assinatura e que o domínio que assinou controla a chave correspondente.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Pontos importantes: DKIM fornece integridade e autenticidade do domínio assinante, mas não garante que o domínio exibido no “De:” seja o mesmo domínio que assinou (isso é tratado por alinhamento no DMARC). Além disso, alterações no corpo (por exemplo, alguns rodapés inseridos por gateways) podem invalidar a assinatura dependendo da configuração.

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

DMARC é a camada de política e governança que conecta SPF e DKIM ao domínio visível ao usuário (o domínio do cabeçalho “From:”). Ele define: (1) como o receptor deve tratar mensagens que falham na autenticação/alinhamento (nenhuma ação, quarentena, rejeição) e (2) como enviar relatórios ao domínio proprietário, ajudando a monitorar abuso e erros de configuração.

O conceito-chave do DMARC é o alinhamento: pelo menos um entre SPF ou DKIM deve passar e estar alinhado com o domínio do “From:”. Alinhamento significa que o domínio autenticado (no SPF: domínio do Return-Path; no DKIM: domínio d= da assinatura) deve ser igual ao domínio do “From:” ou, dependendo do modo, pertencer ao mesmo domínio organizacional.

Como a verificação acontece no recebimento (fluxo simplificado)

• 1) Conexão SMTP: o servidor receptor observa o IP de quem está entregando a mensagem.
• 2) SPF: o receptor consulta o DNS do domínio do envelope (Return-Path) e verifica se o IP está autorizado.
• 3) DKIM: o receptor verifica se há cabeçalho DKIM-Signature, busca a chave pública no DNS (selector + domínio) e valida a assinatura.
• 4) DMARC: o receptor pega o domínio do “From:” (o que o usuário vê) e verifica se SPF e/ou DKIM passaram e estão alinhados com esse domínio. Em seguida aplica a política DMARC (nenhuma ação, quarentena ou rejeição) e pode gerar relatórios.

SPF na prática: como publicar e validar

O registro SPF (TXT) e seus mecanismos

SPF é publicado como um registro TXT no DNS do domínio. Um exemplo simples:

example.com.  IN TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Elementos comuns:

• v=spf1: versão.
• ip4: e ip6:: autoriza IPs específicos.
• include:: inclui a política SPF de um provedor (por exemplo, um serviço de e-mail marketing).
• a e mx: autoriza IPs do registro A do domínio ou dos servidores MX (use com cuidado, pois pode autorizar mais do que o necessário).
• all com qualificador: -all (fail), ~all (softfail), ?all (neutral), +all (pass, inseguro).

Passo a passo: implementar SPF com segurança

• 1) Inventariar fontes de envio: liste todos os sistemas que enviam e-mail usando seu domínio (servidor corporativo, suíte de e-mail, CRM, helpdesk, ferramenta de marketing, sistema de boletos, etc.).
• 2) Identificar como cada fonte envia: algumas enviam diretamente (IP fixo), outras via provedores (exigem include:), outras usam subdomínios dedicados.
• 3) Criar um SPF inicial restritivo, mas viável: comece autorizando apenas o que você tem certeza. Se estiver migrando ou descobrindo fontes, pode iniciar com ~all (softfail) por curto período para observar impactos, mas planeje evoluir para -all.
• 4) Publicar no DNS como um único registro SPF: um domínio deve ter apenas um registro SPF (um único TXT com v=spf1). Múltiplos registros causam comportamento indefinido e falhas.
• 5) Verificar limite de consultas DNS: SPF tem limite prático de 10 consultas DNS (lookups). Muitos include: encadeados podem estourar esse limite e gerar permerror.
• 6) Testar com envios reais: envie e-mails para caixas externas e verifique os cabeçalhos recebidos para ver o resultado SPF.

Erros comuns em SPF

• Autorizar “demais”: usar +all ou mx sem necessidade aumenta a superfície de abuso.
• Esquecer serviços terceirizados: ferramentas legítimas passam a falhar e cair em spam.
• Encaminhamento: e-mails encaminhados podem falhar SPF porque o IP do encaminhador não está no SPF do domínio original. DMARC pode mitigar se DKIM estiver preservado.
• Estouro de lookups: excesso de include: e redirecionamentos SPF.

DKIM na prática: assinatura, seletores e rotação de chaves

Como DKIM aparece no e-mail

Quando DKIM está ativo, o e-mail contém um cabeçalho semelhante a:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; c=relaxed/relaxed; h=from:to:subject:date; bh=...; b=...

Campos relevantes:

• d=: domínio que está assinando.
• s=: selector (identificador da chave). O receptor buscará a chave pública em selector._domainkey.example.com.
• c=: canonicalização (como espaços/quebras são normalizados). relaxed/relaxed é comum e tolera pequenas mudanças de formatação.
• h=: lista de cabeçalhos cobertos pela assinatura.

Passo a passo: habilitar DKIM

• 1) Escolher onde assinar: idealmente, o ponto mais próximo do envio final (MTA do provedor principal), para reduzir alterações após a assinatura.
• 2) Gerar par de chaves: use chaves fortes (hoje, 2048 bits RSA é amplamente recomendado; alguns ambientes suportam Ed25519, mas a compatibilidade varia). Guarde a chave privada com controle de acesso rigoroso.
• 3) Definir um selector: por exemplo s=2026a. Seletores facilitam rotação sem downtime.
• 4) Publicar a chave pública no DNS: crie um TXT em 2026a._domainkey.example.com com o valor fornecido pelo seu servidor/provedor.
• 5) Ativar assinatura no servidor/provedor: configure para assinar e-mails de saída do domínio (ou subdomínio) desejado.
• 6) Testar validação: envie e-mails para destinatários externos e verifique se o resultado DKIM é pass e se o domínio d= é o esperado.
• 7) Planejar rotação: crie um segundo selector (ex.: 2026b), publique a chave, altere a assinatura para o novo selector e, após período de transição, remova o antigo.

Armadilhas frequentes em DKIM

• Assinar com domínio diferente do “From:”: pode passar DKIM, mas falhar DMARC por falta de alinhamento.
• Gateways que modificam mensagens: inserção de banners, disclaimers, reescrita de links e alterações no corpo podem quebrar DKIM. Ajustar canonicalização e revisar onde a modificação ocorre ajuda.
• Chave pública mal publicada: erros de aspas, espaços, registros quebrados em múltiplas strings sem cuidado, ou TTLs longos que atrasam correções.

DMARC na prática: alinhamento, política e relatórios

O que significa alinhamento (com exemplos)

Suponha que o usuário veja From: faturamento@example.com.

• SPF alinhado: o domínio do Return-Path (ex.: bounce@example.com ou example.com) passa SPF e pertence ao mesmo domínio organizacional do “From:”.
• DKIM alinhado: a assinatura DKIM tem d=example.com (ou subdomínio alinhado) e valida.

O DMARC pode operar em modo de alinhamento relaxed (padrão) ou strict:

• Relaxed (r): aceita subdomínios do mesmo domínio organizacional (ex.: mail.example.com alinhado com example.com).
• Strict (s): exige correspondência exata do domínio (ex.: mail.example.com não alinha com example.com).

Estrutura de um registro DMARC

DMARC é publicado como TXT em _dmarc.example.com. Exemplo inicial (monitoramento):

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=r; aspf=r; fo=1; pct=100"

Tags principais:

• p=: política para o domínio (none, quarantine, reject).
• rua=: endereço para relatórios agregados (RUA), normalmente diários, em XML compactado.
• ruf=: relatórios forenses (RUF), evento a evento (cada vez menos suportados por questões de privacidade).
• adkim= e aspf=: alinhamento DKIM e SPF (r ou s).
• pct=: percentual de mensagens às quais aplicar a política (útil para ramp-up).
• fo=: condições para gerar relatórios forenses (quando suportado).

Passo a passo: implantar DMARC sem interromper e-mails legítimos

• 1) Garantir base mínima de SPF e DKIM: antes de aplicar políticas restritivas, assegure que suas fontes legítimas passam SPF e/ou DKIM e que pelo menos um deles alinha com o “From:”.
• 2) Publicar DMARC em modo de monitoramento: comece com p=none e pct=100 para coletar dados sem impactar entrega.
• 3) Coletar e analisar relatórios RUA: identifique quais IPs e serviços estão enviando em nome do domínio, quais passam/falham SPF/DKIM e se há alinhamento. Procure especialmente por fontes legítimas que falham por configuração e por fontes desconhecidas (possível abuso).
• 4) Corrigir fontes legítimas: ajuste SPF (incluir provedores corretos), habilite DKIM nos serviços, e alinhe domínios (por exemplo, configurar o serviço para usar um subdomínio do seu domínio com DKIM alinhado).
• 5) Evoluir para quarentena: após estabilizar, altere para p=quarantine e, se preferir, use pct=25, depois 50, 100, monitorando impacto.
• 6) Evoluir para rejeição: quando a taxa de falhas legítimas estiver controlada, aplique p=reject. Isso reduz significativamente spoofing do seu domínio em provedores que respeitam DMARC.
• 7) Tratar subdomínios: se houver envio por subdomínios, considere sp= (política para subdomínios). Exemplo: sp=reject para bloquear subdomínios não usados.
• 8) Operação contínua: DMARC não é “configurar e esquecer”. Novos fornecedores e mudanças de infraestrutura exigem revisão periódica dos relatórios.

Exemplos de políticas DMARC (modelos)

Monitoramento (início):

v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r; pct=100

Quarentena gradual:

v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; pct=50; adkim=r; aspf=r

Rejeição (maduro):

v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com; adkim=s; aspf=r; pct=100

Observação prática: alinhar em modo estrito (adkim=s ou aspf=s) aumenta segurança, mas pode gerar falsos negativos se seus fluxos usam subdomínios ou provedores que assinam com domínio diferente. Use estrito apenas quando tiver certeza de que todos os envios alinham exatamente.

Como verificar resultados em um e-mail recebido (cabeçalhos)

Em muitos provedores, é possível visualizar “cabeçalhos completos” da mensagem. Procure por:

• Authentication-Results: linha que resume SPF, DKIM e DMARC. Exemplo:

Authentication-Results: mx.destino.com; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

• Return-Path: indica o domínio usado no envelope (SPF avalia isso).
• DKIM-Signature: mostra d= e s= para entender quem assinou e qual selector.

Quando houver falha DMARC, você pode ver algo como:

dmarc=fail (p=reject) header.from=example.com

Isso não significa necessariamente que o e-mail é malicioso, mas indica que, do ponto de vista do domínio do “From:”, não houve autenticação alinhada suficiente. Em ambientes corporativos, isso é um sinal forte para triagem e bloqueio, especialmente se a política do domínio é reject.

Interações com listas, encaminhamento e gateways de segurança

Encaminhamento (forwarding) e SPF

Quando um usuário encaminha e-mails automaticamente (por exemplo, de uma caixa antiga para uma nova), o servidor encaminhador entrega a mensagem ao destino final usando seu próprio IP. SPF tende a falhar porque o IP do encaminhador não está autorizado no SPF do domínio original. Se DKIM permanecer válido e alinhado, DMARC ainda pode passar. Por isso, em muitos cenários, DKIM é a peça que “sobrevive” melhor a encaminhamentos.

Listas de discussão e modificações no corpo

Listas podem alterar o assunto (prefixos), inserir rodapés e reescrever cabeçalhos. Isso pode quebrar DKIM. Para reduzir impacto, algumas listas implementam técnicas como reescrita do “From:” (para um domínio da lista) ou preservação de assinaturas quando possível. Do lado do domínio remetente, uma política DMARC muito restritiva pode fazer com que mensagens legítimas em listas sejam rejeitadas por receptores.

Gateways corporativos (DLP, antivírus, banners)

Ferramentas que inserem banners do tipo “E-mail externo” ou que reescrevem links podem invalidar DKIM. Se sua organização usa esse tipo de gateway, alinhe a arquitetura para que a assinatura DKIM ocorra após as modificações (no último salto antes da Internet) ou ajuste o fluxo para minimizar alterações no corpo.

Boas práticas operacionais (checklist)

• SPF: manter um único registro; usar -all quando estável; evitar mx/a genéricos; controlar lookups; documentar cada include.
• DKIM: chaves 2048 bits; rotação periódica; seletores com nomenclatura e ciclo de vida; assinar no ponto correto; monitorar falhas após mudanças de gateway.
• DMARC: iniciar em p=none; usar relatórios para inventário; corrigir alinhamento; avançar para quarantine e reject; definir política para subdomínios com sp= quando aplicável.
• Governança: ter um processo para aprovar novos fornecedores de envio (marketing, cobrança, suporte) exigindo DKIM alinhado e atualização do SPF antes de entrar em produção.

Exercício prático guiado: do zero ao DMARC em modo monitoramento

Objetivo: publicar SPF e DKIM (se ainda não existirem) e ativar DMARC em p=none para mapear envios legítimos e tentativas de abuso.

Passo 1: mapear emissores

• Liste todos os sistemas que enviam e-mail com seu domínio no “From:”.
• Para cada sistema, registre: provedor, domínio usado no From, se há subdomínio dedicado, e como autentica (SPF/DKIM disponíveis).

Passo 2: publicar/ajustar SPF

• Crie um registro TXT SPF único com os IPs e include: necessários.
• Evite começar com permissões amplas; prefira autorizar apenas o que está no inventário.

Passo 3: habilitar DKIM nos provedores

• Para cada provedor (suíte de e-mail, marketing, helpdesk), habilite DKIM e publique os seletores no DNS.
• Garanta que o domínio d= usado pelo provedor seja o seu domínio (ou subdomínio) para permitir alinhamento DMARC.

Passo 4: publicar DMARC (p=none)

• Crie um endereço dedicado para receber relatórios (ex.: dmarc-rua@seu-dominio).
• Publique o TXT em _dmarc.seu-dominio com p=none e rua=.

Passo 5: validar com envios e leitura de cabeçalhos

• Envie e-mails de cada sistema para uma caixa externa de teste.
• Abra os cabeçalhos e confirme: spf=pass e/ou dkim=pass e dmarc=pass com header.from correto.

Passo 6: interpretar relatórios agregados (RUA)

Relatórios RUA chegam como arquivos XML (geralmente compactados). O que procurar:

• Fontes por IP: IPs que enviam em nome do seu domínio.
• Volume: quantidade de mensagens por fonte (ajuda a priorizar).
• Resultados: percentuais de SPF/DKIM pass/fail e alinhamento.
• Desconhecidos: IPs que não pertencem a seus provedores (potencial spoofing).

Com base nisso, ajuste SPF/DKIM e, quando a taxa de falhas legítimas estiver baixa e explicada, planeje a transição para quarantine e depois reject.