Política DMARC Explicada: None, Quarantine e Reject

Uma política DMARC é a instrução no seu registo DMARC que diz aos servidores de e-mail recetores o que fazer com os e-mails que falham na autenticação. Existem três opções: nenhuma (apenas monitorizar), quarentena (enviar para spam) e rejeitar (bloquear totalmente). Esta única etiqueta, escrita como p= no seu registo DNS, é a diferença entre o DMARC que apenas observa o tráfego de e-mail e o DMARC que realmente impede que mensagens falsificadas cheguem a uma caixa de entrada.

Se já tem um registo DMARC, a política é fácil de encontrar. Fica logo após p= no registo:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Neste exemplo, a política é quarentena. Abaixo, detalharei o que cada uma das três políticas faz, mostrarei a sintaxe exata do registo para cada uma e apresentarei um cronograma realista para a transição do monitoramento para a aplicação total.

Já tem uma política DMARC definida?

Se não tem a certeza se o seu domínio tem um registo DMARC ou qual a política que está a usar, essa é a primeira coisa a verificar antes que qualquer um destes pontos seja relevante.

A forma mais fácil é uma ferramenta gratuita de consulta DMARC como a MXToolbox. Introduza o seu domínio e ela mostrar-lhe-á o registo completo, incluindo o valor p=, se existir. Verá uma das três coisas:

• Nenhum registo DMARC encontrado. O seu domínio não tem qualquer política, o que significa que qualquer pessoa pode falsificar o seu domínio em e-mails sem qualquer consequência.
• Um registo com p=none. O DMARC está configurado em modo de monitorização, mas ainda não está a aplicar nada.
• Um registo com p=quarentena ou p=reject. O DMARC está ativamente a aplicar uma política.

Se nada aparecer, terá de criar um registo DMARC antes que uma política se aplique a si. Escrevi um guia completo, com capturas de ecrã para adicionar o registo através do seu fornecedor de DNS, em como criar um registo DMARC. Esse guia cobre onde os registos DNS residem (o seu host, registrador ou CDN), os campos exatos a preencher e como confirmar que o registo está ativo assim que o publicar.

Enquanto verifica, também vale a pena confirmar que o próprio e-mail de saída do seu site WordPress está configurado para passar SPF e DKIM em primeiro lugar. WP Mail SMTP mostra-lhe o estado de autenticação de cada e-mail que o seu site envia, para que não esteja a adivinhar se o seu próprio site é uma das fontes que o DMARC está prestes a sinalizar.

Corrija os Seus Emails do WordPress Agora

O resto deste post assume que já tem um registo ou acabou de criar um, e quer entender qual política escolher e quando a alterar.

Nenhuma vs. quarentena vs. rejeitar num relance

p=none: monitorização sem aplicação

p=none é a política inicial para qualquer domínio que publique DMARC pela primeira vez. Diz aos servidores de receção para não tomarem qualquer ação sobre e-mails que falhem a autenticação. As mensagens que falham são entregues exatamente como seriam sem DMARC. A única coisa que muda é que começa a receber relatórios agregados mostrando quais as fontes que estão a enviar e-mail como o seu domínio e se estão a passar na autenticação SPF e DKIM.

v=DMARC1; p=none; rua=mailto:[email protected]

O que p=none faz:

• Gera visibilidade sobre todos os servidores que enviam e-mail em nome do seu domínio
• Tem impacto zero na entregabilidade, uma vez que não é tomada qualquer ação de aplicação
• Não requer qualquer configuração prévia de SPF ou DKIM para ser publicada

O que p=none não faz:

• Parar tentativas de phishing ou spoofing usando o seu domínio
• Proteger a sua marca ou os seus destinatários de qualquer forma
• Servir como uma política válida a longo prazo

Um domínio que permaneça indefinidamente em p=none tem um registo DMARC mas sem proteção real. Este é o erro mais comum nas implementações DMARC: tratar a monitorização como a linha de chegada em vez do primeiro passo.

p=quarentena: a política de aplicação transitória

p=quarantine instrui os servidores de receção a tratar as mensagens que falham com suspeita, tipicamente encaminhando-as para a pasta de spam ou lixo eletrónico do destinatário em vez da caixa de entrada. O e-mail não é bloqueado de imediato. Ainda chega, apenas não onde normalmente chegaria.

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Exatamente como "quarantine" é tratado varia ligeiramente por provedor de e-mail. Alguns marcam a mensagem como suspeita em vez de a mover. A maioria, incluindo Gmail e Outlook, envia-a para o spam. De qualquer forma, o efeito prático é o mesmo: e-mails legítimos que falham a autenticação tornam-se mais difíceis de ver para o destinatário, razão pela qual quarantine só deve ser definido quando tiver a certeza de que todos os seus remetentes conhecidos estão devidamente configurados.

Por que os domínios usam quarantine como um passo intermédio:

• Captura más configurações antes que se tornem devoluções. Se um remetente legítimo começar a falhar o DMARC, o e-mail vai para o spam em vez de desaparecer completamente. Pode detetar o problema e corrigi-lo.
• Constrói confiança para reject. Observar o quarantine a funcionar sem problemas durante algumas semanas é o sinal mais claro de que está pronto para a aplicação total.
• Pode ser aplicado gradualmente. A tag pct permite colocar apenas uma percentagem de e-mails com falha em quarentena inicialmente (mais sobre isto abaixo).

p=reject: aplicação total

p=reject é a política mais rigorosa. Instruí os servidores de receção a bloquear e-mails que falhem a autenticação DMARC antes mesmo de serem entregues. Sem caixa de entrada, sem pasta de spam. A mensagem é recusada.

v=DMARC1; p=reject; rua=mailto:[email protected]

Existem duas formas comuns de os servidores de receção implementarem reject:

• Recusa na ligação SMTP. O servidor de receção recusa a mensagem durante a ligação inicial, antes de ser totalmente aceite. Este é o método mais amplamente utilizado e o recomendado pela maioria dos provedores de e-mail.
• Aceitar e depois descartar. O servidor aceita a mensagem e depois descarta-a silenciosamente ou devolve-a ao remetente. Isto acontece com menos frequência, mas ainda é válido de acordo com a especificação DMARC.

A rejeição é o objetivo final de qualquer implementação DMARC séria. É também a política em que os erros são mais visíveis. Se um remetente legítimo não foi autenticado corretamente, o seu e-mail não chegará ao spam onde pode ser encontrado. Simplesmente não chegará, e não haverá falha temporária para o alertar.

As etiquetas pct e sp

Duas etiquetas adicionais permitem controlar como uma política é aplicada, e ambas valem a pena conhecer antes de avançar para além de p=none.

pct controla que percentagem de e-mails com falha recebe a política. Em vez de saltar diretamente para 100% de aplicação, pode aplicar quarentena ou rejeição a uma fatia menor do tráfego com falha primeiro.

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

As mensagens fora dessa percentagem são tratadas como se a política ainda fosse p=none. Isto dá-lhe uma progressão gradual em vez de um interruptor tudo ou nada, e é a forma mais segura de avançar para a aplicação se não tiver a certeza de que todos os remetentes foram contabilizados.

sp define uma política separada para subdomínios. Sem ela, os subdomínios herdam qualquer política que defina para o domínio principal.

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

Este exemplo aplica a rejeição no domínio raiz, enquanto dá aos subdomínios uma política de quarentena mais suave, útil se um subdomínio for gerido por uma equipa diferente ou ainda não tiver sido totalmente autenticado. Ignorar esta etiqueta é uma falha comum: um domínio pode ser totalmente bloqueado com p=reject, enquanto um subdomínio não monitorizado permanece totalmente aberto à falsificação.

Quanto tempo demora a transição de nenhuma para rejeitar

Não existe um cronograma fixo na especificação DMARC, mas apressar a implementação é a forma mais comum de o e-mail legítimo ser bloqueado. Um ritmo defensável e comummente recomendado parece ser este:

• Mantenha p=none durante pelo menos 2 a 4 semanas, e mais tempo se o seu domínio enviar através de várias ferramentas de terceiros (plataformas de marketing, CRMs, software de helpdesk, ferramentas de faturação). Utilize esta janela para rever os relatórios agregados e confirmar que todos os remetentes legítimos estão a passar na autenticação SPF ou DKIM.
• Avance para p=quarantine assim que os remetentes conhecidos estiverem limpos, começando com um valor baixo de pct como 25 e aumentando-o à medida que os relatórios se mantêm livres de tráfego legítimo a ser apanhado.
• Avance para p=reject apenas depois de a quarentena ter sido executada a 100% sem que e-mails legítimos sejam afetados. A maioria dos domínios atinge esta fase entre alguns meses e cerca de um ano após o início, dependendo de quantas fontes de envio precisam de autenticar.

Ignorar etapas é onde a maioria das implementações DMARC corre mal. Um domínio com um único fornecedor de e-mail pode avançar rapidamente. Um domínio que envia através de uma dúzia de ferramentas de marketing, suporte e transacionais precisa de mais tempo, porque cada uma dessas fontes tem de passar na autenticação antes que a aplicação seja segura.

Erros comuns a evitar

• Saltar diretamente para a rejeição. Publicar p=reject antes de confirmar que todos os remetentes legítimos estão autenticados irá rejeitar e-mails reais, por vezes sem qualquer aviso.
• Nunca sair de p=none. Um registo DMARC sem uma política de aplicação fornece visibilidade, mas não proteção real contra spoofing.
• Esquecer subdomínios. Se sp não estiver definido, um atacante pode visar um subdomínio que não foi bloqueado, mesmo que o domínio principal esteja totalmente aplicado.
• Saltar a rampa. Passar de p=none para 100% de rejeição num único passo é mais arriscado do que passar gradualmente pelos valores de pct.
• Não reavaliar após adicionar novos remetentes. Uma nova ferramenta de marketing ou serviço de e-mail transacional precisa de passar na verificação SPF ou DKIM antes de ser adicionada ao seu conjunto de remetentes, ou começará a falhar no DMARC no momento em que a aplicação estiver ativa.

Ignorar etapas é onde a maioria das implementações DMARC corre mal. Um domínio com um único fornecedor de e-mail pode avançar rapidamente. Um domínio que envia através de uma dúzia de ferramentas de marketing, suporte e transacionais precisa de mais tempo, porque cada uma dessas fontes tem de passar na autenticação antes que a aplicação seja segura.

Se o seu site WordPress for uma dessas fontes de envio, vale a pena verificar cedo. A função de e-mail padrão do WordPress envia através da função mail() do PHP ou do que quer que o servidor esteja configurado para usar, o que muitas vezes falha no alinhamento SPF e DKIM, mesmo quando o resto do seu domínio está configurado corretamente. O WP Mail SMTP encaminha os e-mails do WordPress através de uma ligação SMTP autenticada, para que os próprios e-mails do seu site não se tornem o único remetente a impedir a sua transição para quarentena ou rejeição.

Corrija os Seus Emails do WordPress Agora

FAQ

O que significa DMARC p=none? p=none significa que o DMARC está em modo de monitorização. Os e-mails que falham na autenticação ainda são entregues normalmente, mas recebe relatórios que mostram quais as fontes que estão a enviar e-mails como se fossem do seu domínio e se estão a passar nas verificações.

Qual é a diferença entre quarentena e rejeição DMARC? Quarentena envia e-mails com falha para a pasta de spam do destinatário, pelo que ainda são entregues, mas mais difíceis de ver. Rejeição bloqueia e-mails com falha antes da entrega, pelo que nunca chegam, nem mesmo ao spam.

Quanto tempo deve permanecer em p=none? Pelo menos 2 a 4 semanas, embora domínios com vários remetentes de terceiros necessitem frequentemente de mais tempo para confirmar que todas as fontes estão devidamente autenticadas antes de passar para a aplicação.

Uma política DMARC afeta a entregabilidade? p=none não tem efeito na entregabilidade. p=quarantine e p=reject podem afetar a entregabilidade se algum remetente legítimo não tiver sido autenticado corretamente, razão pela qual ambos só devem ser aplicados gradualmente e após a monitorização confirmar que os seus remetentes estão limpos.

Em seguida, Crie um Registo DMARC

Assim que souber qual a política que se adequa ao seu estado de implementação, publicar o registo corretamente é tão importante quanto escolher o certo. O meu guia sobre como criar um registo DMARC detalha a adição da sintaxe exata ao seu DNS, passo a passo, para que não haja risco de um erro de digitação quebrar a sua aplicação.

Pronto para corrigir os seus emails? Comece hoje mesmo com o melhor plugin SMTP para WordPress. Se não tem tempo para corrigir os seus emails, pode obter assistência completa de Configuração White Glove como compra adicional, e existe uma garantia de reembolso de 14 dias para todos os planos pagos.

Se este artigo o ajudou, por favor siga-nos no Facebook e Twitter para mais dicas e tutoriais do WordPress.