DMARC RUA indica no registro DMARC os destinos solicitados para relatórios agregados. Sem esse campo, a política pode existir, mas você perde uma fonte de informação sobre autenticação e alinhamento. Os relatórios são parciais e não comprovam sozinhos a identidade das origens ou falsificação. Para revisar as bases, comece por e-mail empresarial para pequenas empresas.
Um CRM mal configurado, uma extensão WordPress esquecida ou um encaminhamento que afeta SPF podem complicar o diagnóstico. RUA fornece dados para investigar essas situações, sem explicar sozinho todas as decisões de filtragem do Gmail.
Este guia explica RUA, sua publicação, o conteúdo XML e como priorizar as correções.
O que é DMARC RUA?
RUA é o campo de destino dos relatórios agregados de autenticação. Eles resumem SPF, DKIM, alinhamento, IP de origem e disposição durante um período, normalmente diário, para tráfego de destinatários participantes.
Em DMARC, rua=mailto:... solicita o envio dos relatórios agregados ao destino. Conforme a RFC 7489, rua define onde enviar dados de autenticação, alinhamento, domínios, volume e política aplicada.
Observar o tráfego ajuda a avaliar p=none, p=quarantine ou p=reject. RUA fornece evidências, mas não demonstra que todos os remetentes legítimos estejam prontos para uma política restritiva.
O que os relatórios RUA mostram
São resumos agregados, não cópias de mensagens. Mostram origens observadas, autenticação SPF/DKIM e alinhamento DMARC. Diferencie os resultados brutos dos avaliados para a política, que incorporam o alinhamento.
Você não recebe os corpos das mensagens, mas dados para investigar erros de provedores, alinhamento e possível abuso. Complemente com inventário e testes.
| Tag | Função | Dados | Uso comum |
|---|---|---|---|
rua | Solicita relatórios agregados | Resumos XML por IP e autenticação | Monitoramento e avaliação de políticas |
ruf | Solicita relatórios de falhas | Amostras de mensagens quando disponíveis | Diagnóstico específico |
Comece por RUA e considere ruf para uma necessidade concreta. Relatórios forenses têm suporte irregular e levantam mais questões de privacidade.
Exemplo: seu domínio envia por Google Workspace, uma aplicação de cobrança e suporte. RUA pode mostrar origens observadas desses serviços, sem garantir que todos apareçam. Uma falha de alinhamento precisa de investigação; um IP em outro país não comprova falsificação.
Como publicar RUA
Adicione um TXT em _dmarc.yourdomain.com com destino válido rua=mailto:. Comece pelo monitoramento se o inventário de remetentes ainda estiver incompleto.
Este exemplo usa alinhamento estrito opcional, que pode afetar subdomínios legítimos e não é a melhor escolha inicial para todos:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"Esta alternativa mínima usa alinhamento relaxado padrão. Publique apenas um registro, não ambos:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Use uma caixa dedicada ou um serviço de análise. Evite misturar anexos XML compactados com as solicitações habituais do suporte.
Para o TrekMail, consulte Registros DNS obrigatórios. As verificações disponíveis de SPF, DKIM e DMARC ajudam na revisão, sem garantir a detecção de todos os problemas ou remetentes externos.
Como verificar RUA
Consulte o DNS diretamente e depois confira o recebimento dos relatórios. Uma configuração incorreta pode impedir que participantes obtenham um destino válido; uma caixa vazia também pode ter outras causas.
Use dig ou nslookup:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comA resposta deve mostrar o TXT DMARC. Pela RFC 7489, este é outro exemplo válido, não um registro para acrescentar aos anteriores:
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"Os relatórios costumam ser diários, mas frequência e participação variam. A ausência deles não comprova ausência de tráfego nem, sozinha, erro DNS.
Como ler um relatório RUA
Examine origem, SPF, DKIM, alinhamento e disposição. Autenticação válida precisa estar alinhada para contribuir ao DMARC; não demonstra sozinha que o conteúdo seja seguro ou legítimo.
Uma sequência útil:
- Examine IP e DNS reverso e compare com seus provedores; PTR não comprova identidade nem legitimidade.
- Avalie volume e importância: uma origem com 2 mensagens pode ser crítica, mesmo se outra envia 20,000.
- Confira autenticação e alinhamento SPF/DKIM. Um resultado válido não alinhado pode não servir ao DMARC.
- Examine disposição:
nonenão prova entrega nem monitoramento;quarantinenão indica uma pasta fixa;rejectnão garante bloqueio. - Investigue se a origem é conhecida, mal configurada, intermediária ou abusiva.
O Google exige SPF ou DKIM para remetentes gerais ao Gmail pessoal; para remetentes em massa, ambos e DMARC com o alinhamento aplicável ao From: visível. RUA ajuda a localizar problemas observados, sem garantir a caixa de entrada.
Três situações que merecem investigação
Relatórios podem revelar remetentes legítimos sem autenticação, encaminhamentos e possível falsificação, mas também relays compartilhados ou outras rotas. Investigue antes de classificar ou bloquear.
1. Remetente legítimo mal configurado
Um serviço pode usar seu domínio sem SPF ou DKIM válidos e alinhados. Um único resultado válido e alinhado basta ao DMARC. Corrija o remetente e teste antes de mudar a política.
No TrekMail, siga a rota real de envio. Para um serviço externo, consulte SMTP próprio. Com envio incluído no plano, consulte Managed TrekMail SMTP e confira assinatura e alinhamento disponíveis.
2. SPF falha após encaminhamento
Isso pode ocorrer porque o servidor encaminhador faz a conexão. Não prova mensagem maliciosa. Se DKIM preserva os dados assinados conforme sua canonicalização, passa e está alinhado, DMARC passa. Confira a rota em vez de ignorar automaticamente todas as falhas SPF.
Consulte encaminhamento de e-mail e encaminhar e-mail de domínio ao Gmail. Diferenciar a falha SPF do resultado DMARC evita alterações desnecessárias.
3. Origem desconhecida ou possível falsificação
Um IP ou provedor desconhecido exige investigação: pode ser um serviço esquecido, relay compartilhado ou encaminhamento. Não o autorize no SPF nem o bloqueie sem identificar. Avalie restrições depois de verificar as origens legítimas.
Usar um serviço de terceiros para RUA?
Pode facilitar a análise, mas você precisa entender sua configuração DNS e o tratamento de dados. Destinos externos exigem a autorização correspondente para serem aceitos pelos geradores participantes.
Segundo a RFC 7489, quando o destino rua fica fora do domínio organizacional, o domínio que recebe relatórios deve publicar autorização em um nome como:
example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"Sem essa confirmação, alguns geradores ignoram o destino externo. Siga as instruções exatas do analisador e confira a autorização no DNS de destino.
Quando passar de p=none a quarantine ou reject
Use os dados com inventário e testes. Investigue falhas antes das restrições; relatórios favoráveis não comprovam cobertura de todos os fluxos legítimos.
Uma abordagem orientativa:
- Publique RUA com
p=none. - Observe relatórios por 1 a 2 semanas como referência inicial e amplie para cobrir fluxos raros.
- Corrija autenticação e alinhamento de cada remetente para que pelo menos SPF ou DKIM passe alinhado.
- Considere
p=quarantineapós resolver falhas legítimas e investigar as desconhecidas. - Considere
p=rejectdepois de testar também processos críticos e encaminhamentos.
Sem observação e testes, um cliente pode revelar um remetente esquecido antes dos relatórios. Prepare a resposta a incidentes durante a transição.
Operação dispersa ou fluxo coordenado
Revisar XML separadamente para cada domínio exige coordenação. DNS consistente e um painel de domínios, caixas, migração e envio podem facilitar correções conforme os recursos disponíveis.
| Problema comum | Abordagem com TrekMail |
|---|---|
| Configurações SPF, DKIM e DMARC diferentes entre domínios | Painel para acompanhar DNS e operações das caixas |
| Remetente responsável pela falta de alinhamento desconhecido | Fluxo DNS e documentação de diagnóstico |
| Encaminhamentos atribuídos apenas ao SPF | Configuração que considera DMARC, DKIM e rotas indiretas |
| Custos por usuário ao ampliar domínios | Planos anunciados desde $3.50 por mês com armazenamento compartilhado e sem cobrança por usuário conforme os termos |
O TrekMail não substitui um analisador DMARC. Pode coordenar domínios, caixas IMAP, catch-all, encaminhamento, migração IMAP e SMTP próprio ou incluído conforme o plano. Confira os recursos necessários para corrigir problemas observados.
Os planos são anunciados desde $3.50 por mês. O Nano é oferecido gratuitamente sem cartão. Os planos pagos podem incluir avaliação de 14 dias com cartão exigido; confirme os termos vigentes.
Conclusão: RUA oferece visibilidade parcial
RUA cria um canal útil para investigar autenticação, encaminhamentos e possível falsificação. Complemente os dados com outras evidências para avaliar a preparação do domínio para restrições.
Com um domínio, cinquenta ou quinhentos, baseie decisões em testes. Revise relatórios periodicamente, atualize o inventário e corrija os remetentes antes da política.
Para coordenar a infraestrutura, o TrekMail oferece hospedagem multidomínio, armazenamento compartilhado, criação de caixas por convite e migração IMAP conforme o plano. Consulte os termos em trekmail.net e escolha conforme suas necessidades operacionais.
