☰

DMARC sem rua... formato adequado?

tag-icon • tag-icon dmarc
DMARC sem rua... formato adequado?

Yahoo e Google agora exigem DMARC de acordo com Shopify. Estou configurando-os para meus clientes, mas não preciso dos relatórios agregados. Só preciso disso para que essas empresas possam verificar o remetente legítimo, se necessário. Li que você pode remover a rua, mas quero ter certeza de que os e-mails dos clientes ainda são aceitos. Atualmente, estou escrito como: v=DMARC1; p=nenhum; rua=mailto:dmarc-reports@meudominio, mailto:artista@meudominio Em vez disso, usaria v=DMARC1; p=nenhum; mailto:artista@meudominio ??
Não tenho certeza de como funciona a verificação com o dmarc. Meu host adiciona _dmarc.mydomain então não preciso adicioná-lo.

Responder1

TL;DR: v=DMARC1; p=none;é sintaticamente válido, mas não faz sentido na prática.

Você está tomando o caminho mais fácil e o tiro sairá pela culatra. É verdade que oRequisitos do Google para 1º de fevereiro de 2024em relação ao DMARC são soltos. Por outro lado, o próximo requisito parece que o Google exigiriaalinhamento mesmo com a p=nonepolítica.

  • Configure a autenticação de e-mail DMARC para seu domínio de envio. Seu DMARCpolítica de aplicaçãopode ser definido como none.Saber mais
  • Para mala direta, o domínio no cabeçalho From: do remetente deve estar alinhado com o domínio SPF ou com o domínio DKIM. Isso é necessário para passarAlinhamento DMARC.

Mas isso é apenas o começo do uso das políticas DMARC. A p=nonefase de transição é onde você ainda não sabe se a entrega do legítimo passaria por uma aplicação real do DMARC. Você está afirmando que não precisa do relatório agregado, mas discordo. Obter e ler os relatórios agregados é a única maneira de obter o conhecimento necessário para uma entrega tranquila de e-mails na próxima fase. Além disso, o Google e o Yahoo podem começar a aplicar isso também.

Você também diz que as empresas deveriam ser capazes de “verificar o remetente legítimo, se necessário”. O p=nonenão fornece isso; diz que estamos dando um passo à frente na aplicação do DMARC, mas neste momento não nos importamos como o destinatário trata os e-mails falsificados de nosso domínio.

Mais tarde, quando você tiver pelo menos p=quarantinee sua infraestrutura de e-mail estiver estática e estável, vocêpoderremova o rua=com a consequência de que você não saberia se o e-mail legítimo começaria a ser colocado em quarentena. Com p=rejectvocê saberia disso pelas mensagens rejeitadas. No entanto, por exemplo,Microsoft trata p=rejectassim como foi p=quarantine.

Responder2

Você só receberá relatórios DMARC se definir a tag rua. Um registro DMARC mínimo para conformidade é assim:

v=DMARC1; p=none;

OTagque podem ser usados ​​para o registro são:

  • v (obrigatório) – A tag da versão. O único valor permitido é “DMARC1”. Se estiver incorreto ou a tag estiver faltando, o registro DMARC será ignorado.Item da lista
  • p (obrigatório) - A política DMARC. Os valores permitidos são "nenhum", "quarentena" ou "rejeitar". O padrão é “nenhum”, que não executa nenhuma ação contra e-mails não autenticados. Ele apenas ajuda a coletar relatórios DMARC e obter informações sobre seus fluxos de e-mail atuais e seu status de autenticação. “quarentena” marca os e-mails com falha como suspeitos, enquanto “rejeitar” os bloqueia.
  • rua - Destino de envio de relatório agregado. É o URI “mailto:” que os ESPs usam para enviar relatórios de falhas. A tag é opcional, mas você não receberá relatórios se ignorá-la.
  • ruf - Destino de envio do relatório forense (falha). É o URI “mailto:” que os ESPs usam para enviar relatórios de falhas. A tag é opcional, mas você não receberá relatórios se ignorá-la.
  • sp - A política de subdomínio. O subdomínio herda a tag de política de domínio (p=) explicada acima, a menos que seja especificamente definido aqui. Assim como a política de domínio, os valores permitidos são “nenhum”, “quarentena” ou “rejeitar”. Esta opção não é muito utilizada atualmente.
  • adkim - O alinhamento da assinatura DKIM. Esta tag segue o alinhamento entre o domínio DKIM e o domínio Header From pai. Os valores permitidos são "r" (relaxado) ou "s" (estrito). “r” é o padrão e permite uma correspondência parcial, enquanto a tag “s” exige que os domínios sejam iguais.
  • aspf - O alinhamento SPF. Esta tag segue o alinhamento entre o domínio SPF (o remetente) e o domínio Header From. Os valores permitidos são "r" (relaxado) ou "s" (estrito). "r" é o padrão e permite uma correspondência parcial, enquanto a tag "s" exige que os domínios sejam exatamente iguais.
  • fo - Opções de relatórios forenses. Os valores permitidos são “0”, “1”, “d” e “s”. "0" é o valor padrão, que gera um relatório forense quando SPF e DKIM não conseguem produzir uma passagem alinhada. Se algum dos resultados do protocolo for diferente de aprovado, use "1". "d" gera um relatório quando o DKIM é inválido, enquanto "s" faz o mesmo para o SPF. Defina a tag ruf para receber relatórios forenses.
  • rf - O formato de relatório para relatórios de falhas. Os valores permitidos são "afrf" e "iodef". pct A tag de porcentagem. Esta tag funciona apenas em domínios com política de "quarentena" ou "rejeição". Ele marca a porcentagem de e-mails com falha aos quais uma determinada política deve ser aplicada. O resto cai sob uma política inferior. Por exemplo, se "pct=70," num domínio com política de "quarentena", aplica-se apenas 70% das vezes. Os 30% restantes vão para “p = nenhum”. Da mesma forma, se “p = rejeitar” e “pct = 70”, “rejeitar” se aplica a 70% dos e-mails com falha e os 30% vão para “quarentena”.
  • ri - Intervalo de relatório. Marca a frequência de relatórios XML recebidos em segundos. O padrão é 86400 (uma vez por dia). Independentemente do intervalo definido, na maioria dos casos, os ISPs enviam os relatórios em intervalos diferentes (geralmente uma vez por dia). v A tag de versão. O único valor permitido é “DMARC1”. Se estiver incorreto ou a tag estiver faltando, o registro DMARC será ignorado.

Não se esqueça de usar SPF e DKIM, caso contrário o DMARC não funcionará.

Você deve considerar o uso de um serviço de processamento DMARC para detectar qualquer uso não autorizado do seu domínio e garantir a capacidade de entrega no futuro.

Reserve algum tempo para ler um pouco mais sobre o DMARC emhttps://dmarc.org/

informação relacionada