• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1090
  • 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 (  by EXCHANGE.domain.local  

(instead of the outside domain)

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

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?
Matt Kendall
Matt Kendall
  • 4
  • 2
1 Solution
Alan HardistyCo-OwnerCommented:
Sounds like you have everything setup okay and you can test your SPF record here:


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.

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

Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

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

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

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

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