Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1088
  • Last Modified:

Strange SPF - Exchange Email issue

Hi all, I'm having an issue with an SPF record on an exchange server that's confusing me.  We have all the correct DNS settings set up for a mail server "mail.domain.com".  We have a txt record with:
v=spf1 mx -all

Which should mean it will allow mail from the mx server (which is "mail.domain.com"), yet when we send email to a certain client (who is outside the network), their email server rejects it with a SPF record error: SPF unauthorized mail is prohibited.

More specifically:
someserver.secureserver.net gave this error:
SPF unauthorized mail is prohibited
(that's the receiving server)

It sends the original headers back with the email and it says:

Generating server: EXCHANGE.domain.local
someserver.secureserver.net #550 5.7.1 SPF unauthorized mail is prohibited.

Received: from EXCHANGE.domain.local (192.168.1.21)  by EXCHANGE.domain.local  

(instead of the outside domain)

Also, another part says
x-originating-ip: [192.168.1.110]

Which is their internal IP address that I obviously can't add to the SPF record.  I'm guessing this is somehow the problem, the external mail server is somehow getting the internal IP address of the mail server, and it's rejecting it due to the spf?

Does anyone know might be wrong with the setup?
0
Matt Kendall
Asked:
Matt Kendall
  • 4
  • 2
1 Solution
 
Alan HardistyCo-OwnerCommented:
Sounds like you have everything setup okay and you can test your SPF record here:

http://www.kitterman.com/spf/validate.html

If you would like a 2nd opinion, please drop me a test email to testmail@sohomail.co.uk and I'll check my Anti-Spam logs for the IP / SPF etc and report back.

Sounds like it might just be them, but you never know.

Alan
0
 
Matt KendallTech / Business owner operatorAuthor Commented:
It looks like it is a configuration issue because that test email is rejecting them as well, except it's giving the outside IP address of the mail server.  I've added a ip4:<outside ip address>/24 to the spf.  The mailserver's IP address last number is 89, but the test email said it came from 90, so I figure adding the netmask 24 should get all the available numbers at the end in case it changes.  

It looks like the dns has a ttl of 4 hours so I'll know in a few hours if it worked..
0
 
Alan HardistyCo-OwnerCommented:
Okay - you are sending out with an FQDN ending .local, which isn't correct - it should be your correct FQDN for your public domain which looks like #####nat.com

Your sending IP is xxx.xxx.xxx.90 and the SPF record you currently have for the domain is:

v=spf1 mx ip4:xxx.xxx.xxx.89/24 ip4:xxx.xxx.xxx.90/32 -all

Running that through on the Kitterman site does show a Pass, so it should sail through, but as you have recently made changes, then that will explain things.

Testing without the added IP's in the SPF record gives this:

Mail sent from this IP address: xxx.xxx.xxx.90
Mail from (Sender): user@#####nat.com
Mail checked using this SPF policy: v=spf1 mx -all
Results - FAIL Message may be rejected

You have mail arriving on one IP which resolves to mail.#####nat.com and sending from the xxx.xxx.xxx.90 IP, which is fine, but you need to create a new A record called something like outbound / send / something which points to the xxx.xxx.xxx.90 IP Address and setup your FQDN on your SEND Connector to match that name and then you should have fewer problems sending mail.  You also need to contact your ISP and ask them to setup Reverse DNS on the xxx.xxx.xxx.90 IP Address as outbound / send / something.#####nat.com to match the FQDN you choose.

Alan
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Marcus BointonCommented:
It doesn't sound like there's anything wrong with your SPF, but it looks like the intermediate server does not perform SRS correctly, resulting in downstream SPF failure.
0
 
Alan HardistyCo-OwnerCommented:
The SPF was wrong.  Inbound IP was different to outbound IP, so just having MX in the SPF record caused a FAIL on SPF check.

Alan
0
 
Matt KendallTech / Business owner operatorAuthor Commented:
Thanks so much!  I'm not getting send errors anymore.
0
 
Alan HardistyCo-OwnerCommented:
You are welcome.  Happy to help.

Alan
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now