Início›Guias›Segurança de e-mail

Segurança de e-mail · Entender

SPF, DKIM e DMARC: o que protegem e o que não protegem

O SPF diz quais servidores podem enviar por um domínio, o DKIM assina a mensagem, o DMARC verifica se um dos dois corresponde ao domínio exibido em “De” e diz o que fazer em caso de falha. Juntos, eles impedem que um desconhecido use exatamente o seu domínio. Eles não leem o texto: um domínio parecido, um nome de exibição enganoso ou uma conta comprometida passam.

Atualizado em outubro de 20266 minFontes oficiais citadas

SPF: quem tem o direito de enviar

A RFC 7208 parte de uma constatação: nada, no protocolo de e-mail, impede um servidor de anunciar qualquer endereço de envio. O SPF permite ao proprietário de um domínio publicar no DNS a lista dos servidores autorizados a enviar em seu nome, e ao servidor que recebe verificar essa autorização.

Dois detalhes mudam tudo:

  • O SPF verifica o endereço de envelope (o do diálogo entre servidores, chamado “MAIL FROM”) e o nome anunciado pelo servidor, não o endereço que o destinatário lê em “De”.
  • O SPF avalia o último servidor que entregou a mensagem. Quando uma mensagem é encaminhada por outro servidor, quem a entrega já não é um servidor autorizado pelo domínio de origem: a verificação pode falhar mesmo que a mensagem seja legítima.

Um domínio publica um único registro SPF. Todas as fontes de envio devem constar nele: e-mail, software de faturamento, ferramenta de newsletter, CRM, copiadora que digitaliza para o e-mail.

DKIM: a mensagem é assinada

Segundo a RFC 6376, o DKIM permite ao proprietário de um domínio signatário assumir parte da responsabilidade por uma mensagem, por meio de uma assinatura criptográfica. A chave pública fica no DNS. Verificar a assinatura comprova que as partes assinadas não mudaram desde a assinatura.

A assinatura viaja com a mensagem. Por isso ela resiste melhor que o SPF a um relay ou a um encaminhamento, desde que esse relay não modifique o assunto ou o corpo. Uma lista de distribuição que acrescenta uma nota no rodapé da mensagem a quebra.

O que o DKIM não faz, segundo a mesma RFC: ele não criptografa a mensagem, uma falha não obriga a rejeitá-la, e o domínio que assina não precisa ser o exibido em “De”. É justamente essa lacuna que o DMARC preenche.

DMARC: o alinhamento e a política

A RFC 7489 define o DMARC como um meio, para o proprietário de um domínio, de expressar uma política no nível do domínio. O mecanismo se baseia no alinhamento: o domínio do endereço exibido em “De” deve corresponder ao domínio validado pelo SPF ou pelo DKIM. Se nenhum dos dois estiver alinhado, o DMARC falha.

O domínio publica então o que deseja:

  • none: nenhuma ação solicitada, apenas observação;
  • quarantine: tratar a mensagem como suspeita;
  • reject: rejeitar a mensagem.

O DMARC também prevê relatórios: relatórios agregados, que resumem quais servidores enviaram em nome do domínio e com qual resultado, e relatórios de falha, mensagem por mensagem. São eles que permitem descobrir uma ferramenta esquecida que envia por você, ou alguém que falsifica o seu domínio.

MecanismoO que ele verificaO que ele não olha
SPFO servidor que entrega a mensagem está autorizado para o domínio de envelopeO endereço exibido, o conteúdo
DKIMA mensagem assinada não foi modificada; um domínio assume a responsabilidade por elaO endereço exibido, a honestidade do conteúdo
DMARCO domínio exibido está alinhado com SPF ou DKIM; política em caso de falhaOs domínios parecidos, o nome de exibição, o texto

O DMARC bloqueia o phishing?

Ele bloqueia parte da falsificação do domínio, não o phishing em geral. A RFC 7489 diz isso explicitamente: o DMARC não trata os nomes de domínio visualmente parecidos, nem o abuso do nome de exibição, e a análise do conteúdo está fora do seu escopo. Ele não pretende resolver todos os problemas das mensagens fraudulentas.

Concretamente, o DMARC não vê:

  • um domínio parecido: o fraudador autentica perfeitamente o próprio domínio, que se parece com o seu;
  • um nome de exibição falsificado: “Departamento de contabilidade” escrevendo de um endereço sem relação;
  • uma conta comprometida que assina corretamente, já que é o servidor verdadeiro que envia;
  • uma mensagem sem relação com o seu domínio: um falso alerta de transportadora chega de um domínio que nada tem a ver com o seu;
  • um domínio sem política: se o domínio imitado publica “none”, o destinatário não tem instrução de rejeição.

Esses casos dependem de outras análises: semelhança dos domínios, reputação, conteúdo, comportamento. Veja spam, phishing, malware e conta comprometida.

Encaminhamentos e listas de distribuição: ARC

Um encaminhamento muitas vezes quebra o SPF, uma lista que modifica a mensagem quebra o DKIM, e o DMARC então falha em uma mensagem legítima. O ARC, descrito na RFC 8617 (status experimental), permite que cada intermediário ateste o resultado de autenticação que constatou. O servidor final pode escolher levá-lo em conta.

Proteger o próprio domínio, filtrar o que chega

São dois assuntos frequentemente confundidos.

  • Proteger o domínio que envia: publicar SPF, DKIM e DMARC para o seu domínio, para que os outros possam recusar as mensagens que o falsificam. Você publica; os destinatários aplicam.
  • Filtrar o que chega: verificar os registros dos outros domínios nas mensagens que você recebe e, depois, aplicar todas as outras análises.

Implantação gradual

  1. Inventário de tudo o que envia em nome do domínio.
  2. Um registro SPF único que autoriza essas fontes; uma assinatura DKIM para cada serviço capaz de assinar.
  3. DMARC em “none”, com um endereço para receber os relatórios.
  4. Leitura dos relatórios durante várias semanas; correção das fontes esquecidas.
  5. Passagem para “quarantine”, depois para “reject” quando todos os envios legítimos estiverem alinhados.

Exemplo, a título de ilustração. Um escritório publica o DMARC em “none” e lê seus primeiros relatórios. Descobre três fontes: o seu e-mail, bem alinhado; o seu software de faturamento, que envia as faturas com o domínio do escritório sem assinatura DKIM; e um servidor desconhecido no exterior que envia centenas de mensagens em seu nome. Ele corrige o software de faturamento, espera um ciclo de relatórios limpo e passa para “quarantine”: os destinatários que aplicam o DMARC passam a tratar as mensagens do servidor desconhecido como suspeitas.

No dia em que se troca de e-mail, esses registros são preparados antes da mudança de MX. O guia migrar um e-mail sem interrupção descreve esse momento; ele não é repetido aqui.

Perguntas frequentes

Uma política DMARC “none” protege?

Não. Ela permite observar graças aos relatórios. A proteção começa com “quarantine” ou “reject”.

Por que uma mensagem legítima falha no DMARC?

Na maioria das vezes: um encaminhamento, uma lista de distribuição, ou um serviço que envia por você sem estar declarado no SPF nem assinar com DKIM.

O nosso e-mail não assina com DKIM: o que fazer?

Um gateway posicionado no caminho dos envios pode assinar no lugar dele. Veja Proteger o e-mail que você já tem.

Onde ler o resultado desses controles em uma mensagem recebida?

Nos cabeçalhos da mensagem. Para o Klytic MTA, veja Ler e exportar uma decisão do filtro.

Onde a Klytic se posiciona

O Klytic MTA trata os dois assuntos, à frente de qualquer e-mail:

  • Essencial e Avançado: controle de SPF, DKIM e MX; verificação DMARC, inclusive para mensagens encaminhadas graças ao ARC; assinatura DKIM dos envios, mesmo que o seu e-mail não faça isso.
  • Avançado: console DMARC, com os relatórios dos seus domínios, alertas e sugestões de correção, para conduzir a passagem gradual para “reject”.

O DMARC é apenas uma camada: o Klytic MTA acrescenta a detecção dos domínios sósias, do nome de exibição e dos cenários de fraude, descrita em falsificação de identidade e fraude do CEO.

Se você usa o Klytic Mail, SPF, DKIM e DMARC são configurados para o seu domínio: é a proteção do domínio que envia. Já o Klytic MTA pode ser contratado com ou sem o Klytic Mail.

Fontes

Consultadas em outubro de 2026.

  • RFC 7208, SPF: o proprietário de um domínio publica os hosts autorizados a usar seu domínio na identidade “MAIL FROM” ou “HELO”, e o receptor verifica essa autorização. rfc-editor.org
  • RFC 6376, DKIM: um domínio assume a responsabilidade por uma mensagem por meio de uma assinatura criptográfica; sem criptografia, sem rejeição obrigatória, domínio signatário podendo ser distinto do autor exibido. rfc-editor.org
  • RFC 7489, DMARC: alinhamento do domínio de “From” com SPF ou DKIM, políticas none, quarantine e reject, relatórios agregados e de falha; domínios visualmente parecidos, nome de exibição e análise do conteúdo fora do escopo. rfc-editor.org
  • RFC 9989 (maio de 2026), que substitui a RFC 7489: mesmos valores de política e mesmas exclusões (domínios parecidos, nome de exibição). rfc-editor.org
  • RFC 8617, ARC (experimental): cadeia de transmissão autenticada; um receptor DMARC pode aceitar as avaliações trazidas por uma cadeia ARC válida. rfc-editor.org
  • Klytic, página Klytic MTA: controles de autenticação, assinatura DKIM de saída e console DMARC das ofertas Essencial e Avançado, opções, modos de implantação, ativação pelo MX. klytic.com

Verificar e assinar, à frente do seu e-mail

O Klytic MTA verifica SPF, DKIM e DMARC na chegada e assina os seus envios.

Falar com um consultor →

Conhecer o Klytic MTA

Oferta de boas-vindas

30 dias de teste gratuito, migração acompanhada

Oferta de teste sem compromisso. Um consultor entra em contato para entender suas necessidades e preparar seu espaço Klytic.