Módulo 4 · 4.4
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.comeexample.comestão alinhados;example.comeexample.netnão. - strict (
adkim=souaspf=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:
| Resultado do SPF (Return-Path) | Resultado do DKIM (d=) | DMARC |
|---|---|---|
pass para example.com | sem assinatura | pass (SPF alinhado) |
pass para bounce.mailer.example | pass para mailer.example | fail (ambos aprovados, nenhum alinhado) |
pass para bounce.mailer.example | pass para example.com | pass (DKIM alinhado) |
| fail (reencaminhado) | pass para example.com | pass (o DKIM sobrevive) |
pass para bounce.example.com | nenhum | pass em relaxed, fail em aspf=s |
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
| Etiqueta | Para que serve | Recomendação |
|---|---|---|
rua=mailto:... | Endereço(s) para relatórios agregados, separados por vírgulas | Preencher sempre durante a implementação |
ruf=mailto:... | Endereço para relatórios de erro por mensagem (RFC 9991) | Quase nenhum destinatário os envia, e podem conter dados pessoais. Normalmente, omitir |
sp= | Política para subdomínios existentes | Omitir (aplica-se então p=), a menos que os subdomínios enviem correio de forma diferente |
np= | Política para subdomínios que não existem | np=reject é uma boa adição assim que a sua política principal for rigorosa: ninguém pode então enviar correio a partir de factuur.example.com se esse nome não existir |
adkim=, aspf= | Strict ou relaxed | Manter relaxed |
t=y | Modo de teste: um grau mais brando | Útil na transição para quarantine ou reject |
fo= | Quando são gerados relatórios de erro | Só faz sentido com ruf |
pct=, rf=, ri= | Obsoletas na RFC 9989 | Não utilizar; os destinatários que seguem a nova norma ignoram-nas |
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=nonecomruae leitura dos relatórios,p=quarantine(eventualmente comt=y) e, depois,p=reject. - Utilize
np=rejectpara subdomínios inexistentes assim que a política principal for rigorosa.pct,rferiestã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)