Explicação dos Métodos de Autenticação de Email: SPF, DKIM, DMARC e Mais (Guia de 2026)

A autenticação de email é uma das partes mais importantes da deliverability de emails e, ao mesmo tempo, uma das mais mal compreendidas.

A maioria dos remetentes sabe que precisa de SPF, DKIM e DMARC, mas poucos entendem o que cada um faz realmente, como funcionam em conjunto ou porque é que um email pode ir parar ao spam mesmo com os três configurados.

Parte da confusão vem de tratar a autenticação como uma solução de deliverability, o que ela não é. A autenticação ajuda os fornecedores de caixa de correio a verificar quem enviou uma mensagem e se é de confiança. Sem ela, os teus emails podem ser rejeitados ou filtrados. Com ela, estás apenas a cumprir um requisito básico.

Neste guia, vais aprender o que cada método de autenticação faz, como trabalham em conjunto, como configurá-los corretamente e os erros comuns que causam falhas de autenticação mesmo quando os registos parecem bem configurados. 

O que é a Autenticação de Email? 

A autenticação de email é um conjunto de métodos que permite a servidores recetores como o Gmail e o Outlook verificar que um email veio genuinamente do domínio que diz ser e não foi falsificado ou alterado durante o envio. 

Funciona através de registos DNS que o domínio remetente publica: 

1. O SPF lista os servidores autorizados a enviar
2. O DKIM adiciona uma assinatura criptográfica que confirma que a mensagem não foi adulterada
3. O DMARC define a política que liga ambos ao endereço 'De' visível e diz aos recetores o que fazer quando uma verificação falha. 

Juntos, estes protocolos confirmam a identidade do remetente, um dos sinais que os fornecedores avaliam antes de decidirem se aceitam, filtram ou rejeitam o correio entrante.

Os 3 Métodos Principais de Autenticação de Email

A autenticação de email baseia-se em três protocolos que funcionam em conjunto para verificar quem está a enviar um email e se essa mensagem é de confiança. Cada um tem um propósito diferente, e perceber como se complementam é essencial para resolver problemas de deliverability e autenticação.

SPF (Sender Policy Framework)

O SPF (Sender Policy Framework) é um método de autenticação de email que utiliza um registo TXT de DNS para especificar quais os servidores e endereços IP autorizados a enviar emails em nome do teu domínio.

Quando um email é recebido, o fornecedor de caixa de correio consulta o registo SPF do domínio de envio e compara o endereço IP do servidor de envio com a lista de remetentes autorizados. Se o servidor estiver autorizado, o SPF passa. Se não estiver, falha.

O objectivo do SPF é confirmar que o servidor que envia o email tem permissão para o fazer em nome desse domínio. Não verifica o conteúdo da mensagem, a reputação, a interacção ou se o email deve chegar à caixa de entrada.

DKIM (DomainKeys Identified Mail)

O DKIM (DomainKeys Identified Mail) é um método de autenticação de email que adiciona uma assinatura criptográfica aos teus emails enviados, utilizando um par de chaves pública e privada, para que os servidores de receção possam confirmar que a mensagem foi assinada pelo teu domínio e não foi alterada durante o envio.

Quando um email é recebido, o fornecedor da caixa de correio procura a chave pública publicada no DNS do teu domínio sob um seletor específico e usa-a para verificar a assinatura adicionada pela tua plataforma de envio. Se a assinatura for válida e a mensagem estiver inalterada, o DKIM passa. Se as chaves não coincidirem ou a mensagem tiver sido alterada, o DKIM falha.

O objetivo do DKIM é confirmar que o email foi assinado por um domínio autorizado na assinatura DKIM e que as partes assinadas da mensagem não foram alteradas após o envio. Por si só, não prova que o domínio From visível coincide com o domínio autenticado. Esse alinhamento é tratado pelo DMARC.

DMARC (e a questão do MAIL FROM vs cabeçalho From:)

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é um método de autenticação de email que utiliza um registo DNS para ligar os resultados de SPF e DKIM ao domínio no teu endereço From: visível, e para indicar aos fornecedores de receção o que fazer quando a autenticação falha.

Quando um email é recebido, o fornecedor da caixa de correio verifica se o domínio que passou no SPF ou DKIM está alinhado com o domínio no endereço From: que o destinatário realmente vê. Se estiverem alinhados, o DMARC passa. Se não estiverem, o DMARC falha e o fornecedor aplica a política que publicaste: p=none (apenas monitorizar), p=quarantine (enviar para spam) ou p=reject (bloquear a mensagem).

O objetivo do DMARC é confirmar que o domínio autenticado coincide com aquele que o teu destinatário vê, o que impede outros de falsificarem o teu domínio, e dar-te controlo sobre a forma como as falhas são tratadas.

Verifica se os teus registos passam nos testes e não apenas se existem.

Uma consulta DNS apenas confirma que um registo está publicado. Não te diz se o SPF e o DKIM passam quando o Gmail e o Outlook recebem o teu email. O SPF Checker e o DKIM Checker gratuitos da MailReach testam de ponta a ponta e detetam problemas de SPF, DKIM, DMARC, blacklist e DNS reverso num único relatório.

BIMI (e porque é opcional para cold outreach em B2B)

BIMI (Brand Indicators for Message Identification) é um padrão de email que exibe o logótipo verificado da tua marca junto às tuas mensagens nas caixas de entrada compatíveis, mas apenas quando o teu domínio estiver a aplicar o DMARC.

Quando um email é recebido, os fornecedores compatíveis verificam se o teu domínio está a aplicar o DMARC (p=quarantine ou p=reject) e consultam um registo BIMI no teu DNS que aponta para o teu logótipo. Se essas condições forem cumpridas, o teu logótipo aparece junto à mensagem. A maioria dos principais fornecedores também exige um Verified Mark Certificate (VMC) que comprove que és dono do logótipo antes de o exibirem.

O objetivo do BIMI é o reconhecimento visual da marca na caixa de entrada, e não o deliverability. Não afeta a reputação de remetente, os teus resultados de autenticação ou se o teu email chega à caixa de entrada. Para cold outreach B2B, é opcional e de baixa prioridade. É uma camada de branding, não uma alavanca de deliverability, por isso, se és um remetente outbound a decidir onde gastar tempo, o BIMI fica quase no fundo da lista.

Como funcionam o SPF, o DKIM e o DMARC em conjunto

O SPF, o DKIM e o DMARC foram criados para funcionar como uma cadeia, em que cada um resolve uma parte diferente do problema de autenticação de email.

• O SPF verifica se o servidor que está a enviar o email tem autorização para o fazer em nome do domínio. 
• O DKIM verifica se a mensagem não foi alterada após ter sido enviada. 
• O DMARC funciona em conjunto com ambos e verifica se o domínio que passou no SPF ou no DKIM corresponde ao domínio que o destinatário vê no campo De (From:).

Um email não precisa de passar no SPF e no DKIM para que o DMARC seja aprovado. Só precisa que um deles passe e esteja alinhado com o domínio visível no campo De (From:). Se nenhum estiver alinhado, o DMARC falha, mesmo que o SPF or DKIM tenham passado individualmente.

É por isso que os problemas de autenticação podem ser confusos. Uma mensagem pode passar no SPF, passar no DKIM e continuar a falhar no DMARC porque os domínios autenticados não coincidem com o endereço do campo De (From:). Por outro lado, uma mensagem pode falhar no SPF mas passar no DMARC se o DKIM passar e estiver alinhado corretamente.

Em conjunto, estas três normas ajudam os fornecedores de caixas de correio a verificar quem enviou o email, se foi modificado durante o envio e se a identidade do remetente é de confiança. Sem estas três a funcionar em conjunto, os fornecedores têm menos confiança na mensagem e têm mais tendência para a filtrar, enviar para o lixo ou rejeitar.

Requisitos dos Fornecedores: Google, Yahoo e Microsoft

Desde fevereiro de 2024, a Google e o Yahoo tornaram a autenticação num requisito básico para remetentes em massa. Os remetentes em massa precisam de SPF e DKIM, de uma política DMARC de pelo menos p=none, de autenticação alinhada, de baixas taxas de queixas de spam e de um processo de cancelamento de subscrição funcional para mensagens de marketing ou subscritas.

A Microsoft também introduziu requisitos para remetentes de alto volume para domínios que enviam mais de 5.000 emails por dia para endereços de consumidores do Outlook.com, incluindo outlook.com, hotmail.com, live.com e msn.com. Estes requisitos incluem a conformidade com o SPF, DKIM e DMARC.

A conclusão prática é simples: mesmo que tecnicamente não ultrapasses todos os limites de envio em massa, a autenticação é agora o mínimo olímpico. Deves ter o SPF, o DKIM e o DMARC configurados corretamente antes de fazeres crescer qualquer envio a sério.

Como Configurar e Verificar a Autenticação de Email (Passo a Passo)

A autenticação de email funciona melhor quando o SPF, o DKIM e o DMARC são configurados em conjunto. Uma vez que cada protocolo complementa os outros, faz todo o sentido configurá-los numa ordem específica.

Passo 1: Identifica as tuas fontes de envio de email

Começa por listar todas as plataformas que enviam emails a usar o teu domínio. Isto normalmente inclui:

• O teu fornecedor de caixas de correio (Google Workspace, Microsoft 365, etc.)
• Plataformas de marketing
• Sistemas de CRM
• Ferramentas de cold outreach
• Plataformas de helpdesk e suporte
• Sistemas de faturação
• Qualquer outra aplicação que envie emails em teu nome

Ter um inventário completo torna mais fácil configurar a autenticação corretamente e evitar deixar de fora remetentes legítimos.

Passo 2: Configura o SPF

Publica um registo SPF no teu DNS que autorize os servidores com permissão para enviar emails pelo teu domínio.

Ao criares o teu registo SPF:

• Publica um único registo SPF TXT para o domínio
• Adiciona todas as plataformas de envio legítimas
• Usa os mecanismos de inclusão recomendados pelo fornecedor sempre que estiverem disponíveis
• Revê o registo sempre que adicionares uma nova ferramenta de envio
• Mantém o registo correto e atualizado

O registo deve incluir todas as fontes de envio legítimas, mantendo-se correto e atualizado à medida que adicionas novas ferramentas.

Passo 3: Configurar o DKIM

Ativa o DKIM para cada plataforma que envie emails em teu nome.

O DKIM permite que os fornecedores recetores verifiquem se uma mensagem não foi alterada após o envio.

Para cada plataforma de email:

• Gera um par de chaves DKIM dentro da plataforma
• Publica a chave pública no DNS
• Usa o seletor fornecido pelo fornecedor
• Ativa a assinatura DKIM para os emails enviados
• Verifica se as assinaturas DKIM passam nas mensagens entregues

A maioria dos fornecedores gera um registo DKIM que publicas no DNS. Assim que estiver configurado, as mensagens enviadas são assinadas automaticamente para que os servidores de receção possam verificar a integridade das mesmas.

Passo 4: Configurar o DMARC

Publica um registo DMARC para definir como os servidores de receção devem lidar com mensagens que falham a autenticação.

Começa com:

• Um registo DMARC publicado em _dmarc.otudominio.com
• Uma política de monitorização (p=none)
• Um endereço de relatórios agregados (rua=)
• Análises regulares de relatórios DMARC

Antes de avançar para a aplicação:

• Confirma que todos os remetentes legítimos estão autenticados
• Resolve falhas de alinhamento
• Valida os resultados de SPF e DKIM em todas as plataformas de envio

A maioria das organizações começa com uma política de monitorização (p=none) para analisar os resultados da autenticação antes de passar a políticas de aplicação mais rigorosas, como p=quarantine ou p=reject.

Passo 5: Verificar os Resultados da Autenticação

Após a configuração, verifica se o SPF, o DKIM e o DMARC estão realmente a passar nas mensagens entregues.

Verifica se:

• O SPF passa nas mensagens entregues
• O DKIM passa nas mensagens entregues
• O DMARC passa e está devidamente alinhado
• A autenticação continua saudável depois de adicionares novas ferramentas ou fornecedores

Um registo DNS por si só apenas confirma que a configuração existe. A verificação confirma que os fornecedores de caixas de correio conseguem autenticar o teu email com sucesso em condições reais de receção.

Verificar no DNS não é a mesma coisa que verificar na caixa de entrada.

Este é o passo que a maioria dos remetentes ignora. O Teste de Deliverability de Email gratuito do MailReach envia o teu email para caixas de entrada de teste nos ambientes da Google, Microsoft e Yahoo, mostrando depois onde vai parar: caixa de entrada, spam ou pastas filtradas específicas, como as Promoções do Gmail. Também recebes os resultados de SPF, DKIM e DMARC da mensagem recebida, além de uma lista prioritária do que deves corrigir primeiro.

Erros Comuns de Autenticação de Email (e Como Resolvê-los)

A maioria das falhas de autenticação de email é causada por pequenos erros de configuração que passam despercebidos até os emails começarem a ir parar ao spam, a falhar as verificações de autenticação ou a ser rejeitados por completo.

Os erros abaixo são os que os remetentes encontram com mais frequência. Perceber como acontecem torna-os muito mais fáceis de identificar, resolver e prevenir antes que afetem a tua deliverability.

O Registo SPF Ultrapassa o Limite de 10 Consultas

O SPF permite um máximo de 10 consultas DNS. Cada plataforma de email que autorizas através de uma instrução include: consome parte desse limite. À medida que vais adicionando mais ferramentas ao longo do tempo, é fácil ultrapassar este teto sem dares por isso.

Quando o limite é excedido, os fornecedores de caixas de correio já não conseguem avaliar totalmente o registo SPF, fazendo com que as verificações de SPF falhem, mesmo que o registo continue a existir no DNS.

Como resolver:

• Faz uma auditoria a todas as plataformas que enviam emails atualmente para o teu domínio.
• Remove instruções include: obsoletas ou que já não uses.
• Consolida serviços de envio sobrepostos sempre que possível.
• Monitoriza a contagem de consultas sempre que adicionares uma nova ferramenta de envio.
• Testa o SPF após cada alteração para confirmar que continua a passar.

Registos DKIM em Falta para Novas Plataformas de Envio

O DKIM é configurado separadamente para cada plataforma de envio. Um registo DKIM que funciona para o Google Workspace não autentica automaticamente o email enviado através do teu CRM, plataforma de outreach, sistema de faturação ou helpdesk.

Isto acontece frequentemente quando ligas uma nova ferramenta e esta começa a enviar logo, mas nunca chegas a concluir a configuração do DKIM. Alguns emails passam na autenticação enquanto outros falham, o que torna este problema difícil de detetar.

Como resolver:

• Cria um registo DKIM para cada plataforma de envio que utilize o teu domínio.
• Publica o seletor exato e a chave pública fornecidos por cada plataforma.
• Verifica o DKIM após a configuração em vez de assumires que o registo está a funcionar.
• Mantém um inventário de todos os sistemas de envio e dos respetivos seletores DKIM.
• Volta a verificar o DKIM sempre que um fornecedor rodar ou atualizar as suas chaves.

Publicar um registo DMARC sem verificar o alinhamento

O DMARC passa apenas quando o SPF ou o DKIM se alinham com o domínio no endereço De: visível.

Um registo pode existir no DNS e continuar a falhar no DMARC se o domínio autenticado não coincidir com o domínio que os destinatários veem.

Como resolver:

• Confirma que o SPF se alinha com o domínio De: visível.
• Confirma que o DKIM assina utilizando o mesmo domínio apresentado no cabeçalho De:.
• Analisa os relatórios DMARC para detetar falhas de alinhamento.
• Testa emails reais para confirmar que o DMARC passa na entrega.
• Resolve os problemas de alinhamento antes de avançares para além de p=none.

Avançar para p=Reject Demasiado Cedo

A implementação do DMARC foi concebida para ser gradual. Passar diretamente para p=reject antes de entender todas as fontes de envio legítimas pode bloquear os emails reais da empresa.

O problema surge habitualmente quando ferramentas esquecidas, sistemas de terceiros ou aplicações internas continuam a enviar correio que não foi devidamente autenticado.

Como resolver:

• Começa com p=none e recolhe relatórios DMARC.
• Identifica todos os sistemas que enviam email através do teu domínio.
• Resolve primeiro as falhas de autenticação e alinhamento.
• Considera p=quarantine ou uma implementação faseada antes de p=reject se quiseres uma transição mais segura.
• Aplica a rejeição apenas quando uma monitorização consistente confirmar que todo o correio legítimo passa.

Confiar Apenas nas Verificações de DNS

Uma consulta de DNS apenas confirma que um registo existe. Não prova que os fornecedores de correio autenticam com sucesso os teus emails quando os recebem.

Isto cria uma falsa sensação de segurança. Está tudo correto no DNS enquanto as mensagens continuam a ir para o spam ou a falhar as verificações de autenticação durante a entrega.

Como resolver:

• Envia emails de teste para caixas de entrada do Gmail e Outlook.
• Verifica os resultados de SPF, DKIM e DMARC na mensagem recebida.
• Testa após cada alteração de DNS ou na plataforma de envio.
• Monitoriza os resultados de autenticação regularmente, e não apenas durante a configuração.
• Usa testes de colocação na caixa de entrada e de autenticação para validar o desempenho no mundo real.

Usar um Subdomínio para Cold Outreach

Muitos remetentes usam um subdomínio para cold outreach assumindo que isso isola totalmente o risco. Embora a separação ajude a nível operacional, os fornecedores de correio continuam a poder associar subdomínios ao domínio principal.

Se o outreach gerar reclamações ou fraco engagement, os sinais de reputação podem afetar outras mensagens associadas à marca.

Como resolver:

• Usa um domínio secundário separado para cold outreach em vez do teu domínio comercial principal. Mantém-no limpo: evita hífens, números e TLDs exóticos, e autentica-o de forma independente antes de começares a enviar.
• Autentica o domínio secundário de forma independente.
• Faz o warmup do domínio de outreach antes de aumentares o volume.
• Mantém o tráfego de marketing, transacional e de outreach separado.
• Protege o teu domínio principal de negócios contra riscos desnecessários para a reputação.

A perseguir listas negras em vez de resolveres a reputação

Uma entrada numa lista negra costuma parecer assustadora, mas a maioria das listas negras públicas tem pouca influência na entrega na caixa de entrada do Gmail e do Outlook. Os fornecedores de email modernos dependem principalmente dos seus próprios sistemas de reputação, sinais de interação e dados de reclamações.

Muitos remetentes passam dias a investigar entradas em listas negras quando o verdadeiro problema é a fraca reputação do remetente.

Como resolver:

• Verifica se a lista negra em questão é realmente utilizada pelos principais fornecedores de email.
• Concentra-te primeiro nas taxas de reclamação, interação e qualidade da lista.
• Melhora a autenticação e as práticas de envio.
• Monitoriza a colocação na caixa de entrada em vez de olhares apenas para o estado nas listas negras.
• Vê as verificações de blacklist como um sinal de diagnóstico, e não como a principal métrica de deliverability.

Autenticação de Email vs Colocação na Caixa de Entrada

Os fornecedores de caixas de correio encaram cada vez mais a autenticação como um requisito básico em vez de um sinal de confiança. À medida que os sistemas de filtragem se tornam mais sofisticados, o fosso entre o correio autenticado e o correio entregue na caixa de entrada vai continuar a crescer. Os fornecedores estão a prestar mais atenção do que nunca à reputação, ao envolvimento, à consistência e ao comportamento de envio.

É por isso que os remetentes mais bem-sucedidos encaram a autenticação de email como parte de um processo contínuo de deliverability. Cada nova plataforma de envio, alteração de domínio, ferramenta de marketing ou campanha de outreach cria outra oportunidade para a autenticação se desalinhar sem que ninguém dê por isso.

O passo seguinte é verificar continuamente se ainda funcionam em condições reais de receção e detetar problemas antes que os fornecedores de caixas de correio o façam.

Cada nova ferramenta, domínio ou campanha é uma oportunidade para o SPF, DKIM ou DMARC ficarem desalinhados sem dares por isso. Executa um teste de deliverability gratuito do MailReach para veres onde os teus emails vão parar hoje, e junta-lhe o email warmup para construíres a reputação de remetente que a autenticação por si só não consegue.

Perguntas Frequentes

Quais são os três principais métodos de autenticação de email? 

SPF, DKIM e DMARC. O SPF lista quais os servidores que podem enviar em nome do teu domínio, o DKIM adiciona uma assinatura que prova que a mensagem não foi alterada, e o DMARC liga ambos ao teu domínio visível De: e diz aos recetores o que fazer em caso de falha.

Preciso de DMARC se só envio a partir do Google Workspace? 

Sim. É recomendado para qualquer remetente e obrigatório para envios em massa. O Google Workspace é a plataforma de onde envia; publicar uma política DMARC é da sua responsabilidade, não algo que o Workspace faça automaticamente. 

Qual é a diferença entre SPF, DKIM e DMARC? 

O SPF autoriza os servidores de envio. O DKIM assina a mensagem para que os recetores possam verificar que não foi alterada. O DMARC define a política e exige o alinhamento entre o que passou e o domínio De: que o seu destinatário vê.

Quanto tempo devo ficar em p=none antes de passar para p=reject? 

Fique em p=none até que os relatórios DMARC mostrem que todos os sistemas legítimos que enviam em seu nome estão contabilizados. Mudar cedo demais arrisca-se a bloquear correio real da empresa.

A autenticação de email melhora a deliverability? 

É obrigatório para competir e não consegue chegar à caixa de entrada sem ele, mas não melhora a colocação na caixa de entrada por si só. A reputação e o conteúdo fazem isso. A autenticação limpa a porta; a reputação e o conteúdo conquistam a caixa de entrada.