Como criar um registro DMARC sem interromper os e-mails

A decisão de criar um registro DMARC costuma vir após algum problema: mensagens falsificadas, avisos do Gmail, alterações DNS solicitadas por um fornecedor ou resultados SPF e DKIM diferentes entre os envios. Se você ainda está configurando o sistema, comece pelo nosso guia de e-mail empresarial para coordenar domínio, caixas e DNS desde o início.

Uma configuração incorreta nem sempre provoca uma falha imediata. O registro pode existir sem ser utilizado como você espera: nome incorreto, política inválida, relatórios que não chegam ou autenticação sem alinhamento. A falsificação pode continuar e mensagens legítimas ainda podem cair no spam; publicar o DMARC não garante a entrega.

Este guia explica como criar um registro DMARC, quais tags verificar, o que publicar em _dmarc.yourdomain.com e como avaliar a passagem do monitoramento para as restrições.

O que você publica ao criar um registro DMARC

Publique um TXT em _dmarc.yourdomain.com que comece com v=DMARC1 e inclua uma política válida: p=none, p=quarantine ou p=reject. O DMARC solicita um tratamento ao destinatário quando nenhum mecanismo fornece um resultado válido e alinhado a From. Basta que SPF ou DKIM passe com alinhamento para o DMARC passar.

Este é um exemplo mínimo válido:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

Ele publica uma política sem restrições pelo DMARC, mas não solicita relatórios agregados porque falta o destino. Os destinatários podem continuar aplicando filtros locais.

Uma alternativa inicial com solicitação de relatórios é:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Se os testes justificarem restrições, substitua a política anterior em vez de adicionar outra:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

A RFC 7489 exige que v seja a primeira tag e que p esteja presente. Sem esse formato válido, os destinatários não podem aplicar o registro como política DMARC. Consulte os detalhes na RFC 7489.

Onde criar o registro DMARC no DNS

O registro não fica na raiz, mas em _dmarc. Para example.com, o nome completo de consulta é _dmarc.example.com. Outro nome não disponibiliza a política nessa consulta DMARC.

Um erro comum é usar @ ou inserir _dmarc.example.com em um painel que espera apenas _dmarc e adiciona o domínio automaticamente. Confira se o provedor pede um nome relativo ou completo.

Após a publicação, consulte o DNS fora do painel:

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

Deve haver uma única política DMARC válida começando com v=DMARC1. Várias strings TXT podem formar o mesmo registro; outros TXT também não são necessariamente políticas DMARC.

No TrekMail, você pode adicionar o domínio, copiar os valores indicados e usar as verificações DNS disponíveis, comparando-as com consultas externas. Consulte como adicionar um domínio, os registros DNS necessários e a verificação do status DNS. O painel não comprova sozinho a autenticação de todos os fluxos.

Tags de um registro DMARC

Muitas tags são opcionais. Comece por v, p e, para solicitar relatórios, rua. Ajuste o alinhamento para uma necessidade concreta depois de verificar a configuração básica.

Um registro válido com p=none, mas sem rua, não solicita relatórios agregados. Seus logs e outras ferramentas continuam disponíveis, mas a observação por relatórios DMARC fica limitada.

Como escolher a política DMARC

Se todos os remetentes ainda não foram validados, começar com p=none costuma ser útil. Avalie p=quarantine após investigar os relatórios e corrigir os serviços. Considere p=reject depois de comparar fontes desconhecidas com o inventário, os logs e os testes de fluxos críticos pouco frequentes.

As diretrizes do Google citadas exigem SPF e DKIM para remetentes em massa e que pelo menos um passe alinhado a From para o DMARC. Não transforme possíveis mudanças futuras em requisitos atuais; confira as condições e a quem se aplicam nas perguntas frequentes sobre as diretrizes de envio do Google.

DMARC não é apenas uma caixa de seleção. Se o CRM usa seu domínio em From, mas assina e envia com domínios do fornecedor sem alinhamento, o DMARC pode falhar mesmo com a autenticação ativada.

Passo a passo para criar um registro DMARC

Organize uma implantação gradual: inventário, política de monitoramento e restrições após as verificações. A ausência de surpresas nos relatórios não comprova que todos os remetentes funcionam.

1. Liste os serviços que enviam com seu domínio, incluindo Google Workspace, Microsoft 365, suporte, CRMs, formulários, cobrança e newsletters.
2. Verifique SPF e DKIM em cada serviço e pelo menos um mecanismo válido e alinhado. O DMARC não os substitui nem repara. Publique um SPF válido por domínio real do envelope e respeite o limite aplicável aos mecanismos ou modificadores que provocam consultas DNS, incluindo avaliações aninhadas.
3. Crie uma caixa como dmarc@yourdomain.com ou use um serviço de relatórios, com monitoramento, acesso adequado e autorização DNS no domínio destinatário externo quando necessária.
4. Publique inicialmente uma política p=none.
5. Investigue os relatórios agregados disponíveis e compare-os com os remetentes conhecidos e seus logs.
6. Corrija os domínios autenticados e o alinhamento a From; alterar a política DMARC não basta.
7. Avalie p=quarantine depois de testar os fluxos.
8. Avalie p=reject quando os testes, inclusive de processos pouco frequentes, justificarem a mudança.

Este exemplo de monitoramento para um domínio empresarial em 2026 deve ser adaptado ao seu destino de relatórios:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Se você usa encaminhamento, consulte como encaminhar e-mails do domínio para o Gmail. O encaminhamento pode fazer o SPF falhar. O DKIM pode permitir que o DMARC passe se a assinatura continuar válida e alinhada, com os dados assinados preservados após a canonicalização. O ARC pode orientar uma exceção local do destinatário, mas não fornece sozinho um resultado válido de autenticação DMARC.

Erros comuns ao criar um registro DMARC

Muitos problemas vêm da configuração: nome incorreto, várias políticas DMARC, destinos de relatórios inválidos ou a expectativa de que o DMARC corrija SPF e DKIM. Publique uma política válida e verifique-a externamente.

Estes erros aparecem com frequência:

1. Publicar na raiz em vez de _dmarc.
Um registro em @ não aparece na consulta DMARC do domínio.

2. Publicar várias políticas DMARC em TXT.
A RFC 7489 indica que várias políticas DMARC impedem a continuidade do processamento. Mantenha uma política por nome de consulta; fragmentos de um TXT não são políticas separadas.

3. Ativar p=reject logo no início.
Um serviço esquecido pode provocar a rejeição de redefinições de senha, faturas ou respostas legítimas do suporte.

4. Apontar rua para uma caixa inexistente.
Você pode perder relatórios que foram enviados. A ausência de relatórios também não comprova que os destinatários os geraram.

5. Esperar que o DMARC repare o encaminhamento.
O DMARC precisa de SPF ou DKIM válido e alinhado. Se o SPF falhar no encaminhamento, o DKIM precisa continuar válido e alinhado para fornecer esse resultado.

Exemplo: o site envia confirmações por um provedor SMTP, o suporte por outro e o marketing por um terceiro. Você publica p=reject sem verificar os três. Um fluxo passa e dois falham; os destinatários podem recusar mensagens necessárias aos clientes. A política não corrigiu os serviços pendentes.

Se você está configurando o domínio do zero, nosso guia para criar e-mail com seu domínio aborda DNS e caixas junto com SPF, DKIM e DMARC.

Gestão dispersa ou centralizada do DMARC em vários domínios

Planilhas, acessos a cada registrador e TXT copiados de chamados antigos dificultam a coordenação. Uma interface central e verificações DNS podem ajudar a encontrar diferenças, mas cada domínio e serviço de envio exige uma configuração validada.

Conforme o plano, o TrekMail oferece vários domínios, armazenamento compartilhado, caixas IMAP, ferramentas de migração, catch-all, encaminhamento e SMTP gerenciado ou próprio. A cópia IMAP não substitui a alteração de MX nem migra todos os aplicativos. A oferta descrita do Nano permite até 10 domínios sem custo com SMTP próprio; os planos pagos partem de $3.50 por mês sob suas condições. Confira os recursos e preços atuais na página de preços do TrekMail.

Centralizar pode facilitar as verificações e a coordenação entre cinco fornecedores e vinte abas. Isso não comprova automaticamente o estado de todos os fluxos nem garante economia ou redução de incidentes.

Verificações finais antes de aplicar restrições DMARC

Antes de aplicar restrições, confira SPF e DKIM dos remetentes autorizados, pelo menos um resultado válido e alinhado por fluxo, o destino dos relatórios e uma única política DMARC válida em _dmarc. O DMARC não substitui uma autenticação correta.

Revise esta lista:

1. Uma única política DMARC em TXT.
2. Nome _dmarc, relativo ou completo conforme o provedor DNS.
3. Valor começando com v=DMARC1; p=....
4. rua aponta para uma caixa ou serviço válido, monitorado e autorizado quando necessário.
5. Um SPF válido por domínio do envelope, com autorizações consolidadas e respeito ao limite DNS aplicável, incluindo avaliações aninhadas.
6. DKIM configurado e verificado nas plataformas compatíveis, com pelo menos um mecanismo alinhado por fluxo.
7. Consultas externas mostram a política esperada.
8. Comece com none se ainda precisar validar remetentes e fluxos pouco frequentes.

O TrekMail pode centralizar domínios personalizados, caixas IMAP, verificações DNS, escolha de SMTP e ferramentas de migração conforme o plano. Isso não elimina o acompanhamento contínuo nem garante a entrega. Consulte trekmail.net e avalie os recursos de acordo com suas necessidades operacionais.