Há uma pergunta que costuma surgir depois de um incidente: como é que alguém conseguiu enviar um email que parecia vir do diretor financeiro? A resposta desaponta pela simplicidade. O protocolo que transporta o correio eletrónico foi desenhado numa altura em que a confiança entre servidores era a norma, e nada nele impede um remetente de escrever no campo «De» um endereço que não lhe pertence.
O SPF, o DKIM e o DMARC são as três camadas que a indústria construiu para corrigir essa lacuna sem substituir o protocolo. Funcionam através do DNS do domínio e permitem ao servidor destinatário avaliar se a utilização do domínio na mensagem foi autorizada. Não confirmam, por si só, a identidade da pessoa que escreveu o email nem a legitimidade do seu conteúdo.
Este artigo explica o que cada um faz, por que razão nenhum deles é suficiente isoladamente, e qual a ordem sensata para os implementar num domínio que já está em produção — sem interromper o correio legítimo pelo caminho.
- O SPF publica as origens autorizadas, o DKIM assina as mensagens, e o DMARC verifica o alinhamento e comunica o tratamento solicitado quando a validação falha.
- O conceito que liga os três é o alinhamento: a validação tem de estar alinhada com o domínio que o destinatário vê no campo «De». Por omissão basta que partilhem o mesmo domínio organizacional; no modo estrito, têm de ser idênticos.
- A implementação começa sempre pelo inventário das origens de envio. Sem ele, o resto produz falsos positivos.
- O DMARC deve começar em
p=none, com relatórios, e só evoluir depois de os dados confirmarem que o correio legítimo passa. - Autenticação de email não é filtragem de spam. São problemas diferentes.
Porque é possível falsificar um endereço de email
Uma mensagem de correio eletrónico tem dois endereços de remetente. O primeiro, chamado envelope sender ou MAIL FROM, é usado durante a transmissão entre servidores e é para onde seguem as mensagens de erro. O segundo é o cabeçalho From:, aquele que o utilizador vê na sua aplicação de correio.
Estes dois valores podem ser diferentes, e há motivos legítimos para isso — listas de distribuição e serviços de envio em nome de terceiros, por exemplo. O problema é que o protocolo não exige qualquer prova de que quem envia tem autorização para usar o domínio indicado no From:.
Na prática, isso significa que escrever direcao@empresa.pt no campo «De» é tecnicamente trivial. Não requer acesso à caixa de correio, à palavra-passe ou ao servidor da empresa. É esta característica que sustenta a fraude por representação: mensagens que parecem vir de um dirigente e pedem uma transferência urgente ou a alteração de dados bancários de um fornecedor.
Os três mecanismos que se seguem não alteram o protocolo. Acrescentam-lhe informação publicada no DNS, que o destinatário pode consultar para avaliar se a utilização do domínio está autenticada.
O que é o SPF
O SPF (Sender Policy Framework) é uma lista publicada no DNS que indica quais os servidores autorizados a enviar correio em nome do domínio. O destinatário compara o endereço IP de origem com essa lista e conclui se a origem é autorizada.
O registo é publicado como um registo TXT no domínio e tem três partes: a versão, as origens autorizadas e a regra de aplicação. Um registo mínimo para um domínio que envia exclusivamente através do Microsoft 365 tem a seguinte forma:
v=spf1 include:spf.protection.outlook.com -allEste valor é apresentado como exemplo. Um domínio real quase sempre envia correio a partir de mais do que uma origem: plataformas de faturação, sistemas de gestão, ferramentas de newsletter, formulários do sítio Web, impressoras multifunções. Cada uma dessas origens tem de constar do registo, com os valores que o respetivo fornecedor documenta. Copiar um registo sem adaptar tem um resultado previsível: parte do correio legítimo deixa de passar na verificação.
Há três restrições que importa conhecer.
Um único registo SPF por domínio. Publicar dois registos TXT começados por v=spf1 no mesmo domínio invalida a verificação. Quando é necessário acrescentar uma origem, o valor existente é editado, não duplicado. Cada subdomínio, esse sim, tem o seu próprio registo.
Limite de dez consultas de DNS. A avaliação de um registo SPF não pode exigir mais de dez consultas. Cada include: consome pelo menos uma, e alguns fornecedores usam registos encadeados que consomem várias. Ultrapassado o limite, a verificação termina em erro permanente e a mensagem falha o SPF, mesmo vindo de uma origem legítima. Endereços IP indicados diretamente com ip4: ou ip6: não contam para este limite.
A diferença entre ~all e -all. A regra final define o que o destinatário deve concluir sobre origens não listadas. O ~all (softfail) indica que a origem provavelmente não está autorizada, deixando a decisão ao critério do destinatário. O -all (hardfail) afirma que não está autorizada. A Microsoft recomenda -all, por oferecer proteção mais forte contra falsificação e por funcionar melhor em conjunto com o DMARC. A recomendação pressupõe, naturalmente, que o inventário de origens está completo. Alguns sistemas podem ainda aplicar o hard fail do SPF durante a sessão SMTP, antes de avaliarem o DMARC — o que reforça a importância de validar todas as origens antes de publicar -all.
O que é o DKIM
O DKIM (DomainKeys Identified Mail) acrescenta uma assinatura criptográfica às mensagens enviadas. Enquanto o SPF valida a origem da ligação, o DKIM permite verificar a integridade da mensagem e identificar o domínio responsável pela assinatura.
O funcionamento assenta num par de chaves. O servidor de envio assina partes da mensagem — cabeçalhos relevantes e corpo — com uma chave privada, e coloca o resultado num cabeçalho DKIM-Signature. A chave pública correspondente é publicada no DNS. O destinatário obtém a chave pública, verifica a assinatura e confirma duas coisas: que a mensagem foi assinada pelo domínio indicado e que não foi alterada em trânsito.
O seletor é o identificador que permite ao destinatário saber qual das chaves publicadas deve usar. Aparece no cabeçalho da assinatura, no elemento s=, e corresponde a um registo publicado em <seletor>._domainkey no domínio.
No Microsoft 365, a gestão das chaves é feita pela Microsoft. Ao ativar a assinatura DKIM para um domínio, são gerados dois pares de chaves, associados aos seletores selector1 e selector2. Apenas um está ativo de cada vez; o segundo existe para permitir a rotação de chaves sem interrupção. Ambos os registos CNAME têm de ser publicados, mesmo que só um esteja em uso — sem o segundo, a rotação futura falha.
Um ponto que passa frequentemente despercebido: o DKIM não fica ativo por omissão nos domínios personalizados. O domínio inicial .onmicrosoft.com tem assinatura automática, mas qualquer domínio próprio exige publicação dos registos CNAME e ativação explícita no portal Defender ou por PowerShell. Muitas organizações assumem que está tratado porque a migração correu bem e o correio funciona.
Os valores exatos dos CNAME são específicos de cada tenant — o ambiente Microsoft 365 da organização — e devem ser obtidos na página de DKIM do portal Defender. Não são valores que se possam deduzir de forma fiável a partir de exemplos.
O que é o DMARC
O DMARC (Domain-based Message Authentication, Reporting and Conformance) é a camada que dá sentido às duas anteriores. Faz três coisas: exige alinhamento, define uma política e devolve relatórios.
Alinhamento
Este é o conceito central e o que resolve a lacuna do SPF. Não basta que a mensagem passe o SPF ou o DKIM: o domínio autenticado tem de estar alinhado com o domínio apresentado no campo From:. Uma mensagem passa o DMARC se pelo menos uma das seguintes condições se verificar: passa o SPF e o domínio do envelope alinha com o domínio do From:, ou passa o DKIM e o domínio da assinatura alinha com o domínio do From:.
Alinhado não quer dizer necessariamente igual. Por omissão, o DMARC usa alinhamento relaxado: os domínios podem ser diferentes desde que partilhem o mesmo domínio organizacional, como mail.empresa.pt e empresa.pt. O alinhamento estrito, configurado através de aspf=s para o SPF ou adkim=s para o DKIM, exige que os domínios sejam idênticos. O valor por omissão de ambos é r, de relaxed, e na maioria dos ambientes é suficiente.
Falha apenas quando ambas as verificações falham no alinhamento. É por isso que os dois mecanismos funcionam melhor em conjunto: o DKIM tende a sobreviver ao reencaminhamento, desde que o intermediário não altere as partes assinadas da mensagem; o SPF, pelo contrário, costuma falhar quando muda o servidor que efetua a entrega.
Política
O registo é publicado em _dmarc no domínio e indica o que o destinatário deve fazer com as mensagens que falham. O elemento p= assume três valores:
p=none— o domínio não solicita uma ação específica. Serve para observar. Os destinatários podem, ainda assim, aplicar os seus próprios mecanismos de segurança, reputação e filtragem.p=quarantine— solicita que as mensagens que falham sejam tratadas como suspeitas, normalmente encaminhadas para a pasta de correio não solicitado.p=reject— solicita que as mensagens que falham sejam recusadas.
Um registo de monitorização tem a seguinte forma, apresentada como exemplo:
v=DMARC1; p=none; rua=mailto:relatorios-dmarc@exemplo.ptO elemento sp= define a política aplicável aos subdomínios existentes, que de outro modo herdam a política do domínio principal.
O RFC 9989 incorporou também no padrão atual o elemento np=, anteriormente definido de forma experimental no RFC 9091, que define a política aplicável a subdomínios inexistentes. É útil no cenário mais comum numa PME: manter o domínio principal em p=quarantine, onde há listas de distribuição e reencaminhamentos a considerar, e solicitar rejeição para mensagens que usem nomes de subdomínio simplesmente inventados por quem ataca. Na ausência de np=, aplica-se a política de sp= e, se esta também não existir, a de p=.
Vale aqui a mesma ressalva do t=: por ser um elemento novo, sistemas assentes na especificação anterior podem ignorar o np= e aplicar a política de sp= ou de p=. Durante a fase de transição, np=reject não deve ser tomado como universalmente suportado.
Um registo com essa combinação tem a seguinte forma, também apresentada como exemplo:
v=DMARC1; p=quarantine; np=reject; rua=mailto:relatorios-dmarc@exemplo.ptpct= deixou de existir.
A especificação atual do DMARC — RFC 9989, de maio de 2026, que substitui o RFC 7489 — removeu o elemento pct=, depois de a experiência operacional mostrar que a sua aplicação era pouco consistente entre destinatários. No seu lugar existe o elemento t=, de modo de teste: com t=y, o destinatário é convidado a aplicar uma política um nível abaixo da declarada, e t=n é o valor por omissão. Parte da documentação, incluindo a da Microsoft, ainda apresenta exemplos com pct=, por continuar assente na especificação anterior.
Há aqui uma ressalva operacional que importa mais do que parece. Por ser um elemento recente, o suporte a t= não é uniforme, e a própria especificação determina que os elementos desconhecidos têm de ser ignorados. Um sistema assente na versão anterior lê v=DMARC1; p=reject; t=y, ignora o t= e aplica a rejeição tal como está escrita.
Não use, por isso, o t=y como única proteção durante uma transição. Mantenha a progressão explícita por p=none e p=quarantine, apoiada nos relatórios.
Relatórios
O elemento rua= indica o endereço que recebe os relatórios agregados, enviados periodicamente pelos destinatários. Estes relatórios são a parte mais valiosa do DMARC na fase inicial: mostram todas as origens que enviam correio em nome do domínio, incluindo as que a organização desconhecia, e indicam quais passam nas verificações.
Recomenda-se um endereço dedicado para os relatórios, uma vez que o volume pode ser considerável e o formato não se destina a leitura direta — existem serviços especializados na sua interpretação. Note-se ainda que o Microsoft 365 não envia relatórios forenses (ruf), mesmo que exista um endereço válido. Envia relatórios agregados quando o MX do domínio destinatário aponta diretamente para o Microsoft 365; havendo um gateway ou outro sistema antes do Exchange Online, esse comportamento pode não ocorrer.
Como trabalham em conjunto
| Mecanismo | O que valida | Limitação quando utilizado sozinho |
|---|---|---|
| SPF | Se o servidor de origem está autorizado a enviar em nome do domínio do envelope | Não valida o endereço visível no campo «De» e quebra facilmente no reencaminhamento de mensagens |
| DKIM | Se a mensagem foi assinada pelo domínio indicado e não foi alterada em trânsito | Uma assinatura válida de um domínio diferente do apresentado ao utilizador não é, por si, um problema detetável |
| DMARC | Verifica se o SPF ou o DKIM passa com alinhamento face ao domínio do campo «De», e comunica o tratamento solicitado pelo proprietário do domínio | Depende de pelo menos um dos mecanismos — SPF ou DKIM — passar com alinhamento. Configurar ambos melhora a resiliência, sobretudo em reencaminhamentos ou alterações do percurso da mensagem |
Ordem recomendada de implementação
A sequência importa. Aplicada por outra ordem, esta configuração pode bloquear correio legítimo.
1. Inventariar todas as origens de envio. Todos os sistemas que enviam email usando o domínio da empresa: Microsoft 365, plataformas de faturação e ERP, ferramentas de newsletter, CRM, formulários do sítio Web, sistemas de recrutamento, impressoras multifunções, aplicações internas. Este é o passo mais trabalhoso e o mais determinante. Uma origem esquecida transforma-se, mais tarde, num problema de entrega.
2. Corrigir o SPF. Verificar que existe um único registo, que inclui todas as origens identificadas e que se mantém dentro do limite de dez consultas de DNS. Se o limite for um obstáculo, considerar a utilização de subdomínios dedicados para serviços externos.
3. Ativar o DKIM. Publicar os dois registos CNAME e ativar a assinatura para cada domínio personalizado. Confirmar também a assinatura DKIM nos serviços externos que a suportem, configurando-a com o domínio da empresa.
4. Publicar o DMARC com p=none. Incluir um endereço de relatórios em rua=. Nesta fase o domínio não solicita qualquer ação sobre as mensagens que falham — embora os destinatários continuem a aplicar os seus próprios filtros.
5. Analisar os relatórios. Deixar acumular dados durante algumas semanas. Os relatórios revelam origens legítimas em falta no SPF, serviços que não assinam com DKIM e tentativas de utilização abusiva do domínio.
6. Corrigir os serviços desalinhados. Ajustar cada origem legítima até que passe SPF ou DKIM com alinhamento. Alguns serviços exigem configuração adicional; noutros casos, a solução passa por usar um subdomínio dedicado.
7. Evoluir a política, sem destino obrigatório. Depois de corrigir as origens legítimas, evolua para p=quarantine e acompanhe os resultados. A adoção de p=reject deve ser uma decisão específica, baseada no tipo de domínio e nos fluxos existentes: é normalmente mais adequada para domínios sem envio, subdomínios dedicados, ou ambientes em que todas as origens e intermediários estão controlados.
Para o domínio principal de uma PME, com listas de distribuição e reencaminhamentos pelo meio, p=quarantine pode ser uma política de aplicação perfeitamente válida — e não uma etapa provisória a caminho de outra coisa. A especificação atual é explícita quanto aos problemas de interoperabilidade das configurações que levam à rejeição de correio. Mantenha os relatórios ativos em todas as fases e trate os subdomínios separadamente, deixando o domínio principal para último.
Há ainda um motivo externo para não adiar. Os grandes fornecedores de caixa de correio passaram a exigir autenticação a quem envia volumes elevados, e a Microsoft publicou requisitos próprios para remetentes de grande volume dirigidos ao Outlook.com, com alterações posteriores quanto ao tratamento das mensagens que não os cumprem. Se a empresa envia newsletters ou faturação em massa, confirme os requisitos em vigor antes de assumir que o correio continua a ser entregue.
p=reject logo no início, por parecer a opção mais segura. O resultado habitual é o bloqueio de faturas, notificações e newsletters enviadas por serviços legítimos que ainda não estavam alinhados — e a pressão para reverter tudo antes de o problema estar compreendido.
Erros comuns
Vários registos SPF no mesmo domínio. Acontece quando se acrescenta um novo serviço criando um registo adicional em vez de editar o existente. Invalida a verificação para todo o domínio.
Origens de envio esquecidas. A impressora do primeiro andar que envia digitalizações, o sistema de alarme que manda notificações, a ferramenta que a equipa comercial contratou sem informar ninguém. Todas falham assim que a política se torna restritiva.
DKIM não ativado nos domínios personalizados. Como o correio funciona, assume-se que está configurado. Confirme o estado no portal, domínio a domínio.
Passar diretamente para p=reject. Sem uma fase de monitorização e sem análise de relatórios, a probabilidade de bloquear correio legítimo é elevada.
Publicar o DMARC e nunca ler os relatórios. Um registo com p=none não solicita quarentena nem rejeição com base na política DMARC do domínio; serve sobretudo para recolher dados — e os destinatários continuam livres de aplicar os seus próprios filtros e mecanismos de segurança. Sem ninguém a analisar esses dados, fica uma entrada no DNS que dá a sensação de trabalho feito sem produzir efeito prático.
Confundir autenticação com filtragem de spam. São camadas distintas. Uma mensagem pode passar SPF, DKIM e DMARC e ser, ainda assim, uma tentativa de fraude — basta que o atacante autentique corretamente o seu próprio domínio, eventualmente muito parecido com o da empresa. A autenticação impede a falsificação do seu domínio; não avalia a intenção do remetente.
Ignorar subdomínios e domínios não utilizados. Um domínio registado para proteção de marca, sem correio associado, pode ser usado para falsificação. Para domínios que não enviam email, é possível publicar registos que declarem explicitamente essa ausência de origens legítimas.
Como validar a configuração
A validação faz-se em dois planos: a configuração publicada e o resultado real das mensagens.
Do lado da configuração, o portal Microsoft Defender apresenta o estado da assinatura DKIM para cada domínio e assinala registos CNAME em falta ou incorretos. O centro de administração do Microsoft 365 sinaliza problemas nos registos DNS dos domínios verificados.
Do lado das mensagens, o método mais direto é examinar os cabeçalhos de uma mensagem recebida. O cabeçalho Authentication-Results apresenta o resultado das três verificações e o domínio associado a cada uma. Uma leitura típica indica o resultado do SPF com o domínio verificado, o resultado do DKIM com o domínio da assinatura, e o resultado do DMARC com a ação aplicada. Se o DMARC falhar apesar de SPF e DKIM passarem, o problema está quase sempre no alinhamento: a validação ocorreu com um domínio diferente do que aparece no campo «De».
Um teste prático e revelador consiste em enviar uma mensagem a partir de cada origem inventariada no primeiro passo, para uma caixa de correio externa, e examinar os cabeçalhos de cada uma.
Checklist final
- Inventariar todas as origens que enviam correio em nome do domínio, incluindo equipamentos e serviços contratados por outras equipas
- Confirmar que existe um e um só registo SPF por domínio
- Verificar que o registo SPF se mantém dentro do limite de dez consultas de DNS
- Decidir conscientemente entre
~alle-all, depois de o inventário estar completo - Ativar a assinatura DKIM em todos os domínios personalizados e publicar ambos os registos CNAME
- Configurar assinatura DKIM alinhada nos serviços externos que a suportem
- Publicar o registo DMARC com
p=nonee um endereço de relatórios dedicado - Analisar os relatórios agregados durante algumas semanas antes de alterar a política
- Corrigir cada origem legítima que não esteja alinhada
- Evoluir para
p=quarantinee decidir, caso a caso, sep=rejectse justifica para aquele domínio - Definir a política aplicável aos subdomínios existentes, avaliar se é necessária uma política
np=para os inexistentes, e tratar os domínios sem correio associado - Validar os cabeçalhos
Authentication-Resultsa partir de cada origem de envio - Rever a configuração sempre que for contratado um novo serviço que envie email
Conclusão
SPF, DKIM e DMARC não impedem que alguém tente enganar os colaboradores da empresa. Dificultam significativamente a falsificação direta do domínio da empresa e dão aos sistemas destinatários informação para identificar, colocar em quarentena ou rejeitar utilizações não autenticadas. Um atacante continua tecnicamente a conseguir escrever direcao@empresa.pt no campo do remetente, mas os sistemas destinatários passam a ter informação para identificar essa utilização como não autenticada e tratá-la de acordo com a política publicada. Para aumentar a probabilidade de entrega, o atacante terá então de recorrer a um domínio próprio, eventualmente parecido com o da empresa, que tende a ser mais fácil de distinguir — tanto por um filtro como por uma pessoa atenta.
A parte visível parece pequena: um registo SPF, dois registos CNAME para DKIM, um registo DMARC e a ativação da assinatura DKIM no portal. O esforço real está no inventário das origens de envio, na leitura dos relatórios e no alinhamento de serviços de terceiros — e pode ser considerável num domínio com anos de utilização. É essa parte que determina se a implementação corre bem ou se acaba revertida à pressa numa sexta-feira à tarde.
Vale ainda a pena recordar que a autenticação de email é uma camada entre várias. Continua a ser necessária proteção contra phishing, formação das pessoas e — sobretudo em processos financeiros — procedimentos de verificação que não dependam exclusivamente do correio eletrónico.
Fontes oficiais
- RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- Configurar o SPF para ajudar a impedir a falsificação de identidade
- Configurar o DKIM para assinar mensagens no Microsoft 365
- Configurar o DMARC para validar o domínio do remetente
- Outlook's new requirements for high-volume senders
- Guia de implementação do Microsoft Defender for Office 365
Última validação técnica: 26 de julho de 2026, face ao RFC 9989, publicado em maio de 2026, que substituiu o RFC 7489. Os valores concretos dos registos DNS dependem do domínio e dos serviços utilizados. Todos os registos apresentados neste artigo são exemplos e devem ser adaptados antes de qualquer publicação.
