Exemplo de registo DMARC: modelos para todas as políticas

Eis o registo DMARC mais simples que funciona:

Publique-o como um registo TXT em _dmarc.yourdomain.com. E já está. O seu domínio tem agora um registo DMARC válido que cumpre os requisitos mínimos do Google, do Yahoo e da Microsoft.

Se estiver com pressa, esse registo é tudo o que precisa neste momento. Volte ao resto deste guia quando estiver pronto para compreender o que cada tag faz, como adotar políticas mais rigorosas sem comprometer o funcionamento do seu e-mail e por que razão o DMARC pode ainda assim falhar, mesmo quando o SPF e o DKIM são ambos aprovados.

Para todos os outros: vamos explicar o que o registo DMARC realmente significa, o que cada nível de política implica, o erro de alinhamento que causa problemas à maioria dos remetentes e como o DMARC se enquadra na vossa configuração mais ampla de entregabilidade enquanto remetentes B2B.

O registo DMARC mais simples (e o que cada parte faz)

Um registo DMARC é um único registo TXT do DNS publicado num subdomínio específico do seu domínio:

O registo útil mais simples tem o seguinte aspeto:

Três partes. É tudo o que precisas para começares.

v=DMARC1

Isto define a versão. Todos os registos DMARC têm de começar por isto. Tem de aparecer em primeiro lugar, exatamente como está escrito. Não pode haver nada antes.

p=nenhum

Esta é a política. Indica aos servidores de correio de destino o que fazer com as mensagens que não cumprem a verificação DMARC. Com p=none, a resposta é: nada. O correio circula normalmente. Recolhem-se dados. Nenhum e-mail é bloqueado ou filtrado devido a este registo.

É precisamente por isso que é o ponto de partida certo. Estás a ativar a monitorização sem alterar a entrega.

rua=mailto:dmarc@yourdomain.com

Isto indica aos fornecedores de caixas de correio para onde devem enviar os seus relatórios DMARC agregados — resumos diários em XML que mostram quais os sistemas que estão a enviar e-mails utilizando o seu domínio e se estão a passar na autenticação. Substitua o endereço por um que verifique efetivamente.

Sem o «rua=», não tens visibilidade. O registo funciona, mas estás a avançar às cegas.

Exemplos de registos DMARC por política

Cada registo DMARC contém uma etiqueta de política (p=) que indica aos servidores recetores o que fazer quando um e-mail não passa na autenticação. Existem três opções. Eis como cada uma delas se apresenta e quando deve ser utilizada. Para uma análise mais aprofundada sobre como o SPF, o DKIM e o DMARC funcionam em conjunto, consulte o nosso guia sobre como implementar o SPF, o DKIM e o DMARC.

p=nenhum - Modo de monitorização

Não é tomada qualquer medida relativamente às mensagens com falha. O envio de e-mails continua a decorrer normalmente. Recebe relatórios diários que indicam todos os sistemas que enviam e-mails utilizando o seu domínio, se estão a passar na autenticação e de onde provêm as falhas.

Utilize p=none quando:

• Está a configurar o DMARC pela primeira vez
• Ainda não identificou todos os serviços que enviam e-mails em seu nome
• É importante ter visibilidade antes de intervir no fluxo de e-mails

Este é também o mínimo exigido pela Google e pela Yahoo para remetentes em massa (mais de 5 000 e-mails por dia) e pela Microsoft, a partir de maio de 2025, para e-mails enviados para endereços do Outlook, Hotmail e Live.

p = quarentena - Aplicação cautelosa

As mensagens com falha são consideradas suspeitas. A maioria dos servidores de receção encaminha-as para a pasta de spam ou lixo eletrónico, em vez de as bloquear diretamente.

Utilize p=quarentena quando:

• O SPF e o DKIM estão configurados corretamente em todas as suas plataformas de envio
• Os relatórios DMARC mostram que os remetentes legítimos estão a passar na autenticação de forma consistente
• Quer proteção contra a falsificação de endereços sem o risco de rejeição total

p=rejeitar - Aplicação integral

As mensagens com erros são rejeitadas antes de chegarem ao destinatário. Esta é a proteção mais eficaz contra a falsificação de identidade disponível.

Utilize p=rejeitar apenas quando:

• Há semanas ou meses que tem vindo a acompanhar os relatórios DMARC
• Todas as fontes de envio legítimas são identificadas e autenticadas
• A conformidade com SPF, DKIM e DMARC é garantida de forma consistente em todos os seus remetentes
• Têm um processo em curso para monitorizar novas ferramentas antes de estas serem enviadas

Por que é que o DMARC falha mesmo quando o SPF e o DKIM são ambos aprovados

Este é o problema mais comum relacionado com o DMARC que observamos, e é aquele que os concorrentes ou escondem num apêndice ou ignoram por completo. Por isso, vamos abordá-lo diretamente.

Não basta que o SPF e o DKIM sejam aprovados. Para que o DMARC seja aprovado, pelo menos um desses resultados também tem de corresponder ao domínio que os vossos destinatários vêem no endereço «De:».

Eis o que significa «alinhamento» na prática:

• Alinhamento SPF: o domínio indicado no campo «Return-Path» do e-mail (o remetente do envelope) deve corresponder ao domínio indicado no endereço «From:» visível
• Alinhamento DKIM: o domínio especificado na assinatura DKIM (etiqueta «d=») deve corresponder ao domínio no endereço «From:» visível

O fator desencadeante mais comum: liga-se um CRM, um serviço de assistência ao cliente, uma ferramenta de contacto não solicitado ou uma plataforma de marketing. Essa plataforma envia e-mails utilizando o seu domínio no campo «De:», mas, nos bastidores, autentica-se através do seu próprio domínio. O SPF e o DKIM são validados para o domínio da plataforma. No entanto, não correspondem ao seu domínio «De:». O DMARC falha.

Vemos isto acontecer constantemente quando as equipas adicionam novas ferramentas sem atualizar a sua configuração de DNS. A solução consiste em configurar cada plataforma de envio para que se autentique especificamente no seu domínio — e não na sua própria infraestrutura partilhada.

Um registo DKIM por prestador de serviços de e-mail (ESP), e não por ferramenta. Se um ESP enviar e-mails para várias ferramentas da sua pilha, necessita de uma entrada DKIM para esse ESP, configurada para assinar com o seu domínio.

Como diagnosticar um problema de alinhamento:

• Abrir um e-mail recebido e visualizar os cabeçalhos da mensagem original
• Observe o cabeçalho «Authentication-Results» — este apresenta os resultados do SPF, do DKIM e do DMARC, bem como o estado de conformidade
• Verifique se o domínio autenticado corresponde ao seu domínio «De:»
• Analise os seus relatórios agregados do DMARC para identificar padrões de falhas de conformidade
• Faça um teste real de colocação na caixa de entrada com o Teste de Spam gratuito da MailReach para ver os resultados da autenticação em condições reais de receção

Se estiver a verificar falhas no DMARC que não fazem sentido, o nosso guia sobre como resolver falhas no DMARC explica as causas específicas e as soluções.

Exemplos de registos DMARC para casos especiais

A maioria dos domínios pode partir do exemplo básico «p=none» acima. No entanto, há algumas situações que exigem uma abordagem diferente.

Domínios estacionados e domínios que não enviam e-mails

Se um domínio nunca enviar e-mails — domínios estacionados, registos defensivos, domínios de proteção de marca —, o registo DMARC adequado é uma rejeição definitiva, sem necessidade de um endereço de notificação:

Isto indica a todos os fornecedores de serviços de e-mail que rejeitem qualquer e-mail que afirme ter origem neste domínio. Uma vez que nunca deveria haver qualquer e-mail legítimo proveniente deste domínio, não há risco de interferir com a correspondência verdadeira.

Domínios secundários para o envio de e-mails não solicitados no âmbito B2B

Este é o caso de utilização que a maioria dos guias sobre o DMARC ignora por completo.

Se realiza campanhas de contacto não solicitado no setor B2B, deve utilizar domínios secundários, e não subdomínios do seu domínio principal. Os subdomínios partilham a reputação com o domínio principal. Um problema de entregabilidade num subdomínio afeta também o seu domínio principal. Os domínios secundários (suaempresa.co, suaempresa.io) são completamente independentes e constroem a sua própria reputação de forma autónoma.

Opte por extensões conhecidas: .com, .co, .io. Evite TLDs pouco comuns. Estes suscitam desconfiança antes mesmo de o seu e-mail chegar ao destinatário.

Cada domínio secundário necessita da sua própria configuração completa de autenticação:

• Um registo SPF específico que enumera os remetentes autorizados
• Chaves DKIM configuradas por ESP para esse domínio
• O seu próprio registo DMARC
• O seu próprio processo de aquecimento para construir a reputação do remetente a partir do zero

No que diz respeito à abordagem direta B2B, o DMARC é apenas a camada de autenticação. É a camada de reputação que, na verdade, faz com que os e-mails passem da pasta de spam para a caixa de entrada. Descubra como o serviço «email warmup » constrói a reputação do remetente de que os seus domínios secundários necessitam.

Proteger subdomínios com a tag sp=

Por predefinição, os subdomínios herdam a política DMARC do domínio pai. Se pretender um controlo explícito, utilize a etiqueta sp=:

p= aplica-se ao domínio da sua organização. sp= aplica-se a todos os subdomínios. Se tiver subdomínios não utilizados que nunca devam enviar e-mails, bloqueá-los com sp=reject impede que sejam explorados para fins de falsificação de identidade.

Como passar de «p=none» para «Enforcement» sem afetar o seu correio eletrónico

A publicação do registo DMARC demora alguns minutos. A implementação demora semanas. As equipas que enfrentam dificuldades são, quase sempre, aquelas que ignoram a fase de monitorização e só descobrem que faltam remetentes depois de os e-mails legítimos começarem a ser devolvidos.

Eis a sequência que funciona:

Passo 1: Publicar p=none e começar a recolher relatórios

Deixe isto assim durante, pelo menos, duas a quatro semanas. Verifique se os relatórios estão a chegar. Analise-os.

Passo 2: Identifique todos os sistemas que enviam e-mails em nome do seu domínio

É aqui que a maioria das organizações fica surpreendida. Para além do seu principal fornecedor de e-mail, verifique:

• Plataformas de CRM e ferramentas de envolvimento de vendas
• Plataformas de automatização de marketing e de newsletters
• Sistemas de assistência técnica e de gestão de tickets
• Software de faturação e cobrança
• Aplicações internas e notificações automáticas
• Ferramentas de abordagem a clientes potenciais

Os relatórios DMARC são, muitas vezes, o primeiro local onde as equipas descobrem sistemas de envio cuja existência tinham esquecido.

Passo 3: Definir a autenticação e o alinhamento para cada remetente

Para cada plataforma de envio, encontrará:

• Confirme se o SPF está configurado e se o endereço IP de envio está autorizado
• Publique registos DKIM e ative a assinatura especificamente para o seu domínio
• Verifique se o domínio autenticado corresponde ao seu endereço «De:»
• Confirme os resultados nos seus relatórios DMARC antes de prosseguir

Passo 4: Passar para p=quarentena

Só mude para aqui depois de os seus relatórios indicarem que a autenticação está correta para todos os seus remetentes. Continue a monitorizar. Esteja atento a qualquer e-mail legítimo que vá parar à pasta de lixo eletrónico.

Passo 5: Passar para p = rejeitar (quando as provas o justifiquem)

Só se deve passar para o estado «p=rejeitar» após meses de relatórios sem incidentes, com todos os remetentes verificados, todos os problemas de alinhamento resolvidos e um processo em vigor para avaliar novas ferramentas antes de estas começarem a enviar mensagens.

Uma nota sobre a etiqueta pct=: poderá encontrar registos DMARC que utilizam pct=10 ou pct=25 para aplicar a aplicação da política apenas a uma percentagem das mensagens. As orientações atuais desaconselham a utilização desta opção, uma vez que os fornecedores de caixas de correio não a implementam de forma consistente. Uma implementação faseada, passando por p=none, p=quarantine e p=reject, é mais fiável.

Etiquetas de relatório DMARC: O que a «rua» e a «ruf» realmente fazem

Os relatórios DMARC permitem-lhe verificar o que está a acontecer depois de o seu registo estar ativo. Sem a funcionalidade de relatórios ativada, pode aplicar políticas, mas não saberá quais os sistemas que estão a passar, a falhar ou a tentar enviar e-mails utilizando o seu domínio.

rua= (Relatórios agregados)

Os relatórios agregados são resumos diários em formato XML enviados pelos fornecedores de caixas de correio participantes. Mostram quem está a enviar e-mails utilizando o seu domínio, quais os endereços IP envolvidos e se estes estão a ser aprovados ou reprovados nas verificações de SPF, DKIM e DMARC.

É este que precisas. Para a maioria das organizações, basta apenas o «rua=».

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Configure-o para uma caixa de correio dedicada que vá realmente monitorizar. Os fornecedores enviam normalmente relatórios uma vez por dia. Deve contar com ficheiros XML que exigem uma análise manual ou uma ferramenta de relatórios para serem lidos facilmente.

ruf= (Relatórios forenses / de avarias)

Os relatórios forenses contêm detalhes sobre falhas de autenticação individuais. São opcionais, não são enviados de forma sistemática por todos os fornecedores e suscitam questões de privacidade em algumas regiões. Para a maioria dos remetentes, a configuração correta consiste apenas no parâmetro «rua=».

Endereços para envio de relatórios externos

Se o seu endereço rua= utilizar um domínio diferente do seu domínio de envio, o domínio de receção deve publicar um registo DNS que o autorize a receber relatórios em seu nome. Sem isso, os relatórios poderão não ser entregues — sem qualquer aviso.

Verifique sempre se os relatórios estão a chegar alguns dias após a publicação do seu registo DMARC. Caso contrário, verifique primeiro este requisito de autorização.

Por que razão o DMARC, por si só, não resolve o problema da entrega na caixa de entrada

O DMARC é necessário. Mas não é suficiente.

O Google, o Yahoo e a Microsoft utilizam o alinhamento entre SPF, DKIM e DMARC para determinar se uma mensagem está devidamente autenticada. Para remetentes com volumes elevados, esta camada de autenticação é agora um requisito mínimo. Sem ela, é muito mais provável que os seus e-mails sejam enviados para a pasta de lixo eletrónico, rejeitados ou considerados suspeitos antes mesmo de o conteúdo e a reputação serem avaliados. Mas isso não garante que cheguem à caixa de entrada. Essa decisão assenta em três pilares:

• Configuração do envio (autenticação): SPF, DKIM e DMARC — O DMARC está aqui
• Reputação do remetente: construída a partir de sinais reais de interação ao longo do tempo, tais como a abertura dos seus e-mails pelos destinatários no Gmail ou no Outlook, respostas, interações positivas na caixa de correio, baixo número de reclamações de spam e colocação consistente na caixa de entrada
• Conteúdo do e-mail: estrutura, links, palavras que podem ser identificadas como spam e como as suas mensagens são interpretadas pelos filtros

A autenticação é o mínimo indispensável. É o que te permite entrar no jogo. A reputação é o que faz com que os teus e-mails passem da pasta de spam para a caixa de entrada.

No que diz respeito especificamente ao contacto não solicitado no âmbito B2B, isto é extremamente importante. Estás a enviar mensagens a pessoas que nunca ouviram falar de ti. Não existe qualquer relação prévia, nem histórico de interação, nem reconhecimento da marca junto do fornecedor da caixa de entrada dessas pessoas. Um registo DMARC limpo indica aos fornecedores que o teu e-mail é legitimamente enviado por ti. No entanto, isso não lhes diz, de forma alguma, que vale a pena ler o teu e-mail.

É por isso que todos os domínios de divulgação secundários precisam de um processo de aquecimento — não basta apenas a autenticação. O MailReach melhora a sua reputação de remetente através de interações positivas e significativas com uma rede de mais de 30 000 caixas de entrada reais do Google Workspace e do Microsoft 365. É a camada de reputação que funciona em conjunto com a autenticação para garantir que os seus e-mails cheguem efetivamente à caixa de entrada. Veja como funciona o email warmup e por que razão a qualidade da rede é o que distingue um processo de aquecimento eficaz dos demais.

Perguntas frequentes

Qual é um exemplo de um registo DMARC?

O exemplo mais simples é v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, publicado como um registo TXT em _dmarc.yourdomain.com. v=DMARC1 define a versão, p=none indica aos destinatários que monitorizem sem tomarem medidas e rua= é o endereço para onde são enviados os seus relatórios agregados. Este é o mínimo exigido pela Google, pelo Yahoo e pela Microsoft para remetentes em massa.

O valor «p=none» é suficiente?

Para começar e cumprir os requisitos do provedor de caixa de entrada, sim. p=none é também o ponto de partida correto, pois proporciona visibilidade sem interromper o fluxo de e-mails. Em ambientes de envio complexos, com várias plataformas e fornecedores, um p=quarantine bem monitorizado é, muitas vezes, o destino adequado a longo prazo. Não se apresse a definir p=reject antes de os seus relatórios confirmarem que todos os remetentes estão em conformidade.

Por que é que o DMARC falha quando tanto o SPF como o DKIM são aprovados?

Alinhamento. Não basta que o SPF e o DKIM sejam válidos — o domínio autenticado também tem de corresponder ao domínio que aparece no campo «De:» visível. Esta situação ocorre com maior frequência quando uma ferramenta de terceiros (CRM, serviço de apoio ao cliente, plataforma de divulgação) autentica o e-mail utilizando o seu próprio domínio, em vez do seu. A solução consiste em configurar cada plataforma para assinar e autenticar utilizando especificamente o seu domínio.

Preciso de um registo DMARC separado para cada subdomínio?

Normalmente, não. Por predefinição, um registo no domínio da sua organização rege os subdomínios. Utilize a etiqueta sp= para definir uma política explícita para os subdomínios — por exemplo, sp=reject para bloquear os subdomínios a partir dos quais nunca envia mensagens. Os domínios secundários de comunicação, no entanto, são completamente separados e cada um necessita do seu próprio registo DMARC.

Posso enviar relatórios DMARC para o meu próprio endereço de e-mail, em vez de utilizar uma ferramenta paga?

Sim. Basta indicar rua=mailto: em qualquer caixa de entrada que controle e receberá relatórios agregados gratuitamente. O problema é que estes chegam em formato XML bruto, o que é viável para um domínio pequeno, mas torna-se difícil de analisar em grande escala. Para um único domínio de envio com atividade limitada, a sua própria caixa de correio é suficiente.

O DMARC irá melhorar a capacidade de entrega dos meus e-mails não solicitados?

O DMARC é necessário, mas não suficiente. Sem ele, o Google, o Yahoo e a Microsoft podem rejeitar ou enviar o seu e-mail para a pasta de lixo eletrónico antes mesmo de este ser avaliado. No entanto, o facto de o ter não garante que o e-mail chegue à caixa de entrada; isso depende da reputação do remetente e do conteúdo. O DMARC garante a autenticidade. A chegada à caixa de entrada depende destes três fatores. Consulte o nosso guia sobre como melhorar a capacidade de entrega de e-mails para ter uma visão completa.

A Microsoft exige agora o DMARC?

Sim. Desde 5 de maio de 2025, a Microsoft exige SPF, DKIM e uma política DMARC mínima de p=none para remetentes em massa (mais de 5 000 e-mails por dia) para endereços Outlook.com, Hotmail.com e Live.com. As mensagens que não cumprem estes requisitos são inicialmente encaminhadas para a pasta de lixo eletrónico, sendo posteriormente rejeitadas. A Google e a Yahoo adotaram requisitos semelhantes em fevereiro de 2024. Os três principais fornecedores de serviços de e-mail exigem agora o DMARC para o envio em massa.

‍