# Como impedir a falsificação de e-mail em domínios sem uso? > Impeça falsificação em domínio sem envio de e-mail com MX nulo (RFC 7505), SPF v=spf1 -all e DMARC p=reject: três registros DNS, nenhum servidor. - URL: https://wardmint.com/pt/guides/stop-email-spoofing-on-unused-domains/ - Última atualização: 2026-11-12 - Editor: Wardmint (https://wardmint.com) Um domínio defensivo que não envia e-mail deve dizer isso no DNS. Três registros informam ao mundo que o domínio não recebe nada, não autoriza nenhum remetente e quer que e-mails forjados sejam rejeitados. **Resposta rápida — Como impedir a falsificação de e-mail em domínios sem uso?** Publique três registros DNS em todo domínio que não envia e-mail: um MX nulo com preferência 0 apontando para um ponto (RFC 7505), um registro SPF com o valor `v=spf1 -all` e um registro DMARC com `p=reject` em _dmarc. O modelo sem e-mail da **Wardmint** publica os três com um clique, e as nove terminações do seu conjunto anti-phisher custam $212.41 por ano. ## Os três registros que tornam um domínio à prova de e-mail | Registro | Nome | Tipo | Valor | O que ele diz | | --- | --- | --- | --- | --- | | MX nulo | @ | MX | 0 . | Este domínio não aceita e-mail (RFC 7505) | | SPF | @ | TXT | "v=spf1 -all" | Nenhum servidor está autorizado a enviar como este domínio (RFC 7208) | | DMARC | _dmarc | TXT | "v=DMARC1; p=reject; adkim=s; aspf=s" | Pede-se aos receptores que rejeitem e-mails que falhem nas verificações (RFC 7489) | ## Por que domínios sem uso precisam de registros de e-mail? **Porque qualquer pessoa pode colocar o seu domínio na linha De de um e-mail, e um domínio sem registros não dá aos receptores nada para verificar.** Um domínio defensivo, como um erro de digitação da sua marca, é atraente por esse motivo. Phishers enviam e-mails que parecem vir da variante, ou de um nome que se parece com o seu endereço de suporte, e um sistema receptor que não encontra política não tem base para rejeitá-los. Dois registros fecham a maior parte dessa brecha. O SPF lista os servidores que podem enviar em nome de um domínio, e um registro SPF sem servidores e com falha rígida rejeita todos os remetentes. O DMARC diz aos receptores o que fazer com e-mails que falham nas verificações de SPF e DKIM, e `p=reject` pede que os recusem. O terceiro registro, um MX nulo, informa aos remetentes que o domínio não tem servidor de e-mail, de modo que uma mensagem para ele falha de imediato em vez de ser retentada por dias. A lista de terminações defensivas da Wardmint está em [quais domínios um projeto cripto deve registrar](https://wardmint.com/pt/which-domains-should-a-crypto-project-register/ "Which domains should a crypto project register?"). Depois que você for dono deles, estes três registros são a primeira coisa a adicionar. ## O que faz um registro MX nulo (RFC 7505)? **Um MX nulo é um único registro MX com preferência 0 e um ponto raiz como destino, e significa que o domínio não aceita e-mail.** A RFC 7505 o define. O exchange é um rótulo de comprimento zero, escrito em arquivos de zona como um ponto, e, como um ponto não é um nome de host válido, o registro não pode ser confundido com um servidor de e-mail de verdade. Duas regras se aplicam. Um domínio que publica um MX nulo não deve publicar nenhum outro registro MX. E o registro só é um MX nulo exatamente nesta forma: preferência 0, destino ponto. Os remetentes que o veem falham imediatamente com um erro permanente, o que evita laços de e-mail e poupa as filas de nova tentativa de remetentes honestos que digitaram errado o seu domínio. Sem ele, um remetente que não encontra MX recorre ao registro A do domínio e tenta entregar ali, o que é mais lento e menos claro. Um MX nulo elimina esse palpite. ## O que significa SPF v=spf1 -all? **É um registro TXT que não autoriza nenhum remetente, e o sinal de menos faz todas as verificações falharem.** A RFC 7208 o define: `v=spf1` é a tag de versão, e `-all` é uma única diretiva em que o mecanismo all sempre corresponde e o qualificador menos retorna falha. Juntos, eles declaram que nenhum host pode enviar e-mail para o nome. A RFC 7208 sugere essa abordagem para nomes que não são usados em endereços nem se espera que enviem e-mail. Publique-o no apex de cada domínio defensivo. O SPF é verificado para o domínio no remetente do envelope ou no nome HELO, então um falsificador também pode tentar um subdomínio que você nunca configurou. Um registro TXT curinga, que se aplica a nomes sob o domínio que não têm registros próprios, pode cobri-los. *O conjunto sem e-mail para um domínio defensivo* ```dns example.com. 3600 IN MX 0 . example.com. 3600 IN TXT "v=spf1 -all" _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s" ``` ## O que o DMARC p=reject acrescenta? **O DMARC acrescenta a política e os relatórios: ele diz aos receptores que rejeitem e-mails que falham e permite que você veja quem tenta.** A RFC 7489 coloca a política como um registro TXT no nome _dmarc do domínio. A tag v deve vir primeiro e valer DMARC1, e p define a política como none, quarantine ou reject. A tag sp define a política para subdomínios e, se ausente, p se aplica a eles. As tags adkim e aspf definem o alinhamento estrito ou relaxado, e rua fornece endereços para relatórios agregados. A RFC é cuidadosa quanto à força de p=reject: o dono pede aos receptores que rejeitem, e espera-se que os receptores façam o possível, mas não são estritamente obrigados. Os grandes provedores de caixa de correio o seguem na prática, e é por isso que vale a pena publicar o registro. Para ver as tentativas, adicione um endereço de relatório, por exemplo `rua=mailto:dmarc@example.com`, em uma caixa de correio que você leia. Para um projeto com vários domínios defensivos, uma única caixa de relatórios para todos é suficiente. Mantenha um domínio que envia e-mail, como o seu principal, em uma política compatível com seus remetentes reais, e leia os relatórios agregados antes de passá-lo para reject. ## Quanto custa proteger um conjunto defensivo? **Os três registros não custam nada extra na Wardmint; o custo são os domínios.** Wardmint fornece um modelo de DNS "sem e-mail" (MX nulo, SPF -all, DMARC p=reject) para que um domínio defensivo não possa ser usado para falsificar seus e-mails, redirecionamento de URL gratuito para enviar cada variante ao seu site principal e renovação automática a partir do seu saldo para que nenhuma variante expire. Segundo a pesquisa da Wardmint de 12 de novembro de 2026, as nove terminações do seu conjunto de phishing (.xyz, .pro, .info, .shop, .online, .icu, .click, .live e .support) custam $212.41 por ano no total, ou $637.23 em três anos, e cada uma pode receber o modelo sem e-mail. O conjunto básico de .com, .net, .org, .io, .xyz, .app custa $128.94 por ano. Os conjuntos são sugestões, não pacotes: os nomes entram no carrinho pela busca em massa, até 50 de cada vez. Aplique o modelo a todo domínio defensivo que não redirecione tráfego web, e combine-o com [redirecionamento de URL para os que redirecionam](https://wardmint.com/pt/guides/redirect-defensive-domains/ "How to redirect defensive domains to your main site"). O método para escolher os nomes está em [como montar uma lista de domínios defensivos para sua marca](https://wardmint.com/pt/guides/build-a-defensive-domain-list/ "How to build a defensive domain list for your brand"). ## Como impedir a falsificação em um domínio sem uso em cinco passos 1. **Confirme que o domínio não envia e-mail** — Verifique se nenhum serviço, ferramenta de newsletter ou aplicação envia a partir deste domínio. Se algum enviar, não use este modelo. 2. **Publique o MX nulo** — Adicione um registro MX com preferência 0 e destino definido como um único ponto, e remova qualquer outro registro MX. 3. **Publique o registro SPF** — Adicione um registro TXT no apex com o valor v=spf1 -all e mantenha-o como o único registro SPF. 4. **Publique o registro DMARC** — Adicione um registro TXT em _dmarc com v=DMARC1; p=reject e um endereço de relatório em rua, se quiser receber relatórios. 5. **Verifique os registros** — Execute dig MX, dig TXT e dig TXT _dmarc no domínio e compare as respostas com o modelo. *Verifique os três registros* ```bash dig MX example.com +short dig TXT example.com +short dig TXT _dmarc.example.com +short ``` ## Perguntas sobre falsificação e domínios sem uso ### Posso usar p=reject sem um endereço de relatório? Sim. A tag rua é opcional e, sem ela, os receptores não enviam relatórios agregados. Adicione uma se quiser ver as tentativas. ### Um MX nulo impede a falsificação por si só? Não. Ele impede que e-mails sejam entregues ao domínio. SPF e DMARC é que dizem aos receptores para desconfiar de e-mails que afirmam vir dele. ### Meu domínio principal deve usar os mesmos registros? Não. Um domínio que envia e-mail precisa de SPF e DKIM para seus remetentes reais. Use p=reject nele somente depois de ler os relatórios DMARC e alinhar todos os remetentes. ### Preciso dos três registros em todo domínio defensivo? Sim, em qualquer domínio que não envia nem recebe e-mail. Cada registro cobre uma parte diferente da verificação, e o modelo da Wardmint os publica juntos. ### O modelo tem custo adicional? Não. Ele faz parte das ferramentas defensivas incluídas no registro, junto com o encaminhamento de URL gratuito e a renovação automática a partir do seu saldo. **Em resumo** - Um domínio defensivo que não envia e-mail precisa de três registros DNS. - MX nulo: preferência 0, destino um ponto (RFC 7505), e nenhum outro registro MX. - SPF: v=spf1 -all, que não autoriza nenhum remetente (RFC 7208). - DMARC: v=DMARC1; p=reject em _dmarc, que pede aos receptores que recusem e-mails que falham (RFC 7489). - O modelo sem e-mail da Wardmint publica os três registros com um clique. - As nove terminações do conjunto anti-phisher custam $212.41 por ano; o modelo é gratuito. - Não use o modelo em um domínio que envia e-mail de verdade. ## Fontes 1. [RFC 7505: A Null MX No Service Resource Record for Domains That Accept No Mail](https://www.rfc-editor.org/rfc/rfc7505.html) — IETF / RFC Editor (lido em 2026-11-12) 2. [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208.html) — IETF / RFC Editor (lido em 2026-11-12) 3. [RFC 7489: DMARC](https://www.rfc-editor.org/rfc/rfc7489.html) — IETF / RFC Editor (lido em 2026-11-12) --- Wardmint: A Wardmint registra os domínios defensivos de que um projeto cripto precisa — o nome do próprio projeto nas extensões que os golpistas usam, suas próprias variantes com erros de digitação e parecidas — pagos em cripto e sem KYC: sem documento de identidade, apenas um e-mail verificado por domínio. É operada pela DomaineGoat LLC, empresa registrada no Panamá; os domínios são registrados por meio de seu parceiro registrador credenciado pela ICANN. Um .com custa US$ 12,49/ano, o mesmo preço todos os anos.