Implementar o DMARC: de none a reject

Módulo 4: Capacidade de entrega: SPF, DKIM e DMARC na prática · Tempo de leitura: 12 minutos

Objetivo de aprendizagem: Após esta lição, saberá explicar como funciona o alinhamento, planear uma implementação do DMARC em fases de p=none até p=reject, escolher as etiquetas certas (rua, sp, np, t) e lidar com as armadilhas conhecidas em redirecionamento e listas de distribuição.

Conceitos-chave: DMARC (RFC 9989), Author Domain (o domínio no De), alinhamento (alignment), relaxed e strict (adkim, aspf), domínio organizacional, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (modo de teste), etiquetas obsoletas pct, rf, ri, listas de distribuição, reescrita do From, ARC

O que o DMARC verifica exatamente

O DMARC responde a uma pergunta para cada mensagem recebida: o SPF ou o DKIM foram aprovados para um domínio associado ao endereço De? O domínio do endereço De chama-se, na norma, o Author Domain. A base do registo está explicada no curso de DNS, lição 4.5. Em maio de 2026 foi publicada a norma revista: RFC 9989, com a RFC 9990 para os relatórios agregados e a RFC 9991 para os relatórios de erro. Os registos existentes com v=DMARC1 continuam válidos.

O alinhamento na prática

"Está associado" chama-se alinhamento (alignment). Existem dois modos:

• relaxed (predefinição): os domínios têm o mesmo domínio organizacional. nieuws.example.com e example.com estão alinhados; example.com e example.net não.
• strict (adkim=s ou aspf=s): os domínios têm de ser exatamente iguais.

Para o SPF, o DMARC compara o domínio do Return-Path com o domínio De. Para o DKIM, o domínio d= de uma assinatura válida. Alguns exemplos para uma mensagem com De: info@example.com:

Mantenha, portanto, adkim e aspf em relaxed, a menos que tenha uma boa razão para o contrário.

Como é que um destinatário sabe qual é o domínio organizacional? Antigamente através da Public Suffix List, uma lista de domínios como .nl, .co.uk e github.io. A RFC 9989 substitui isso por um DNS tree walk: o destinatário procura registos _dmarc do domínio e dos domínios superiores. Para um utilizador comum nada muda; só se nota se trabalhar com registos em subdomínios.

A implementação em quatro fases

O objetivo é p=reject: assim, os destinatários recusam correio que se faça passar por si, o que é a melhor proteção contra faturas falsas e phishing em seu nome. Mas quem passa logo para reject sem conhecer os seus remetentes acaba por recusar as suas próprias faturas. Por isso, esta ordem (a linha de orientação deste curso):

Fase 0: preparação

• Faça o inventário de todos os seus remetentes (lição 4.2).
• Certifique-se de que cada remetente tem SPF ou DKIM alinhado; de preferência DKIM, pois sobrevive ao reencaminhamento.
• Crie um endereço próprio para relatórios, por exemplo dmarc@example.com, ou utilize um serviço de relatórios. Receberá rapidamente alguns relatórios por dia.

Fase 1: medir com p=none

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none não faz nada à mensagem em si. Os destinatários entregam tudo como habitualmente, mas enviam-lhe diariamente um relatório agregado (aggregate report) com todos os servidores que enviaram em nome do seu domínio e se o SPF, o DKIM e o DMARC foram aprovados. Com isto cumpre também o requisito mínimo da Gmail, Yahoo e Microsoft para remetentes em grande volume (lição 5.3).

Deixe isto assim durante pelo menos duas a quatro semanas, e mais tempo se tiver serviços que enviam correio apenas ocasionalmente (um lembrete anual, uma fatura trimestral). Leia os relatórios (lição 4.5) e repare qualquer fonte própria que falhe.

Fase 2: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

O correio que não passa o DMARC vai para a pasta de spam do destinatário. Se, mesmo assim, se esquecer de alguma fonte, essa mensagem não se perde, mas torna-se difícil de encontrar. Se preferir ter mais cautela, adicione primeiro t=y (modo de teste): os destinatários aplicam então uma política um grau mais branda (no caso de quarantine, portanto none), mas nos relatórios vê o que aconteceria. Na RFC 9989, isto substitui a antiga etiqueta pct=.

Observe de novo os relatórios durante algumas semanas.

Fase 3: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

O correio que não passa o DMARC é recusado. O remetente recebe um bounce, por exemplo com o código 5.7.509 na Microsoft e, na Gmail, com uma referência à política DMARC (módulo 6). Continue a acompanhar os relatórios: surgem sempre novos serviços.

Quando pode avançar mais depressa?

Se todo o seu correio passar por um único fornecedor que trata do SPF e do DKIM por si, e nada mais for enviado em nome do seu domínio? Nesse caso, pode aplicar-se de imediato uma política rigorosa. Por isso, algumas empresas de alojamento definem p=reject por predefinição. Se, mais tarde, vier a utilizar um serviço de newsletter ou um programa de contabilidade, volte primeiro, temporariamente, para p=none com um endereço de relatórios, até esse serviço estar bem configurado.

As outras etiquetas

Um endereço de relatórios num domínio diferente (por exemplo, um serviço de relatórios) só funciona se esse domínio der autorização através de um registo como example.com._report._dmarc.rapportdienst.example. Normalmente, é o próprio serviço que trata disso (RFC 9990, capítulo 4).

Armadilhas

Listas de distribuição

Uma lista de distribuição clássica reencaminha a sua mensagem para todos os membros, a partir do seu próprio servidor, e muitas vezes acrescenta [lijst] ao assunto ou um rodapé. Nesse caso, o SPF falha (servidor diferente) e o DKIM falha (mensagem alterada). Com p=reject, os destinatários recusam a sua mensagem enviada para a lista. O software de listas moderno resolve isto reescrevendo o endereço De para o endereço da lista ("Jan via Leden"), ou reencaminhando a mensagem sem alterações. Se utilizar uma lista que não faça isto, verá isso refletido nos seus relatórios.

Reencaminhamento

Ver a lição 3.3: o SPF quebra, o DKIM geralmente sobrevive. Um destinatário pode decidir, através de ARC, confiar num reencaminhador conhecido. Nos relatórios reconhece isto como correio de um servidor desconhecido com DKIM pass e SPF fail; não é motivo para tornar a sua política mais branda.

Dois registos ou um erro de digitação

Dois registos DMARC em _dmarc tornam a política inválida, e um erro de digitação em p= também (p=rejected não existe). Verifique após cada alteração.

Na prática: como se apresenta num painel

Num pacote de alojamento da WebOké, está definido por predefinição v=DMARC1;p=reject, sem endereço de relatórios. Isto é seguro se todo o seu correio passar por esses servidores. Se também enviar correio através de outros serviços, configure para p=none com um endereço rua e percorra as fases. No DirectAdmin, faz isto em Administração de DNS, através do lápis junto ao registo _dmarc (campos Tipo de política de domínio e E-mail agregado (RUA)); n’O meu WebOké, através do assistente de DMARC no separador DNS. Noutros fornecedores, cria um registo TXT com o nome _dmarc e escreve o texto manualmente; o resultado é o mesmo.

Resumo

• O DMARC é aprovado se o SPF ou o DKIM forem aprovados para um domínio alinhado com o domínio De; o alinhamento relaxed aceita subdomínios.
• Implementação: inventário, p=none com rua e leitura dos relatórios, p=quarantine (eventualmente com t=y) e, depois, p=reject.
• Utilize np=reject para subdomínios inexistentes assim que a política principal for rigorosa. pct, rf e ri estão obsoletas.
• As listas de distribuição e o reencaminhamento geram falhas esperadas; o DKIM e o ARC compensam parte delas.
• Apenas um registo em _dmarc, sem erros de digitação.

Quiz

Exercício

Exercício Z4.4: Verificar o DMARC do seu domínio e escolher o passo seguinte. Introduza o seu próprio domínio (ou internet.nl). Introduza o registo DMARC tal como o encontrou, o valor de p= e se contém um endereço rua. Depois, escolha qual é, na sua opinião, a próxima fase da implementação, e porquê. O programa consulta o registo em tempo real, verifica a sintaxe segundo a RFC 9989 (um único registo, p válido, etiquetas conhecidas, etiquetas obsoletas assinaladas como aviso) e coloca as suas respostas ao lado.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; noutros fornecedores o funcionamento é semelhante.

• Curso gratuito de DNS 4.5: DMARC: o que os destinatários devem fazer com e-mails falsos
• Manual DirectAdmin 5.9: Configurar o DMARC
• O que é o DMARC? Explicação em linguagem simples
• Criar registo DMARC no DirectAdmin
• RFC 9989 (DMARC), em particular a secção 4.7 (etiquetas) e o anexo C (alterações desde a RFC 7489)