[ DNS e domínios ]

Registros DNS e PTR reversos para infraestrutura de envio

Encontre a operadora que controla o DNS reverso do IP remetente e verifique o nome do host retornado sem confundi-lo com autenticação de domínio.

Pela equipe de pesquisa EmailAuth

[Pontos-chave]

  • Use o IP de origem pública real e sua autoridade de zona reversa.
  • Guarde todos os resultados PTR e confirme o mapeamento direto relevante.
  • A nomenclatura reversa não é autorização do remetente ou entrega garantida.
Nesta página

DNS reverso pede um nome associado a um endereço IP. Para um remetente de email, o endereço relevante é a fonte pública usada na conexão SMTP . Um registo PTR nesse endereço é uma prova útil de infra-estrutura, mas não é SPF autorização, um Assinatura DKIM ou prova de que uma mensagem é legítima.

Identifique o endereço real e a autoridade

Referências: RFC 1035 §3.5, RFC 3596 §2.5.

Comece com o IP visto pelo sistema receptor ou uma observação SMTP externa controlada. O endereço privado de um aplicativo, o endereço do balanceador de carga e o endereço de saída do provedor podem ser diferentes. Liste todas as famílias e pools de endereços de saída que o serviço pode usar.

Consultas reversas IPv4 usam octetos invertidos em in-addr.arpa. IPv6 usa nibbles hexadecimais invertidos em ip6.arpa. A autoridade para essas zonas reversas segue a alocação de IP e qualquer delegação. Geralmente é o provedor de hospedagem ou rede, não o registrador ou host DNS do domínio visível do remetente. Publicar um nome semelhante ao PTR em uma zona direta não relacionada não alterará a resposta reversa real.

Coordenar ambas as direções

Referências: RFC 1912 §2.1, RFC 2181 §10.2.

Pergunte ao operador da zona reversa o processo de alteração suportado e o IP público exato. Escolha um nome de host de infraestrutura pretendido e certifique-se de que seus dados de endereço de encaminhamento incluam esse IP. RFC 1912 recomenda a correspondência de dados reversos e diretos; trata-se de uma orientação operacional, não de um contrato universal de aceitação do receptor.

RFC 2181 esclarece que DNS não restringe um endereço a exatamente um PTR . Vários nomes retornados devem ser mantidos como evidência, em vez de descartados silenciosamente. Para uma administração previsível, um nome de host documentado estável é muitas vezes mais simples, mas os requisitos específicos do receptor precisam de sua própria documentação atual. Não afirme que um padrão PTR garante a entrega a todos os provedores.

Reproduzir uma pesquisa reversa

Dispositivo IPv4 sintético: endereço de origem 192.0.2.25; proprietário reverso 25.2.0.192.in -addr.arpa.; Alvo PTR smtp.example.com.; encaminhar A naquele alvo 192.0.2.25. A resposta reversa esperada é o nome do host e a confirmação de encaminhamento esperada inclui o IP original.

Em uma zona reversa isolada, consulte cavar @AUTH -x 192.0.2.25 +norecurse e depois consulte smtp.example.com. A contra a autoridade avançada do laboratório. Preservar a autoridade utilizada para cada direção porque não precisam ser da mesma organização. Remova o PTR para um segundo dispositivo: a evidência esperada é a ausência ou um erro classificado na resposta real, não um nome de host recém-inventado.

Para IPv6 , use a conversão de endereço para reverso da ferramenta de pesquisa em vez de abreviar manualmente o nome do nibble. Consulta cavar @AUTH -x 2001:db8::25 +norecurse, substituindo o resolvedor de laboratório configurado por AUTH. Uma verificação de produção deve usar um endereço de origem real observado; esses intervalos de documentação não descrevem um remetente ativo.

Distinguir infraestrutura de autenticação

Referências: RFC 7208 §5.5, RFC 9989 §5.3.5.

Um destino PTR não precisa ser o domínio De visível apenas porque o correio usa esse domínio. Um provedor pode operar infraestrutura de envio compartilhada com seu próprio nome de host. O que importa para uma determinada apólice de recebimento deve ser verificado separadamente do SPF e DKIM alinhamento.

Não adicione o SPF desanimado PTR mecanismo apenas para tornar DNS reverso relevante para SPF . Mantenha PTR como uma preocupação de infraestrutura e configure SPF com a autorização real do remetente suportada. Após as alterações, verifique as respostas direta e reversa, a introdução SMTP e a resposta relevante do receptor. Mantenha qualquer conclusão de entrega limitada à rota e ao tempo testados.

Mantenha o escopo da evidência explícito

Uma conversão de biblioteca de endereços local confirma 192.0.2.25 mapas para 25.2.0.192.in -addr.arpa e gera o nome completo do nibble IPv6 . Esse cálculo não consulta nenhuma zona reversa nem estabelece que existe um PTR . Nenhum teste de entrega ou política do receptor foi realizado.

[ Remover ]

Use o IP de origem pública real e sua autoridade de zona reversa. Guarde todos os resultados PTR e confirme o mapeamento direto relevante. A nomenclatura reversa não é autorização do remetente ou entrega garantida.

[Por função]

O que isso significa para você

Escolha sua função para ver as próximas etapas práticas.

Administrador de TI/Correio

Comece pelo IP de origem observado

Endereços internos e associação presumida ao pool são insuficientes para um diagnóstico de DNS reverso.

Próximas etapas

  1. Capture endereços de fontes públicas reais.
  2. Coordene PTR com dados de endereço de encaminhamento.
  3. Registre cada autoridade da zona reversa.

CISO/SecOps

Mantenha a garantia PTR limitada

Um nome de host de infraestrutura não autoriza o uso do domínio do remetente visível.

Próximas etapas

  1. Separe a nomenclatura de infraestrutura da autorização.
  2. Revise a propriedade do pool compartilhado e o controle de alterações.
  3. Evite tratar PTR como prova de identidade.

Fundador / Não técnico

Encontre o proprietário da rede

A organização que controla o endereço pode ser diferente da organização que gerencia o domínio.

Próximas etapas

  1. Atribua o proprietário do relacionamento do provedor.
  2. Mantenha o inventário de IP de saída atualizado.
  3. Exija evidências antes das reclamações de entrega.

[ Perguntas frequentes ]

Perguntas frequentes

Quem normalmente altera o PTR de um IP público?

O operador da zona reversa, geralmente o IP ou o provedor de hospedagem, a menos que a autoridade seja delegada.

Meu registrador de domínio sempre pode configurá-lo?

Não. O registro de domínio direto e o controle de zona reversa são diferentes.

Qual IP devo inspecionar?

A fonte pública observada na conexão SMTP .

PTR deve ser igual ao domínio From visível?

Não como regra geral DNS . Verifique a infraestrutura real e os requisitos do receptor.

Um IP pode ter vários registros PTR ?

Sim. DNS permite isso; preservar o conjunto completo e verificar as regras operacionais aplicáveis.

RFC 2181 §10.2

PTR autoriza o envio?

Não. Não substitui SPF , DKIM ou DMARC .

Devo adicionar SPF ptr?

Não. RFC 7208 desencoraja esse mecanismo; a manutenção reversa DNS é uma tarefa separada.

RFC 7208 §5.5

Uma resposta reversa bem-sucedida garante a entrega?

Não. A política do receptor e outras verificações de mensagens e infraestrutura ainda se aplicam.

[ Fontes ]

Fontes

  1. RFC 9989

    Seções §5.3.5

  2. RFC 7208

    Seções §5.5

  3. RFC 1035

    Seções §3.5

  4. RFC 2181

    Seções §10.2

  5. RFC 1912

    Seções §2.1

  6. RFC 3596

    Seções §2.5

  7. Referência de escavação ISC BIND

    Seções Sintaxe, -x pesquisa reversa, opção de consulta norecurse

[ Glossário ]

Glossário

Registro PTR
Um ponteiro para um nome de domínio canônico; um proprietário reverso pode ter mais de um PTR .

RFC 2181 §10.2

Nome reverso IPv6
Os nibbles hexadecimais invertidos de um endereço IPv6 em ip6.arpa.

RFC 3596 §2.5

Proveniência da empresa

Por que as principais instituições financeiras e governos retiraram seus painéis de segurança de e-mail.

As plataformas tradicionais de autenticação de e-mail vendem um painel e pedem que seus engenheiros façam o trabalho. Em ambientes de alto risco, a supervisão manual significa aplicação atrasada, desvios de configuração e domínios ocultos não monitorados.

EmailAuth é a plataforma de origem de e-mail agente. Nossos agentes impõem p=reject, mantenha remetentes terceiros alinhados e mova seus domínios para full RFC 9989 conformidade, o novo padrão DMARC , com auditabilidade humana no circuito.

Governos Grandes empresas Instituições financeiras de nível 1

SaaS · Locação dedicada · Air gap no local · Criptografia BYOK

Base de conhecimento