Defaults.Exposed › Correções › DMARC (Proteção contra Falsificação de E-mail)

Como corrigir DMARC (Proteção contra Falsificação de E-mail)

O DMARC é a única definição que efetivamente diz aos fornecedores de correio do mundo para BLOQUEAREM e-mails que falsificam o nome da sua empresa. O SPF e o DKIM verificam as fechaduras; o DMARC decide o que acontece quando uma falsificação não passa na verificação — deitar fora, sinalizar ou deixar passar. Mal configurado, o seu domínio é totalmente falsificável; bem configurado, a imitação para à porta da caixa de entrada.

O essencial para o seu negócio: Sem imposição de DMARC, um criminoso pode enviar e-mails que parecem exatamente vir da sua empresa — para os seus clientes, colaboradores e fornecedores — e eles caem na caixa de entrada, não no spam. Há pessoas a serem burladas em seu nome, e a culpa é-lhe atribuída a si.

Quanto isto lhe pode custar

Um burlão envia ao seu cliente uma fatura realista «da sua equipa de contabilidade» com os dados bancários dele. O cliente paga-a. Só descobre semanas depois, quando lhe perguntam pela mercadoria que já pagaram — e responsabilizam-no a si.
Um e-mail falso de «pagamento urgente» chega à sua pessoa das finanças, parecendo vir de si, o dono. Faz a transferência antes de alguém pensar em confirmar — e, uma vez na conta de um criminoso, quase nunca se recupera.
A equipa de TI de um cliente importante faz uma verificação de segurança ao seu domínio antes de assinar. O resultado é «e-mail não protegido — pode ser falsificado». Perde o negócio para um concorrente cujo domínio passou.
O seu domínio é usado numa vaga de phishing. Os clientes que foram enganados deixam críticas furiosas e avisam os outros. Os danos à reputação duram meses para além do ataque.
Até o seu e-mail genuíno começa a ir para o lixo, porque o Google e o Yahoo desconfiam cada vez mais — e agora por vezes rejeitam — domínios sem DMARC imposto.

Por que importa. O e-mail nunca foi construído para provar quem realmente o enviou, por isso falsificar o endereço «de» é trivial. O DMARC é o único controlo que transforma «conseguimos detetar falsificações» em «as falsificações são bloqueadas» — e dá-lhe também os relatórios diários que revelam quem está a enviar correio em nome da sua marca. Os grandes fornecedores de correio tratam agora uma política DMARC em falta ou não imposta como um sinal de desconfiança contra si, por isso isto afeta também se o seu próprio e-mail é entregue.

O que é o DMARC, em palavras simples

O e-mail tem um segredo sujo: a linha «de» é apenas texto escrito. Qualquer pessoa, em qualquer lado, pode escrever o nome e o endereço da sua empresa no campo «de» de um e-mail e enviá-lo. A internet nunca foi desenhada para os impedir.

Há três definições que, em conjunto, resolvem isto. Pense nelas como a segurança de um edifício:

O SPF é a lista de quem pode entrar pela porta principal (que serviços de correio podem enviar por si).
O DKIM é um selo à prova de adulteração que prova que a mensagem não foi alterada em trânsito.
O DMARC é o segurança que verifica a lista e o selo — e, crucialmente, decide o que fazer quando não batem certo: deixar passar, mandar para o spam ou recusar à porta.

Pode ter a lista (SPF) e o selo (DKIM) e mesmo assim não ter segurança nenhuma. É a situação mais comum e mais perigosa: as fechaduras existem, mas nada as impõe. O DMARC é a imposição. É a diferença entre «conseguimos perceber que este e-mail é falso» e «este e-mail falso nunca chega ao seu cliente».

Quanto isto lhe pode custar

Isto não é teórico. Eis as formas concretas em que um domínio desprotegido se transforma em dinheiro real e dano real:

A burla da fatura falsa. Um criminoso envia ao seu cliente algo que parece exatamente uma fatura genuína da sua equipa de contabilidade — mesmo nome, mesmo domínio, aspeto profissional — mas com os dados bancários dele. Como o seu domínio não está imposto, cai na caixa de entrada, não no spam. O cliente paga. Descobre-o semanas depois, quando lhe perguntam onde está a encomenda. O dinheiro normalmente já se perdeu, e o cliente muitas vezes responsabiliza-o a si pela falha.
A transferência por fraude do CEO. Um e-mail parece vir de si, o dono, para a sua pessoa das finanças: «Consegues processar este pagamento com urgência, estou numa reunião.» Parece completamente real porque é o seu endereço — apenas falsificado. O pagamento sai. Este padrão — Comprometimento de E-mail Empresarial — é uma das burlas mais caras a atingir pequenas empresas, precisamente porque o e-mail vem mesmo do seu próprio domínio, passando direto pela desconfiança.
O contrato perdido. Um cliente sério faz uma verificação de segurança ou de compras antes de assinar. As ferramentas dele relatam o seu domínio como «falsificável — sem imposição de autenticação de e-mail». Esse único sinal vermelho pode bastar para entregar o contrato a um concorrente cujo domínio passou. Nunca chega a saber a verdadeira razão.
O dano de reputação que não se desfaz. O seu domínio é arrastado para uma campanha de phishing. Dezenas de pessoas enganadas em seu nome publicam avisos e críticas. O ataque dura uma semana; a pergunta «esta empresa é sequer segura?» persiste durante meses.
O seu próprio e-mail a ir para o spam. O Google e o Yahoo desconfiam agora ativamente de domínios sem DMARC imposto. Orçamentos, faturas e respostas que enviou genuinamente começam a cair em silêncio nas pastas de spam. Os negócios estagnam e nunca descobre porquê.

O que é na realidade (e como é o «bom»)

O DMARC vive como uma única linha de texto nas definições do seu domínio — um registo DNS «TXT» publicado no nome especial _dmarc.seudominio. Lá dentro estão algumas instruções curtas. Duas delas importam mais, e são exatamente as duas coisas que esta avaliação verifica.

1. A política (p=) — as ordens do segurança. Esta é a parte de peso elevado da verificação. Pode ser uma de três coisas:

p=none — só vigiar. O segurança aponta quem passou mas não para ninguém. Isto não o protege contra nada; é uma fase de monitorização, não uma configuração acabada. (O nosso motor pontua isto como falha — melhor do que nenhum DMARC, mas não é proteção.)
p=quarantine — mandar as falsificações para o spam. Proteção real, mas um atacante determinado aposta em que as pessoas verificam a pasta de spam. Um degrau sólido — vale cerca de metade da pontuação.
p=reject — recusar as falsificações à porta. O e-mail falsificado nunca é entregue. É a única definição que o protege por completo e merece pontuação máxima.

Como é o «bom»: p=reject. Qualquer coisa menos deixa uma brecha.

Dois detalhes técnicos que a nossa verificação também observa, vale a pena conhecê-los para não ser apanhado:

A política de subdomínios (sp=). Pode definir uma política forte para o seu domínio principal e deixar acidentalmente os subdomínios (como mail.seudominio ou news.seudominio) totalmente abertos. O nosso motor penaliza isto fortemente — um domínio com p=reject mas sp=none é pontuado em baixo, perto de não ter imposição nenhuma, porque os atacantes vão simplesmente falsificar um subdomínio. A boa prática é deixar o sp herdar a sua política principal forte, ou defini-lo explicitamente como reject.
A percentagem (pct=). Durante uma implementação cuidadosa pode aplicar a imposição apenas a uma fração do correio (ex.: pct=25). É uma ferramenta de transição legítima, mas uma implementação parcial só dá proteção parcial, e a nossa pontuação reflete isso — sobe de forma constante à medida que avança de 25% para 100%, mas a pontuação máxima exige cobertura total.

2. O endereço de relatório (rua=) — a sua visibilidade. Esta é a segunda verificação desta página. A etiqueta rua= pede a todos os fornecedores de correio do mundo que lhe enviem um resumo diário de quem tentou enviar e-mail em nome do seu domínio — os seus próprios sistemas e quaisquer imitadores. Sem ela, está às cegas: não faz ideia de quem está a abusar do seu nome. Com ela, as empresas descobrem rotineiramente entre 5 e 50 remetentes não autorizados logo no primeiro dia.

Como é o «bom» para o relatório: um endereço rua=mailto: válido (ou um URL https: de um serviço de relatórios) que receba mesmo os relatórios. A nossa verificação valida o formato — um endereço mal escrito ou malformado faz com que os relatórios desapareçam em silêncio, o que pontua como resultado parcial ou falhado, mesmo que uma etiqueta esteja tecnicamente «presente».

Como corrigir (gratuito, ~30 minutos distribuídos por duas semanas)

Entregue esta secção a quem gere o seu domínio, site ou TI — a correção é completamente gratuita. Só cobramos para monitorizar que se mantém correto ao longo do tempo, para gerir um portefólio de domínios ou por uma auditoria. A alteração em si não custa nada.

A regra de ouro: nunca salte direto para reject. Ligue primeiro a monitorização, observe os relatórios, confirme que o seu correio real é reconhecido e só depois aperte. Feito por esta ordem, é seguro; feito à pressa, pode mandar o seu próprio e-mail para o lixo.

Passo 1 — Garanta que o SPF e o DKIM estão primeiro no lugar. O DMARC depende deles. Se algum faltar, resolva-os antes de impor o DMARC (veja as páginas do SPF e do DKIM).

Passo 2 — Publique um registo de monitorização com relatórios ligados. Adicione um registo DNS TXT:

Host / nome: _dmarc.seudominio (o seu fornecedor de DNS pode mostrar isto apenas como _dmarc)
Tipo: TXT
Valor: v=DMARC1; p=none; rua=mailto:dmarc@seudominio; adkim=s; aspf=s

Isto vigia e relata sem bloquear ainda nada. As partes adkim=s; aspf=s pedem alinhamento estrito — deixe-as de fora ao início se tiver dúvidas, e acrescente-as quando o seu correio estiver confirmado como limpo.

Passo 3 — Leia os relatórios durante ~2 semanas. Os relatórios DMARC em bruto são XML denso. Use um serviço de relatórios gratuito (por exemplo o dmarcian ou a ferramenta DMARC gratuita do Postmark) para os transformar num painel legível. Confirme que todos os remetentes legítimos — o seu fornecedor de caixa de correio, ferramenta de newsletter, CRM, helpdesk, aplicação de faturação — estão a passar. Corrija qualquer remetente genuíno que não esteja.

Passo 4 — Passe para quarantine. Quando o seu correio real estiver limpo, mude p=none para p=quarantine. Observe mais uns dias.

Passo 5 — Passe para reject. Por fim, mude p=quarantine para p=reject. Está agora totalmente protegido. O registo final fica assim:

v=DMARC1; p=reject; rua=mailto:dmarc@seudominio; adkim=s; aspf=s

Passo 6 — Não esqueça os subdomínios. Confirme que não deixou sp=none no lugar. Se não publicar nenhum sp, os subdomínios herdam a política p= principal, que é o que quer.

Notas por plataforma comum:

Google Workspace / Microsoft 365: Ambos suportam totalmente o DMARC. O registo DMARC em si vai no seu fornecedor de DNS, não na consola de administração do Google ou da Microsoft — garanta primeiro que o SPF e o DKIM estão ativados na consola de administração e depois publique o registo DMARC TXT no seu registrar/fornecedor de DNS.
Cloudflare: DNS > Records > Add record > TXT, nome _dmarc, cole o valor. A Cloudflare também oferece gestão de DMARC integrada que pode configurar isto e recolher os relatórios por si.
Alojamentos / registrars comuns (GoDaddy, etc.): Procure «DNS», «DNS Zone» ou «Advanced DNS», adicione um registo TXT com nome _dmarc e o valor acima. A propagação costuma levar de uns minutos a uma hora.

Erros comuns

Parar em p=none. O erro mais comum de longe. A monitorização é o início, não o fim — um domínio preso em «none» continua totalmente falsificável. O nosso motor pontua-o como falha exatamente por esta razão.
Saltar direto para reject sem monitorizar. O erro oposto. Sem a fase de relatórios pode não reparar que um remetente legítimo (muitas vezes uma ferramenta de newsletter ou de faturação) não está alinhado — e vai começar a bloquear o seu próprio correio.
Esquecer a política de subdomínios. Um p=reject forte com sp=none deixa uma porta lateral escancarada; os atacantes limitam-se a falsificar um subdomínio.
Um endereço de relatório avariado. Um rua= mal escrito (ou sem o prefixo mailto:) faz com que os relatórios não cheguem a lado nenhum e fique às cegas sem perceber. O formato tem de ser um URI mailto: ou https: válido, ou os relatórios nunca são entregues.
«Não enviamos e-mail, por isso ignoramos.» Um domínio que não envia é um alvo de eleição precisamente porque ninguém o está a vigiar. Publique uma política estrita de reject para o trancar por completo.

Uma nota sobre a avaliação

A verificação da política (p=) é um dos itens de maior peso de toda a avaliação — porque é o maior fator isolado em saber se a sua empresa pode ser imitada. reject merece a pontuação total; quarantine merece cerca de metade; none e um registo em falta pontuam como falhas. Uma política de subdomínios mais fraca ou uma implementação parcial com pct= puxam a pontuação para baixo, para corresponder ao nível real de proteção que realmente tem.

A verificação do relatório (rua=) também tem peso real, mas pense nela menos como uma caixa a marcar e mais como a ferramenta que lhe permite chegar a reject em segurança. Configure-a ao mesmo tempo que o seu registo de monitorização e ela paga-se a si própria em visibilidade logo no primeiro dia.

Configure no seu fornecedor

Passo a passo para os fornecedores mais populares:

Perguntas frequentes

Não percebo nada de informática — é algo que consigo mesmo resolver?

Sim, mas não tem de o fazer pessoalmente. A correção são umas linhas adicionadas às definições do seu domínio, e é gratuita. O caminho mais simples é reencaminhar a secção «Como corrigir» abaixo a quem gere o seu site ou ao seu suporte de TI. Costuma levar-lhes bem menos de uma hora, distribuída por umas semanas de monitorização segura.

Ligar o DMARC pode acidentalmente impedir os meus próprios e-mails de chegarem?

Pode — mas só se saltar a implementação segura. Todo o objetivo de começar em «só monitorizar» (p=none) com relatórios ligados é vigiar durante duas semanas e confirmar que todos os remetentes legítimos (a sua caixa de correio, a ferramenta de newsletter, a aplicação de faturação) são corretamente reconhecidos ANTES de passar para bloqueio. Feito por esta ordem, o seu correio real não é afetado. Correr direto para «reject» sem ler os relatórios é o erro comum que estraga a entrega.

Já tenho o SPF e o DKIM configurados. Não basta?

Não — e este é o ponto mais importante a perceber. O SPF e o DKIM são as fechaduras; o DMARC é a instrução que diz «se as fechaduras não baterem certo, recusa o e-mail». Sem DMARC em «reject», um servidor recetor pode reparar que um e-mail é falsificado e entregá-lo na mesma. O SPF e o DKIM são pré-requisitos para o DMARC funcionar, mas por si só não impedem que um e-mail falsificado chegue à caixa de entrada.

Qual é a diferença entre «none», «quarantine» e «reject»? De qual preciso?

«none» só vigia e relata — não impede nada, por isso não o protege. «quarantine» manda as falsificações para a pasta de spam. «reject» recusa-as de imediato, por isso nunca chegam. «reject» é o objetivo e a única definição que merece pontuação máxima. «quarantine» é um degrau razoável; «none» é um ponto de partida para as primeiras semanas, não um destino.

O que é essa coisa do relatório «rua», e preciso dela?

A etiqueta rua pede aos fornecedores de correio que lhe enviem um resumo diário de todos os sistemas que tentaram enviar e-mail em nome do seu domínio — incluindo os criminosos. É assim que as empresas descobrem os 5 a 50 remetentes não autorizados que tipicamente abusam de um domínio logo no primeiro dia. Por si só tem menos peso que a política, mas é como passa para «reject» em segurança sem estragar o seu correio real, por isso configure-a ao mesmo tempo.

Quase não enviamos e-mail, ou não enviamos e-mail deste domínio de todo. Mesmo assim precisamos de DMARC?

Sobretudo nesse caso. Um domínio que envia pouco ou nenhum correio real é um alvo perfeito e silencioso para os criminosos imitarem, porque ninguém está a vigiar. Um domínio do qual nunca envia correio deve publicar uma política estrita de reject — é uma vitória limpa e de baixo risco que fecha a porta por completo.