Desmistificando o registro DMARC

O padrão DMARC (Domain-based Message Authentication, Reporting & Conformance) é a melhor ferramenta que as marcas possuem para combater ataques de phishing que visam clientes falsificando seus domínios de propriedade. Mas implementar o DMARC pode se tornar confuso muito rapidamente.

Nesta postagem, vamos desmistificar o registro DMARC definindo as tags DMARC que o compõem. Abordaremos as tags obrigatórias e opcionais, além de discutir algumas estratégias e casos de uso em que as tags DMARC menos conhecidas podem oferecer à sua organização um nível maior de segurança de e-mail.

O que são tags DMARC?
As tags DMARC são a linguagem do padrão DMARC. Eles dizem ao destinatário do e-mail para (1) verificar o DMARC e (2) o que fazer com as mensagens que falham na autenticação do DMARC.

Tags DMARC obrigatórias
Existem apenas duas tags DMARC obrigatórias: “v:” e “p:”

v: Versão . Essa tag é usada para identificar o registro TXT como um registro DMARC, para que os destinatários do e-mail possam distingui-lo de outros registros TXT. A tag v: deve ter o valor “DMARC1” e deve ser listada como a primeira tag em todo o registro DMARC. Se o valor não corresponder exatamente a “DMARC1” ou a v: tag não for listada primeiro, todo o registro DMARC será ignorado pelo receptor.

Exemplo: v = DMARC1

p: Política de Destinatário de Correio Solicitado. Essa tag indica a política a ser executada pelo receptor para mensagens que falham na autenticação DMARC e nas verificações de alinhamento, conforme especificado pelo proprietário do domínio. Esta política se aplicará ao domínio consultado e a todos os subdomínios, a menos que uma política de subdomínio separada seja explicitamente descrita (abordaremos isso posteriormente na postagem). Existem três valores possíveis para a p: tag

1. p = nenhum: O proprietário do domínio não solicita que nenhuma ação específica seja realizada no e-mail que falhe na autenticação e alinhamento DMARC.
2. p = quarentena: o proprietário do domínio deseja que os e-mails que falham na autenticação DMARC e nas verificações de alinhamento sejam tratados como suspeitos pelos destinatários de e-mails. Isso pode significar que os destinatários colocam o e-mail na pasta de spam / lixo, sinalizam como suspeito ou examinam esse e-mail com intensidade extra.
3. p = rejeitar: o proprietário do domínio solicita que os destinatários do e-mail rejeitem o e-mail que falha na autenticação DMARC e nas verificações de alinhamento. A rejeição deve ocorrer durante a transação SMTP. Esta é a política mais rígida e oferece o mais alto nível de proteção.

Dadas as informações acima, o exemplo de registro DMARC mais básico poderia ser: v = DMARC1; p = nenhum.

Tags DMARC opcionais
As tags DMARC opcionais abaixo permitem que os remetentes de e-mail forneçam instruções mais específicas sobre o que fazer com o e-mail que não é autenticado, eliminando as suposições dos destinatários.

• rua: Indica para onde os relatórios DMARC agregados devem ser enviados. Os remetentes designam o endereço de destino no seguinte formato: rua = mailto: [email protegido]
• ruf: indica para onde os relatórios forenses do DMARC devem ser enviados. Os remetentes designam o endereço de destino no seguinte formato: ruf = mailto: [email protegido]

As seguintes tags opcionais têm um valor padrão que será assumido se a tag for excluída. A lista de tags com um valor padrão assumido é:

• adkim: indica alinhamento estrito ou relaxado do identificador DKIM. O padrão é relaxado.
• aspf: indica o alinhamento estrito ou relaxado do identificador SPF. O padrão é relaxado.
• rf: formato para relatórios de falha de mensagem. O padrão é Formato de Relatório de Falha de Autenticação ou “AFRF”.
• ri: O número de segundos decorridos entre o envio de relatórios agregados ao remetente. O valor padrão é 86.400 segundos ou um dia.
• pct: porcentagem de mensagens às quais a política DMARC deve ser aplicada. Este parâmetro fornece uma maneira de implementar e testar gradualmente o impacto da política.
• fo : Dita que tipo de vulnerabilidades de autenticação e / ou alinhamento são reportados ao Proprietário do Domínio.
• Existem quatro valores para o último fo: tag:
• 0: Gera um relatório de falha DMARC se todos os mecanismos de autenticação subjacentes falharem em produzir um resultado de “aprovação” alinhado. (Padrão)
• 1: Gere um relatório de falha DMARC se qualquer mecanismo de autenticação subjacente produziu algo diferente de um resultado de “aprovação” alinhado.
• d: Gere um relatório de falha DKIM se a mensagem tiver uma assinatura que falhou na avaliação, independentemente de seu alinhamento.
• s: Gere um relatório de falha de SPF se a mensagem falhou na avaliação de SPF, independentemente de seu alinhamento.

Embora o padrão seja “fo = 0”, a Return Path aconselha os clientes a usar fo: 1 para gerar os relatórios de falha mais abrangentes, fornecendo uma visibilidade muito mais granular do canal de e-mail.

Abaixo está um exemplo de registro DMARC. Com base no que você aprendeu até agora, tente decifrar cada tag:

v = DMARC1; p = rejeitar; fo = 1; rua = mailto: [email protegido]; ruf = mailto: [email protegido]; rf = afrf; pct = 100

E quanto aos subdomínios?
A tag DMARC final que discutiremos hoje é a tag sp:, que é usada para indicar uma política solicitada para todos os subdomínios onde o e-mail está falhando na autenticação DMARC e nas verificações de alinhamento. Esta marca é aplicável apenas a domínios de nível superior (domínios de nível organizacional). É mais eficaz quando um proprietário de domínio deseja especificar uma política diferente para o domínio de nível superior e todos os subdomínios.

Para os cenários a seguir, usaremos o domínio de nível superior de “domínio.com” e o subdomínio de “mail.domain.com” para ilustrar os casos de uso.

1. O proprietário do domínio deseja impor uma política de rejeição para “dominio.com,” mas uma política de quarentena para “mail.domain.com” (e todos os outros subdomínios). O registro DMARC para “domínio.com” incluiria “v = DMARC1; p = rejeitar; sp = quarentena. ” Essa é uma estratégia eficaz se a organização precisar manter uma política DMARC separada para o domínio de nível superior e todos os subdomínios.
2. O Proprietário do domínio deseja impor uma política de rejeição para “mail.domain.com” (e todos os outros subdomínios), mas não impõe uma política de rejeição para “dominio.com”. O registro DMARC para “domínio.com” incluiria “v = DMARC1; p = nenhum; sp = rejeitar. ” Essa seria uma estratégia eficaz para combater ataques de dicionário no caso de o domínio de nível superior não estar pronto para aplicar a política, mas os fraudadores estão falsificando subdomínios como mail.domain.com, abc.domain.com, 123.domain. com, xyz.domain.com, etc. Definir o sp: tag para rejeitar protegerá a organização desses ataques de dicionário que visam subdomínios sem afetar nenhum dos e-mails enviados do domínio de nível superior, “domain.com”

Agora que você entende o DNA do registro DMARC, aprenda mais sobre quais tipos de ataques ele bloqueia e quais tipos de ataques não bloqueia no The Email Threat Intelligence Report .