Antes de restringir sua política DMARC, identifique os sistemas que enviam e-mails legítimos usando o seu domínio. Relatórios podem revelar um remetente que precisa de alterações na autenticação antes que a aplicação da política bloqueie seus e-mails.
Qual relatório você deve usar?
Use relatórios agregados para comparar fontes de envio e resultados de autenticação ao longo de um período de relatório. O endereço rua do seu registro DMARC solicita esses resumos XML dos receptores participantes.
O endereço ruf solicita relatórios individuais de falha, às vezes chamados de relatórios forenses. Eles usam um formato de relatório de falha de autenticação e podem conter cabeçalhos ou conteúdo da mensagem. Receptores podem redigi-los ou omiti-los porque esse conteúdo pode expor informações pessoais. As regras de relatório da RFC 7489 descrevem os dois tipos de relatório.
Relatórios agregados cobrem o tráfego que cada receptor reportou. A ausência de um relatório não prova que nenhuma mensagem usou seu domínio. A explicação do registro DMARC indica onde configurar os endereços de relatório.
O que um relatório agregado contém?
Um relatório agregado identifica a organização que reporta, o período do relatório e a política publicada, seguidos de registros que agrupam mensagens com características em comum. Um IP de origem pode aparecer em vários registros quando os resultados de autenticação ou outros campos de agrupamento diferem.
Este trecho ilustrativo mantém os campos necessários para comparar uma fonte com seus resultados de autenticação:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Este registro representa 42 mensagens de 203.0.113.10 usando example.com no endereço From visível. Ambos os métodos de autenticação passaram e estavam alinhados. O receptor não aplicou nenhuma ação de DMARC a essas mensagens; isso não determina o posicionamento na caixa de entrada.
Quais campos identificam um problema de autenticação?
Compare policy_evaluated com auth_results para distinguir uma falha de autenticação de uma falha de alinhamento de domínio.
| Campo | O que verificar |
|---|---|
source_ip | Identifique o servidor de envio e o serviço responsável por ele. |
count | Conte as mensagens representadas por este registro, não pelo relatório inteiro. |
header_from | Confirme o domínio exibido ao destinatário. |
disposition | Verifique se o receptor aplicou none, quarantine ou reject. |
dkim e spf em policy_evaluated | Verifique se cada método passou e alinhou para DMARC. |
auth_results | Compare os resultados brutos de autenticação e os domínios que eles autenticaram. |
Por exemplo, SPF pode passar em auth_results mas falhar em policy_evaluated quando seu domínio autenticado não está alinhado com o domínio do From. Um passe alinhado de DKIM ainda pode fazer essa mensagem passar em DMARC. Como DMARC funciona explica essa relação.
O que você deve fazer com cada fonte de envio?
Associe cada fonte a um serviço que você autoriza antes de alterar a política. Resultados de autenticação sozinhos não indicam se a sua organização pretendia que aquele serviço enviasse.
- Para um remetente conhecido que passa e alinha, confirme se o volume reportado corresponde ao tráfego esperado.
- Para um remetente conhecido que falha, corrija a autenticação ou o alinhamento e verifique relatórios posteriores para conferir o resultado.
- Para um remetente desconhecido que passa, identifique quem o configurou e se ele deve manter a autorização.
- Para um remetente desconhecido que falha, investigue se é um serviço legítimo mal configurado ou uso não autorizado do seu domínio.
Resolva falhas legítimas antes de passar do monitoramento para quarentena ou rejeição, porque essas mensagens seriam candidatas à aplicação da política. Corrigindo falhas de DMARC cobre causas comuns.
Como você inspeciona relatórios de um domínio de envio Bird?
Você pode direcionar relatórios agregados para sua própria caixa de entrada pelo endereço rua no seu registro DMARC. Use o analisador de relatórios DMARC para inspecionar o XML ou abra um relatório em um editor de texto.
A verificação de DNS do Bird confere sua política publicada; relatórios de receptores descrevem resultados de autenticação para mensagens. São verificações separadas. O guia de autenticação cobre a política e os registros DNS a publicar.