Domínio sem email: a configuração Null MX
Por CaptainDNS
Publicado em 29 de agosto de 2026
- Publique um único MX com prioridade
0cujo alvo seja.: a ausência de MX ainda dispara um fallback para o endereço A ou AAAA. - Para o envio, use o SPF nu
v=spf1 -alle DMARC comp=reject; sp=reject; np=reject. Coloque oruaem outro domínio que receba de verdade. - Não publique nenhum seletor DKIM. Um
p=vazio revoga uma chave antiga; não é a política de um domínio que não envia. - A auditoria pública exibe um recebimento completo, mas uma zona de referência fica na faixa Bom, em torno de 80-85 conforme
ruae DNSSEC.
Um domínio sem email parece simples de administrar: nenhuma caixa de entrada, nenhum servidor SMTP, portanto nada a configurar. É justamente aí que está a armadilha. Uma zona deixada com os valores do registrador pode ainda conter um MX padrão. Um SPF amplo demais pode continuar autorizando um antigo fornecedor. Sem política DMARC, os destinatários não recebem nenhuma orientação firme contra a falsificação de identidade.
Outro erro frequente: excluir todos os MX e achar que o recebimento está fechado. O protocolo SMTP previu um fallback para os endereços A ou AAAA quando nenhum MX existe. No caso de um site, esse fallback aponta exatamente para o servidor que serve o site. Ele pode responder mal ou com atraso, mas o remetente remoto terá mesmo assim tentado entregar mensagens a ele.
A receita abaixo trata dois usos na mesma zona de referência: um site institucional ou uma aplicação em HTTPS sem nenhuma caixa de entrada e, depois, um domínio defensivo sem site e sem certificado. A base de email é idêntica. O CAA muda, porque o primeiro precisa continuar renovando o certificado enquanto o segundo precisa proibir qualquer emissão.
Verifique a zona e gere sua política DMARC
O problema de uma zona deixada no padrão
Um domínio sem email deve anunciar explicitamente que não recebe nem envia mensagens. O silêncio do DNS deixa intactos os comportamentos de fallback e as autorizações antigas.
Comece inventariando a zona. Procure os MX adicionados pelo registrador, os TXT SPF históricos, _dmarc, os seletores sob _domainkey, os endereços A e AAAA e, por fim, os CAA. Um MX que aponta para uma oferta de email gratuita não é inofensivo: se alguém criar uma caixa mais tarde por engano, o domínio volta a receber. Um SPF que contém include: continua autorizando o serviço indicado a apresentar este domínio no envelope SMTP.
Uma zona sem DMARC também deixa cada destinatário decidir sozinho o destino de uma mensagem falsificada. O SPF pode falhar, mas o DMARC é a camada que liga a autenticação ao domínio visível no endereço From e publica uma política. Para este caso fechado o objetivo é claro: nenhuma fonte legítima existe, então toda mensagem que diz vir do domínio precisa ser rejeitada.
O resultado esperado não é uma coleção de mecanismos de email. É uma declaração negativa coerente: nenhum destino de recebimento, nenhum remetente autorizado, uma política de rejeição e nenhuma chave DKIM inventada. Menos registros, mas cada um com um sentido preciso.
Null MX fecha explicitamente o recebimento
Um Null MX é um único registro MX com prioridade 0 cujo alvo é o nome raiz .. A RFC 7505 o define para anunciar que um domínio não aceita mensagens.
A representação na zona é curta:
example.com. IN MX 0 .
Conforme a interface DNS, o alvo pode aparecer como um ponto, um valor vazio ou uma opção dedicada "Null MX". O resultado publicado precisa continuar sendo um único MX com preferência zero e um nome de troca vazio. Não adicione um segundo MX reserva: a presença de outro alvo contradiz a declaração.
A ausência de MX não tem o mesmo sentido
Sem resposta MX, um remetente SMTP pode tentar o endereço A ou AAAA do domínio como se fosse um servidor de troca implícito. Esse comportamento histórico é a principal razão para publicar Null MX mesmo em um domínio que não hospeda nenhum site.
Com Null MX, o remetente entende que a entrega é impossível e não tenta o servidor web. Na auditoria CaptainDNS, essa configuração obtém o recebimento completo. MTA-STS, DANE e TLS-RPT deixam de ser necessários: eles protegem um transporte SMTP que não existe, e a auditoria concede os pontos correspondentes.
A distinção também conta quando o domínio não tem A nem AAAA. A ausência de MX continua sendo uma ausência, não uma declaração Null MX. Publicar 0 . documenta a intenção, resiste à adição futura de um endereço web e dá aos remetentes uma resposta sem ambiguidade.
Fechar o envio com SPF e DMARC
O SPF nu v=spf1 -all declara que nenhum endereço IP está autorizado a enviar em nome do domínio. O DMARC completa essa declaração com uma política de rejeição para o domínio e seus subdomínios.
Publique no ápice:
example.com. IN TXT "v=spf1 -all"
Mantenha esse valor como está. Não adicione a, mx, include nem uma faixa de IP. Cada um desses mecanismos reintroduziria um remetente autorizado. O qualificador -all é uma falha rígida; ~all expressaria apenas uma falha branda, inútil quando não há nenhuma fonte legítima a preservar. O gerador SPF ajuda a revisar a sintaxe, mas aqui o valor final se resume a dois elementos.
Publique em seguida em _dmarc:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc@captaindns.com"
p=reject cobre o domínio organizacional. sp=reject aplica a rejeição aos subdomínios existentes e np=reject aos subdomínios inexistentes, quando um destinatário suporta essa tag. Os alinhamentos estritos adkim=s e aspf=s são adequados aqui: nenhum fluxo legítimo depende de um alinhamento relaxado.
O relatório rua muda a pontuação
A tag rua não é decorativa. A ausência dela muda a pontuação DMARC na auditoria. Ela serve para receber os relatórios agregados que revelam as fontes que se apresentam com o domínio, mesmo quando a política as rejeita.
O endereço nunca deve pertencer ao domínio sem email. rua=mailto:dmarc@example.com criaria um endereço órfão: Null MX anuncia que example.com não recebe nada. Use um endereço em outro domínio que receba de verdade, como dmarc@captaindns.com, ou um serviço de ingestão DMARC. O mesmo princípio vale para ruf, se você usá-lo, e para o endereço iodef de um CAA.
Os relatórios externos podem exigir uma autorização DNS adicional no domínio destinatário, conforme o DMARC. Verifique essa delegação com o provedor escolhido. A ingestão CaptainDNS a 5 euros é um segundo nível possível para centralizar esses relatórios; não é um pré-requisito para rodar a auditoria gratuita.
DKIM: não publique nenhum seletor
Não existe um registro DKIM ideal para colar em um domínio que não envia. A configuração certa é a ausência de qualquer seletor sob _domainkey.
O DKIM autentica uma assinatura carregada por uma mensagem. Aqui nenhuma mensagem legítima sai. Publicar uma chave RSA ou Ed25519 "por precaução" criaria uma superfície de configuração sem uso. Publicar um valor vazio seria pior, porque o significado dele já está definido.
A RFC 6376 descreve uma tag p= vazia como a revogação de uma chave publicada anteriormente. O signatário que conhece esse seletor quer que as assinaturas que o usam falhem. A mesma RFC esclarece que um verificador não dá sentido diferente a uma chave revogada e a um registro de chave excluído: nos dois casos, nenhuma validação DKIM tem sucesso. A RFC 5863 apresenta esse valor vazio como uma lápide útil na retirada de um seletor, para evitar sua reutilização acidental.
Isso não cria uma política geral de "este domínio não envia". Um wildcard *._domainkey com um p= vazio aplica a semântica de revogação a nomes de seletor que nunca existiram. A M3AAWG retirou essa receita antiga do seu BCP de 2022: o DKIM não é necessário para um domínio sem email e nenhum deveria ser publicado.
O comportamento da CaptainDNS segue essa leitura. A auditoria pública mantém DKIM e BIMI em zero, conserva as respectivas recomendações e depois exibe esta nota quando Null MX e o SPF nu estão presentes: "Se este domínio não envia email, DKIM e BIMI não são necessários. A pontuação não muda." Esse texto explica o caso; ele não maquia a pontuação.
No monitoramento, a opção "Este domínio não envia email" muda a camada de avaliação. DKIM e BIMI saem então da pontuação, e um alerta é emitido se um MX real ou uma chave DKIM aparecer. As duas visões são portanto coerentes: a pública mostra as recomendações gerais e a pontuação limitada; o monitoramento aplica a intenção declarada do domínio.
Nenhum endereço órfão na zona
Todo URI mailto: publicado por um domínio sem email precisa apontar para outro domínio capaz de receber. Essa regra cobre o DMARC, os avisos CAA e qualquer endereço operacional adicionado mais tarde.
Faça uma busca textual na zona exportada. Os lugares clássicos são rua, ruf e iodef. Um endereço de contato em um registro TXT próprio merece o mesmo controle. Se a parte à direita de @ for o domínio que Null MX acabou de fechar, o relatório será perdido.
Em um site sem email, não confunda o endereço visível em uma página web com o serviço de email do domínio. Você pode exibir um endereço hospedado por outro domínio, ou um formulário ligado a um sistema externo. O DNS do site continua sem email. Em um domínio defensivo sem site, nenhum endereço local tem razão de existir.
Essa separação evita uma contradição discreta: pedir às autoridades certificadoras ou aos receptores DMARC que enviem um relatório para um destino que o DNS declara inexistente. A política de segurança pareceria completa em um arquivo de zona, mas ninguém leria os alertas dela.
Dois casos, uma base de email e duas políticas CAA
O site HTTPS e o domínio sem site compartilham Null MX, SPF e DMARC. A diferença está em A/AAAA e na autorização para emitir um certificado.
| Elemento | Site sem email | Domínio sem site |
|---|---|---|
| A / AAAA | Presentes conforme a hospedagem | Ausentes |
| MX | 0 . | 0 . |
| SPF | v=spf1 -all | v=spf1 -all |
| DMARC | p=reject; sp=reject; np=reject | p=reject; sp=reject; np=reject |
| DKIM | Nenhum seletor | Nenhum seletor |
| CAA | CA realmente usada, mais iodef externo | 0 issue ";" |
| Certificado | Permitido e renovável | Proibido |
CAA para o site HTTPS
Um site precisa autorizar a CA que realmente emite seu certificado. Adicione também um destino iodef situado em outro domínio receptor. Uma política completa pode obter 100 no controle CAA do pilar DNS, sem que a pontuação global alcance a faixa superior por causa do DKIM.
example.com. IN CAA 0 issue "ca.example.com"
example.com. IN CAA 0 iodef "mailto:security@captaindns.com"
Adapte o identificador à sua CA. Sobretudo, não publique issue ";" neste site: você proibiria a emissão e a próxima renovação poderia falhar. O guia CAA detalha a herança, issuewild e os parâmetros ACME.
CAA para o domínio sem certificado
Um domínio sem site, sem A/AAAA e sem certificado pode proibir qualquer CA:
example.com. IN CAA 0 issue ";"
Na auditoria CaptainDNS, essa escolha vale 90 para CAA, não 100. A diferença reflete a ausência de canal iodef, enquanto um domínio fechado não deve publicar um mailto: local. Uma CA indicada pelo nome não é uma variante intercambiável: ela reabriria a emissão de certificados.
O DNSSEC também protege o site contra uma pane silenciosa
O DNSSEC assina as respostas DNS e permite ao resolvedor detectar a falsificação delas. Uma cadeia quebrada torna o domínio inválido para os resolvedores validadores, mesmo que os registros estejam presentes na hospedagem.
Para o site sem email, é o único elemento dessa receita que pode deixar o site silenciosamente inacessível depois de uma rotação malfeita. Um DS obsoleto no registrador, uma KSK retirada cedo demais ou assinaturas expiradas costumam produzir SERVFAIL. O navegador não vai dizer "DNSSEC quebrado"; ele mostrará apenas um erro de resolução.
Implante o DNSSEC verificando a cadeia entre a zona filha e a zona pai. Ao trocar de provedor DNS, coordene as chaves e o DS antes de remover a zona antiga. O guia de ativação do DNSSEC cobre essa sequência.
No domínio sem site, uma falha de DNSSEC não quebra uma página web inexistente, mas impede os destinatários de ler Null MX, SPF e DMARC. A proteção contra a falsificação de identidade continua, portanto, dependendo de uma cadeia válida. Monitore-a como qualquer outro registro de segurança.
O que a auditoria pública vai mostrar
A auditoria pública avalia três pilares: envio 50, recebimento 35 e DNS 15. Uma zona sem email bem ajustada obtém Bom, geralmente em torno de 80-85 conforme a presença de rua e DNSSEC.
O recebimento é completo com um único Null MX. MTA-STS, DANE e TLS-RPT não são pedidos, já que o domínio não recebe mensagens. Por outro lado, MXCount == 0 é um erro: o fallback para A continua possível e o fechamento não está declarado.
Do lado do envio, o SPF estrito e o DMARC reject marcam claramente a ausência de fonte legítima. Ainda assim, DKIM e BIMI permanecem em zero na ferramenta pública, com suas recomendações. A nota exibida explica que esses mecanismos não são necessários se o domínio não envia e que a pontuação não muda. Resultado: a faixa superior, a partir de 90, continua inacessível sem DKIM. Isso é proposital e visível.
O pilar DNS depende principalmente de CAA e DNSSEC. O site pode obter o controle CAA completo com uma CA autorizada e um iodef externo. O domínio sem certificado obtém 90 nesse controle com issue ";". Esses números são subpontuações de controles, não uma promessa de pontuação global.
O monitoramento muda apenas a intenção de email
A opção "Este domínio não envia email" é uma função de monitoramento. Ela retira DKIM e BIMI da pontuação monitorada e alerta se a zona voltar a aceitar ou assinar mensagens.
Ela não fabrica uma captura de tela lisonjeira na auditoria pública. Ela não muda a necessidade de Null MX, nem de SPF, nem de DMARC, nem de CAA, nem de DNSSEC. O interesse dela é operacional: se um administrador adiciona um MX real ou se um antigo seletor DKIM reaparece, o monitoramento sinaliza que o contrato "sem email" acaba de ser rompido.
A primeira ferramenta CaptainDNS é gratuita. Comece pela auditoria da zona, corrija os registros e ative depois um monitoramento se o domínio merecer um alerta contínuo. O monitor custa 5 euros. As outras ferramentas seguem a tarifação da conta, 3 euros e depois 5 euros, sem oferta separada dedicada a esse caso.
Divergências entre as recomendações publicadas
Os guias disponíveis online não dão todos a mesma receita. Ficamos com os textos mais recentes e a semântica das RFCs, e apontamos as diferenças em vez de escondê-las.
A GOV.UK ainda recomenda um wildcard _domainkey contendo um p= vazio na página dela atualizada em 1o de março de 2021. A EasyDMARC e a Mimecast também retomam o BCP M3AAWG de 2015. Não copiamos esse valor: a M3AAWG o retirou na edição de junho de 2022, enquanto as RFCs o definem como a revogação de uma chave antiga. A ausência de seletor é mais exata e não dispara a recomendação crítica dkim.empty_p_tag da nossa própria auditoria.
A condição "Null MX somente se existir um A ou AAAA" pertence à edição de dezembro de 2015: "M3AAWG recommends the use of a null MX record only if the domain has an A and/or AAAA record", por compatibilidade com os receptores que ainda não tinham implementado a RFC. A edição de junho de 2022 retirou essa restrição, e o exemplo "Single Parked Domain" dela, sem A nem AAAA, publica de fato example.com. MX 0 .. Seguimos o texto de 2022 e publicamos nos dois casos: nenhum MX significa sempre "nenhum MX", não "recusa explícita", e um futuro endereço A reativaria o fallback SMTP.
O internet.nl também recomenda Null MX para um domínio sem servidor de email e considera vários testes de email não aplicáveis a esse perfil. A CaptainDNS mantém uma leitura pública uniforme dos três pilares: a zona sai Bom em torno de 80-85, não na faixa superior. As duas interfaces descrevem o mesmo objetivo com modelos de pontuação diferentes.
O que este artigo não é
Este guia descreve uma zona que não envia nem recebe mensagens. Ele não substitui o gerador DMARC, que compõe uma política a partir das suas escolhas, nem a auditoria, que lê as respostas DNS realmente publicadas.
Também não é um guia de remetente. Ele não cobre a rotação de chaves, nem os seletores dos provedores, nem a entregabilidade de uma campanha. Esse papel fica com os artigos dedicados ao DKIM. Aqui, adicionar uma plataforma de envio muda a necessidade: o domínio deixa de estar sem email e a receita precisa ser revista.
O CAA só é tratado no ponto de decisão entre certificado autorizado e certificado proibido. A herança dele e suas variantes pertencem ao guia CAA. O DNSSEC se limita ao risco de cadeia quebrada; o tutorial completo permanece separado. Por fim, a retenção e a expiração dos nomes cabem ao ciclo de vida de um domínio, não à configuração de email.
Verificação final da zona
Uma zona coerente se controla de fora, depois da propagação. Verifique que apenas um MX 0 . está visível, que o SPF contém somente v=spf1 -all e que _dmarc publica a rejeição esperada.
Procure depois qualquer nome sob _domainkey: nada deve restar, exceto uma chave antiga em processo de retirada segundo um plano datado. Confira que cada mailto: aponta para outro domínio receptor. Termine com CAA, DNSSEC e os eventuais A/AAAA.
Rode a auditoria de novo depois do TTL. Espere Bom e leia as recomendações ainda exibidas para DKIM e BIMI à luz dessa nota. Se você ativar o monitoramento "Este domínio não envia email", teste também o alerta durante uma alteração planejada e depois restaure a zona de referência.
FAQ
Qual é a diferença entre Null MX e a ausência de MX?
Null MX publica um MX explícito com prioridade 0 e alvo .. Sem MX, um remetente SMTP pode recorrer a A ou AAAA; as duas configurações não são equivalentes.
É preciso publicar um DKIM?
Não. Não publique nenhum seletor sob _domainkey. Um p= vazio serve apenas para retirar uma chave antiga; não é um modelo para declarar que um domínio não envia.
Por que manter um rua se o domínio não envia?
Os relatórios agregados revelam as fontes que tentam usar o domínio, e a ausência da tag rua muda a pontuação DMARC. Envie-os para um endereço hospedado em outro domínio que receba de verdade.
Null MX basta para impedir a falsificação de identidade?
Não. Null MX fecha o recebimento. O SPF v=spf1 -all e o DMARC p=reject tratam o envio falsificado; cada mecanismo responde a uma direção diferente.
Qual CAA publicar para um site sem email?
Autorize a CA que emite o certificado do site e adicione um iodef externo se possível. Nunca publique issue ";" nesse site, porque a renovação do certificado ficaria bloqueada.
Qual CAA publicar para um domínio sem site?
Publique 0 issue ";" se nenhum certificado deve ser emitido. Na auditoria CaptainDNS, essa escolha vale 90 para o controle CAA, e não 100.
Por que a pontuação pública continua em Bom?
A auditoria pública conserva DKIM e BIMI em zero com suas recomendações, mesmo que uma nota explique que aqui eles são inúteis. O monitoramento marcado os retira da pontuação dele, mas não altera a auditoria pública.
