DNS and SPF configuration for Microsoft Exchange

domain-name-systemexchangeexchange-2010spamspf

We've started receiving spam with spoofed addresses from our own domain. So I'm trying to get my PTR and SPF records etc correct to prevent it. We're running Exchange 2010 on site with one server configured to run all roles. Our SAN certificate for Exchange includes: webmail.domain.org and autodiscover.domain.org

I currently have the following records in my external DNS (The SPF record was generated using Microsoft's Sender ID Framework Wizard):

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"

If I do a reverse lookup using Google's DNS server I get a response from our ISP similar to:

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

Which doesn't match the domain being presented by my mail server.

My internal DNS has the following records:

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

My questions are:

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

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

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?

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? or leave it as it is?

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

6) Is the SPF record I have generated correct?

7) Is there anything else that I need to change which I haven't asked about? lol

I've tried to give as much information as possible, but if you need anything else please ask.

Best Answer

I kind of see where you're going with this. Let me add my two cents:

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

No. That doesn't have any bearing on external to internal or internal to external email delivery.

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

That would be recommended so that when your server sends email, the reverse-DNS record matches the FQDN in the HELO/EHLO that your server provides (which is the FQDN configured on your Send Connector).

  1. 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?

That isn't relevant to your server sending or receiving email.
What URL/FQDN your users connect to in order to access their mailboxes doesn't matter here.

  1. 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?

You should change this FQDN on your Send Connector, although it doesn't have any relevance to your MX record. (The MX record designates what server receives email for your domain, not what server sends email for your domain.)

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

No. That doesn't have any bearing on external to internal or internal to external email delivery.

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

Here's the problem I see with your approach: Unless you're going to perform a hard rejection on a reverse DNS or SPF record check failure then you're not going to completely prevent these spoofed emails. If you perform a hard rejection then you're going to lose a lot of legitimate email because reverse DNS and SPF records aren't universally implemented (and/or are often implemented incorrectly).
You may be able to reduce the amount of spam and spoofed emails by adjusting the Sender ID and Sender Reputation settings in the Anti-spam settings in Exchange but you're not going to completely prevent them unless you hard reject the emails (but again, that's probably going to cause legitimate emails to be rejected as well).

I may be completely off base with my logic, so maybe someone else can weigh in with their expertise.

Also, see here, courtesy of TheCleaner:

http://exchangepedia.com/2008/09/how-to-prevent-annoying-spam-from-your-own-domain.html

Related Topic