RDNS

De Porcupine E-Mail Protection
Revisão de 19h17min de 26 de maio de 2025 por Porcupine.email (Discussão | contribs) (Criou página com 'As recomendações para configuração de **reverso de IP** (ou **rDNS**, Reverse DNS) para servidores de e-mail, conforme descrito em padrões como os RFCs (especialmente RFC...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)

As recomendações para configuração de **reverso de IP** (ou **rDNS**, Reverse DNS) para servidores de e-mail, conforme descrito em padrões como os RFCs (especialmente RFC 1912, RFC 5321 e RFC 2505, entre outros), são cruciais para garantir a confiabilidade e a entregabilidade de e-mails. Abaixo estão as principais diretrizes baseadas nas melhores práticas e nas RFCs relevantes:

1. **Configuração Obrigatória do rDNS**:

  - O endereço IP do servidor de e-mail deve ter um registro de DNS reverso (PTR) configurado.
  - O registro PTR deve mapear o endereço IP para um nome de domínio (FQDN, Fully Qualified Domain Name) válido. Por exemplo, se o IP do servidor é `192.0.2.1`, o rDNS deve resolver para algo como `mail.exemplo.com`.
  - **RFC 1912**: Recomenda que todo endereço IP em uso tenha um registro PTR correspondente para evitar problemas de resolução.

2. **Consistência com o Registro A/AAAA**:

  - O nome de domínio retornado pelo rDNS (ex.: `mail.exemplo.com`) deve ter um registro A (ou AAAA, para IPv6) que aponte de volta para o mesmo IP do servidor. Isso é chamado de **consistência forward-reverse**.
  - Exemplo: se o rDNS de `192.0.2.1` é `mail.exemplo.com`, então `mail.exemplo.com` deve resolver para `192.0.2.1` no DNS forward.
  - Essa consistência é essencial para verificações de autenticidade por servidores de e-mail recipientes.

3. **Uso de Domínio Relevante**:

  - O domínio no registro PTR deve ser um domínio que você controla e que seja relevante para o servidor de e-mail. Evite nomes genéricos ou não relacionados (ex.: `ip-192-0-2-1.provedor.com`).
  - Idealmente, use um subdomínio do domínio principal associado ao envio de e-mails (ex.: `mail.seudominio.com`).

4. **Evitar Configurações Genéricas ou Incorretas**:

  - Não deixe o rDNS com valores padrão fornecidos pelo provedor de hospedagem (ex.: `host123.provedor.com`), pois isso pode sinalizar que o servidor não está adequadamente configurado, aumentando a chance de e-mails serem marcados como spam.
  - **RFC 5321 (SMTP)**: Embora o protocolo SMTP não exija explicitamente um rDNS, muitos sistemas de filtragem de spam verificam a existência e a validade do registro PTR.

5. **Boas Práticas para Entregabilidade**:

  - Configure o rDNS para refletir o nome do servidor usado no **HELO/EHLO** do protocolo SMTP. Por exemplo, se o servidor se apresenta como `mail.exemplo.com` no HELO, o rDNS deve corresponder a esse nome.
  - Certifique-se de que o domínio no rDNS seja consistente com os registros SPF, DKIM e DMARC, que também são verificados para autenticidade.

6. **Evitar IPs Dinâmicos**:

  - IPs dinâmicos ou residenciais frequentemente não têm registros PTR adequados e são bloqueados por servidores de e-mail. Use IPs estáticos dedicados para servidores de e-mail.
  - **RFC 2505**: Recomenda evitar o uso de IPs dinâmicos para envio de e-mails, pois eles são frequentemente associados a spam.

7. **Teste e Validação**:

  - Após configurar o rDNS, teste a resolução usando ferramentas como `dig -x <IP>` ou `nslookup <IP>` para verificar se o registro PTR está correto.
  - Verifique a consistência forward-reverse com ferramentas online como MXToolbox ou serviços de validação de DNS.
      1. Exemplo Prático

- IP do servidor: `192.0.2.1` - Registro PTR: `mail.exemplo.com` - Registro A de `mail.exemplo.com`: `192.0.2.1` - No SMTP, o servidor deve se apresentar como `mail.exemplo.com` no comando HELO/EHLO.

      1. Observações

- A falta de um rDNS válido ou a configuração incorreta pode levar à rejeição de e-mails por servidores recipientes, especialmente por grandes provedores como Gmail, Outlook e Yahoo. - A configuração do rDNS geralmente é feita pelo provedor de hospedagem ou pelo administrador da rede que controla o bloco de IPs. Entre em contato com eles para garantir que o PTR esteja corretamente configurado.