2

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.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
Daniel
  • 243
  • 1
  • 7
  • 16
  • 3
    I don't see what any of this has to do with spam `TO` your server. – joeqwerty Mar 11 '15 at 15:51
  • The spam in question is "from" my domain (I.e example@mydomain.org) but is actually coming from another mail server. So my theory is get the SPF record etc correct and the mail should be rejected as it's not from a valid/authorised IP. – Daniel Mar 11 '15 at 16:13
  • 2
    That is secondary: joeqwerty's point is that you need to deal with the spam being sent *to* your server by making sure it's marked as invalid by your server. – BE77Y Mar 11 '15 at 17:41
  • @Daniel Your theory isn't entirely valid. While in theory SPF should work the way you describe, in practice SPF alone contributes only a small amount to spam scores and is rarely used to block delivery. If you really want to block this email (and you should) you will need to add a DMARC record with p=quarantine or (ideally) p=reject. – Peter Goldstein Mar 12 '15 at 00:52
  • Your SPF record is a little much...lol. What server is sending your outbound email? Is it mail.domain.org? Is that the only host sending out email (with that FQDN)? If so, then you can simply have it as `domain.org. IN TXT "v=spf1 mx -all"` – TheCleaner Mar 18 '15 at 17:38
  • Related: Our canonical ["What can I do to fight spam?"](http://serverfault.com/questions/419407/fighting-spam-what-can-i-do-as-an-email-administrator-domain-owner-or-user) question. (Which has its own related questions listed in the header that might help you out with SPF setup) – voretaq7 Mar 19 '15 at 17:17

2 Answers2

6

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

Community
  • 1
joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • Thank you for your answer. You said no to question 5 (adding the SPF record to my internal DNS), but in question 7 you said "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". The problem with that (correct me if I'm wrong) is that if I run "nslookup -type=txt domain.org" from my exchange server it returns nothing as there are no TXT/SPF records in my internal DNS server. So don't I need to add the SPF in Daniel's answer to my internal and external DNS? – Daniel Mar 12 '15 at 10:03
  • Does your internal DNS server host your public DNS zone? If so, then I misunderstood and you do need to add the MX and SPF records there. If not, then you need to add the MX and SPF records to your public DNS servers. If your internal DNS server only serves your internal AD DNS zone then that has no bearing on external email servers sending you email and they won't find your MX and SPF records in your internal AD DNS zone. – joeqwerty Mar 12 '15 at 14:31
  • The domain.org zone exists in both my internal and external DNS. The external DNS obviously resolves to my external IP's and the internal DNS to my internal IP's. But in the case that I'm receiving emails from "randomserver.de" which have "from: example@mydomain.org" in the headers, I assume my server would need to be able to access my own SPF record to determine if the email has come from a valid IP (even though it's technically checking if the email came from itself). So in that case I assume in my internal DNS I need the SPF record and an MX record pointing to my internal IP? – Daniel Mar 12 '15 at 14:39
  • In that case, yes you should add it to your internal DNS zone. – joeqwerty Mar 12 '15 at 14:48
  • I've added Daniel's suggested SPF record and an MX record to my internal DNS servers and waited for propagation. I then used telnet from a client on my internal network to send an email without authenticating. The email headers for that email once received show "SID:SenderIDStatus TempError". Any idea why that's happening? – Daniel Mar 13 '15 at 12:06
  • The other thing I'm still unsure about is that my MX record is mail.domain.org, and I if change the FQDN for the HELO response to mail.domain.org as you suggested but my SAN certificate for exchange doesn't contain mail.domain.org; instead it contains webmail.domain.org and autodiscover.domain.org then surely any server which tries to create a secure connection isn't going to trust the certificate? Which then leads me back to thinking I either need to pay to update my certificate and include the extra domain, or change my MX record to webmail.domain.org? – Daniel Mar 13 '15 at 12:38
  • @joeqwerty - feel free to add this link to your answer to allow Daniel to block inbound spam emails from spoofing internal senders. http://exchangepedia.com/2008/09/how-to-prevent-annoying-spam-from-your-own-domain.html - still works in Exchange 2010 as well, done properly. – TheCleaner Mar 18 '15 at 17:41
4

Usually this line is enough:

domain.com. IN TXT "v=spf1 mx a ~all"
                           ^1 ^2
  1. It allows all servers listed as an MX for domain.com to send emails for this domain.
  2. It allows the server with the IP of domain.com to send emails for this domain.

So …

  1. No
  2. No, but it would be good.
  3. No, to all.
  4. Change it.
  5. No, internal hostnames and ip addresses do not go into the SPF record
  6. Shorten it as shown above
  7. Maybe ;)
Daniel
  • 6,780
  • 5
  • 31
  • 60
  • 2
    Your first 2 points about the SPF record are inaccurate. You are correct on the MX portion. The "a" portion allows address host records as valid senders for any A record associated with that domain. The ~ is a soft fail, which basically says "anything else technically isn't valid, but maybe you should let it through anyway...just in case we are lazy and haven't updated this SPF record correctly." It should really be setup properly with a -all to hard fail anything not defined in the list if at all possible. – TheCleaner Mar 18 '15 at 17:35