Verificador DNS Legado de MD (Mail Destination)
O registro MD (Mail Destination) é um pilar obsoleto e fundamental dos primeiros dias de roteamento de email na internet. Para entender o registro MD, é preciso analisar como os engenheiros de rede inicialmente tentaram estruturar o fluxo de email antes da padronização da infraestrutura SMTP moderna. No início dos anos 1980, o protocolo DNS tentou dividir rigorosamente as responsabilidades de roteamento de emails em dois tipos de registros separados e distintos: o registro MD e o seu companheiro, o registro MF (Mail Forwarder).
O Destino Final Rígido
Nesta arquitetura legada de roteamento dividido (split-routing), o registro MD era encarregado de definir o host final e absoluto, responsável por receber os emails para um determinado domínio. Se um usuário enviasse um email endereçado a admin@example.com, o servidor remetente consultaria a zona DNS de example.com buscando especificamente um registro MD. O Payload retornaria o hostname canônico exato da máquina onde a caixa de entrada física daquele usuário residia. O servidor remetente executaria então um lookup do registro A nesse hostname para descobrir o endereço IP e tentar entregar o Payload. O sistema operava inteiramente sob um mapeamento do tipo um-para-um.
O Ponto Único de Falha (Single Point of Failure)
A arquitetura do registro MD possuía uma falha operacional fatal: ela desconhecia totalmente a redundância, roteamento por prioridade ou mecanismos de failover. Representava um gigantesco Ponto Único de Falha (Single Point of Failure). Se o mainframe específico listado no registro MD do domínio ficasse offline para manutenção, sofresse de uma falha de hardware ou perdesse conectividade de rede, qualquer email de entrada sofreria um hard-bounce (rejeição permanente) devolvido instantaneamente ao remetente. Não havia mecanismo nativo dentro do protocolo MD que indicasse ao servidor de envio para reter a mensagem ou tentar um servidor de backup. Conforme o tráfego da internet aumentou exponencialmente, a incapacidade de lidar graciosamente com quedas de rede se tornou inaceitável para comunicações acadêmicas e corporativas.
Descontinuação e a Revolução do MX
Para solucionar esses gargalos críticos, a Internet Engineering Task Force (IETF) ratificou a RFC 973, que tornou oficial e permanentemente obsoletos (deprecated) ambos os registros, MD e MF. As funções desses sistemas legados foram consolidadas no moderno registro MX (Mail Exchanger). O registro MX revolucionou a arquitetura de emails por meio da introdução do conceito de valores inteiros de prioridade. Os administradores agora podiam configurar destinos primários e servidores de encaminhamento (forwarders) de backup secundários de maneira unificada e altamente resiliente dentro de um array de roteamento único. O protocolo MX instruiu os servidores de envio a primeiro tentar realizar a conexão baseada no menor número correspondente à prioridade para depois proceder imediatamente ao failover invisível em prol de utilizar os hosts paralelos indicados no mapeamento para uso via backup caso houvesse a inoperância do primário originário. Exigir do servidor hoje em dia respostas ou processar buscas sobre um registro de tipo MD serve puramente a exercícios focados na averiguação histórica acadêmica e no desenvolvimento histórico de pesquisas perante o âmbito restrito dos engenheiros, não sendo jamais adotada por um software ou serviço provedor nos termos práticos mantidos perante a rede mundial atuante, dado que quaisquer instâncias processadas perante sistemas como o MTA não executam ou operam dados atrelados a esses velhos protocolos referendando payloads da tipagem MD.