Configuração de DNS e SPF para o Microsoft Exchange

Question

Começamos a receber spam com endereços falsos de nosso próprio domínio. Então, eu estou tentando obter meus registros PTR e SPF, etc, para evitar isso. Estamos executando o Exchange 2010 no site com um servidor configurado para executar todas as funções. Nosso certificado de SAN para o Exchange inclui: webmail.domain.org e autodiscover.domain.org

Atualmente, tenho os seguintes registros em meu DNS externo (o registro SPF foi gerado usando o Assistente de Estrutura de ID de Remetente da Microsoft):

domain.org A 123.123.123.123

mail.domain.org A 123.123.123.234
mail.domain.org PTR 123.123.123.234
domain.org MX 0 mail.domain.org

webmail.domain.org A 123.123.123.234
webmail.domain.org PTR 123.123.123.234

autodiscover.domain.org A 123.123.123.234
_autodiscover._tcp.domain.org SRV 0 0 443 webmail.domain.org

domain.org TXT "v=spf1 mx ip4:123.123.123.234 a:webmail.domain.org ptr:webmail.domain.org ptr:99-99-99-99.static.virginm.net mx:mail.domain.org a:99-99-99-99.static.virginm.net ~all"

Se eu fizer uma pesquisa inversa usando o servidor DNS do Google, recebo uma resposta do nosso ISP semelhante a:

99-99-99-99.static.virginm.net

O que não corresponde ao domínio apresentado pelo meu servidor de e-mail.

Meu DNS interno possui os seguintes registros:

domain.org A 192.168.0.123

mail.domain.org A 192.168.0.234

webmail.domain.org A 192.168.0.234
mailserver.domain.internal PTR 192.168.0.234

autodiscover.domain.org CNAME webmail.domain.org
_autodiscover._tcp.domain.org SRV 0 0 443 webmail.domain.org

Minhas perguntas são:

1) Preciso adicionar um registro MX ao meu DNS interno?

2) Preciso perguntar ao meu ISP se eles podem alterar seu PTR para mail.domain.org?

3) Nossos usuários acessam o OWA via webmail.domain.org. Devo alterar meu registro MX para webmail.domain.org e me livrar de mail.domain.org completamente? Se não, o mail.domain.org precisa estar no meu certificado de SAN?

4) Minha resposta do FQDN para HELO / EHLO é: mailserver.domain.internal. Preciso alterar isso para corresponder ao domínio no meu certificado ou no meu registro MX? ou deixar como está?

5) Preciso fazer um registro SPF diferente com endereços IP internos e adicioná-lo ao meu DNS interno?

6) O registro SPF que gerou está correto?

7) Há mais alguma coisa que eu precise mudar, sobre a qual não perguntei? lol

Eu tentei fornecer o máximo de informações possível, mas se precisar de mais alguma coisa, pergunte.

    

Answer 1

Eu meio que vejo onde você está indo com isso. Deixe-me adicionar meus dois centavos:

1. Do I need to add an MX record to my internal DNS?

Não. Isso não afeta a entrega de e-mails externos para internos ou internos para e-mails externos.

2. Do I need ask my ISP if they're able to change their PTR to mail.domain.org?

Isso seria recomendado para que, quando seu servidor enviar e-mails, o registro DNS reverso corresponda ao FQDN no HELO / EHLO que seu servidor fornece (que é o FQDN configurado no seu Conector de Envio).

3. Our users access OWA via webmail.domain.org. Should I change my MX record to webmail.domain.org and get rid of mail.domain.org completely? If not, does mail.domain.org need to be on my SAN certificate?

Isso não é relevante para o envio ou recebimento de email do seu servidor.
Qual URL / FQDN seus usuários se conectam para acessar suas caixas de correio não importa aqui.

4. My FQDN response to HELO/EHLO is: mailserver.domain.internal. Do I need to change this to match the domain on my certificate or my MX record?

Você deve alterar esse FQDN no Conector de Envio, embora não tenha relevância para o seu registro MX. (O registro MX designa qual servidor recebe o email para o seu domínio, não o servidor que envia email para o seu domínio.)

5. Do I need to make a different SPF record with internal IP addresses and add it to my internal DNS?

Não. Isso não afeta a entrega de e-mails externos para internos ou internos para e-mails externos.

6. Is the SPF record I have generated correct See Daniel's answer: You can probably get away with a much simpler SPF record.

Aqui está o problema que eu vejo com a sua abordagem: A menos que você vá executar uma rejeição strong em uma falha de verificação de registro DNS ou SPF reverso, então você não irá impedir completamente esses e-mails falsos. Se você executar uma rejeição difícil, perderá muitos emails legítimos porque os registros DNS e SPF reversos não são universalmente implementados (e / ou são implementados incorretamente). Você pode reduzir a quantidade de e-mails de spam e spoofing ajustando as configurações de ID de Remetente e Reputação do Remetente nas configurações de Anti-spam do Exchange, mas não as impedirá completamente, a menos que você rejeite os e-mails (mas, novamente Isso provavelmente fará com que e-mails legítimos sejam rejeitados também.

Eu posso estar completamente fora da base da minha lógica, então talvez outra pessoa possa se interessar pela sua expertise.

Além disso, veja aqui, cortesia de TheCleaner:

link

    

Answer 2

Normalmente, esta linha é suficiente:

domain.com. IN TXT "v=spf1 mx a ~all"
                           ^1 ^2

1. Permite que todos os servidores listados como MX para domain.com enviem e-mails para esse domínio.
2. Permite que o servidor com o IP de domain.com envie e-mails para este domínio.

Então ...

1. Não
2. Não, mas seria bom.
3. Não, para todos.
4. Altere-o.
5. Não, nomes de host internos e endereços IP não entram no registro SPF
6. Encurte como mostrado acima
7. Talvez;)