A política DMARC anula: Explicado
por
Tempo de leitura: 7 min
Este artigo explica em pormenor o que são as substituições da política DMARC, como funcionam, qual a diferença entre uma substituição da política DMARC e uma falha da política DMARC e se a substituição dos registos DMARC é legítima ou não.
Takeaways de chaves
- As substituições de política DMARC ocorrem quando um servidor de correio eletrónico recetor não respeita as políticas DMARC especificadas pelo remetente.
- O servidor de correio eletrónico recetor pode ter as suas próprias políticas que podem levar à anulação das definições DMARC mais rigorosas do remetente.
- A especificação DMARC incentiva os destinatários de correio a respeitarem, tanto quanto possível, as políticas DMARC do proprietário do domínio.
- As substituições são permitidas ao abrigo do RFC 7489, mas vão contra o espírito pretendido do DMARC.
- É importante que os remetentes controlem as substituições da política DMARC para evitar a falsificação de correio eletrónico e manter a segurança.
A política DMARC anula: Explicado
A anulação da política DMARC acontece quando o servidor de correio electrónico receptor anula o DMARC registo que é estabelecido pelo remetente. Isto ocorre quando o remetente especifica que quer que o seu correio electrónico seja rejeitado se não corresponder à política de um servidor de correio de entrada, mas o servidor de correio electrónico receptor decide que não é apropriado para o seu próprio conjunto de políticas.
Por exemplo, se o remetente tiver especificado uma política rigorosa (como "p=rejeitar todo o correio sem SPF ou DKIM") e o servidor de correio eletrónico recetor tiver uma política flexível (como "aceitar todo o correio sem SPF ou DKIM"). Nesta situação, o servidor de receção pode substituir a configuração da política DMARC do remetente pela sua própria política local e entregar a mensagem na caixa de entrada do destinatário, mesmo que não passe nas verificações DMARC.
Simplifique a política DMARC com o PowerDMARC!
Compreender o mecanismo de anulação da política DMARC
DMARC é utilizado para comunicar configurações de políticas que os receptores de correio electrónico podem utilizar para fazer cumprir contra e-mails enviados a partir do seu domínio.
Por exemplo, pode utilizar uma política para DMARC para indicar ao servidor de correio eletrónico do destinatário o que deve fazer (p=rejeitar ou p=nenhum ou p=quarentena) se uma verificação SPF ou DKIM falhar nos e-mails enviados do seu domínio.
Isto resume bem o poder do DMARC, certo?
Mas e se o servidor de recepção de correio electrónico tiver o seu próprio conjunto de políticas locais para tratar a recepção de correio electrónico? Irá respeitar as políticas DMARC definidas pelo remetente OU irá sobrepor-se às políticas do remetente com as suas próprias políticas locais?
Bem...
A especificação DMARC exige que os receptores de correio façam um esforço de boa fé para respeitar as políticas DMARC publicadas pelos Proprietários do Domínio. Assim, se um teste do SPF, DKIM, e From do cabeçalho do remetente falhar numa mensagem que deve desencadear o que está especificado na política DMARC do remetente (p) como quarentena, rejeição, ou NENHUMA.
Agora vamos assumir que a situação é esta:
➜ O seu domínio (mypersonaldomain.org) tem a política DMARC (p=nenhuma).
O servidor de correio eletrónico gerido pelo destinatário (theirdomain.org) rejeita todo o correio que falhe uma verificação SPF. Isto significa que se uma mensagem de correio eletrónico enviada para (theirdomain.org) falhar a verificação SPF, será rejeitada. Certo?
Mas...
O que acontecerá se um e-mail do seu domínio (mypersonaldomain.org) com a política DMARC p=none for recebido em somedomain.org e falhar a verificação do SPF?
Neste caso, dependerá do servidor de correio eletrónico recetor (da forma como está configurado) concordar com a política DMARC definida pelo remetente OU rejeitar a mensagem de correio eletrónico, substituindo a política do remetente por regras definidas na sua política local de p=rejeitar em caso de falha na verificação SPF.
O Microsoft 365 é um exemplo disso em tempo real, pois envia todos os e-mails p=rejeitar para a pasta de lixo electrónico/spam do utilizador em vez de o rejeitar. Isto deve-se ao facto de O365 considerar que é óptimo que o destinatário tome a decisão final sobre a disposição final.
Os Cinco Valores da Política DMARC Substituem
encaminhado - O e-mail foi provavelmente encaminhado, com base em algoritmos locais que identificaram padrões de encaminhamento. Pode esperar-se que a autenticação falhe.
política_local - a política local do Receptor de Correio isentou o correio electrónico de ser sujeito à acção solicitada pelo seu Proprietário de Domínio. Por exemplo, quando a política solicitada é definida para "rejeitar" mas a verificação do ARC passou, um receptor de correio pode anular essa decisão e optar por não rejeitar um correio electrónico.
| O que é ARC?
ARC significa Cadeia de Recebimento Autenticada (ARC). Com o ARC, os protocolos DKIM e SPF de um e-mail já não serão quebrados por reencaminhamento ou listas de correio. Isto porque o ARC preserva os resultados da autenticação de correio electrónico através de routers, intermediários e outros sistemas ("hops") que podem modificar uma mensagem à medida que esta passa de um nó na Internet para outro. Assim, se uma cadeia de ARC estivesse presente, o servidor de recepção de correio que de outra forma descartaria as mensagens poderia optar por avaliar os resultados do teste - e fazer uma excepção, permitindo que as mensagens legítimas destes fluxos de correio indirectos chegassem aos seus destinos. |
mailing_list - O e-mail foi enviado a partir de uma lista de correio, pelo que o programa de filtragem decidiu que provavelmente não era legítimo.
sampled_out - A mensagem não se aplicava à política porque a sua definição "pct" estava definida no registo DMARC.
trust_forwarder - A falha foi antecipada por provas que ligavam o correio electrónico a uma lista de reencaminhadores de confiança mantida localmente.
outros - Algumas políticas continham excepções que não foram abordadas pelas outras entradas da lista.
Política de Substituição de DMARC: É permissível?
A secção 6 do RFC 7489 declara que os servidores de correio devem honrar e tratar as mensagens em conformidade com a política do remetente. Embora as revogações sejam contra o espírito do DMARC, os fornecedores de caixas de correio reservam-se o direito de revogar a política de qualquer remetente. Portanto, sim, é admissível que o servidor receptor sobreponha a política do DMARC com a sua política local.
Isto significa que um servidor de correio electrónico ainda poderia entregar uma mensagem falsa, mesmo que a política que deveria seguir dissesse o contrário.
Deve enviar relatórios de anulação da política DMARC?
As revogações da política DMARC ocorrem sobretudo quando:
- a heurística do receptor identifica uma mensagem que falhou a autenticação mas que pode ter sido enviada por uma fonte autorizada.
- um fornecedor de caixas de correio tem uma mensagem que falhou o DMARC devido a reencaminhamento de correio electrónico mas estão suficientemente confiantes na sua legitimidade, podem sobrepor-se à política e entregá-la de qualquer forma.
Embora as revogações da política DMARC sejam permitidas, as secções 6 e 7.2 do RFC 7489 declaram que quando um receptor opta por se desviar da política publicada pelo proprietário do domínio, deve comunicar esse facto bem como as suas razões para o fazer (utilizando o formato de relatório de feedback agregado) de volta ao proprietário do domínio.
Como é permitida a anulação da política DMARC?
O DMARC é composto por duas partes:
Política DMARC - Esta política é definida pela organização remetente (no DNS público da organização remetente, juntamente com SPF e DKIM) e define a forma como o lado destinatário deve tratar as mensagens que não cumprem as suas políticas.
Verificação DMARC - É utilizada pela organização recetora (no gateway de segurança de correio eletrónico da organização recetora) e verifica todas as mensagens recebidas de uma determinada organização relativamente às políticas listadas nos registos DMARC dessa empresa. No entanto, a capacidade de substituir a aplicação da política DMARC de uma organização remetente também se aplica às organizações destinatárias.
Criação de um Política DMARC é um "PEDIDO, NÃO UMA OBRIGAÇÃO".: significa essencialmente que você está "pedindo servidores de correio electrónico para indicar como devem tratar as mensagens de correio electrónico enviadas a partir do seu domínio ou fazendo-se passar por ele.
Contudo, os receptores de correio electrónico não são obrigados a seguir um conjunto rigoroso de directrizes ao processar as mensagens de correio electrónico recebidas. Podem desenvolver as suas políticas relativamente às mensagens que aceitam ou rejeitam e aplicar essas normas em conformidade.
Por exemplo, se o destinatário do correio eletrónico considerar a mensagem válida. Assim, se uma mensagem de correio eletrónico falhar uma verificação DMARC, o recetor pode ainda aplicar a sua política local e entregá-la nas caixas de entrada. Além disso, as políticas do recetor de correio eletrónico podem sobrepor-se à política do proprietário de um domínio.
Como pode uma organização receptora anular a minha política DMARC?
Outras organizações podem substituir a sua configuração de políticas DMARC pelas suas próprias ferramentas de verificação DMARC e decidir o seu próprio conjunto de políticas sobre como agir em relação às mensagens recebidas. Dependendo do sistema, um utilizador com privilégios de administrador pode ser capaz de anular todos os domínios ou apenas determinados domínios.
É de notar que as políticas DMARC são estabelecidas pelo proprietário do domínio, e cada política aplica-se apenas aos domínios dessa organização. Assim, uma política DMARC não pode afectar os endereços de outras organizações ou as suas mensagens.
Falha da Política DMARC vs. Política DMARC Substituição da Política DMARC: Qual é a diferença?
Falha do DMARC é quando um servidor de correio não implementa correctamente o DMARC, o que leva a uma falha de verificação SPF e DKIM no final do receptor. A incapacidade de verificar a sua legitimidade pode levar as caixas de entrada a marcá-lo como spam ou a rejeitar as suas mensagens. Aqui o servidor de recepção de correio electrónico honra a política do remetente e não anula a referida política com a sua política local.
As anulações da política DMARC ocorrem quando o servidor de recepção de correio não honra a política do remetente. Em vez disso, anula a política DMARC do remetente com a sua política local. Isto significa que se a mensagem do remetente tiver uma política rigorosa de p=rejeição sem verificação SPF ou DKIM, o correio de recepção anulará a política e ainda assim entregará a mensagem à caixa de entrada.
Manter um registo adequado da política DMARC Substituir com PowerDMARC
Manter-se actualizado sobre as anulações da política DMARC é uma parte essencial para evitar a falsificação e a personificação do correio electrónico. No entanto, a maioria das organizações não tem tempo ou recursos para acompanhar as suas revogações de política de DMARC.
Não pode impedir as substituições de políticas DMARC, mas pode controlá-las com o nosso serviço DMARC. Fornecer-lhe-emos relatórios completos sobre quais as organizações que anulam o seu modo de política e que tipo de mensagens de quais e que e-mails foram permitidos no destinatário. Isto ajudará o remetente a manter o controlo e a tomar as medidas necessárias se for detectada falsificação ou imitação.
Inscreva-se no nosso Teste gratuito de DMARC hoje e teste-o você mesmo!
Especialista em segurança de domínios e e-mails da PowerDMARC
Yunes é um Operations Team Lead na PowerDMARC com conhecimentos especializados em autenticação e segurança de correio eletrónico. Yunes é um Microsoft-certified Azure Administrator Associate com certificações em CompTIA A+ e muito mais.
Últimas mensagens de Yunes Tarada (ver todas)
- Ataques de salting de correio eletrónico: Como o texto oculto contorna a segurança - 26 de fevereiro de 2025
- Alisamento do SPF: O que é e porque é que precisa dele? - 26 de fevereiro de 2025
- DMARC vs DKIM: Principais diferenças e como funcionam em conjunto - 16 de fevereiro de 2025
