How do i handle the SPF Record issue for exchange2003 email server when the recipient blocks our emails?

[root@broken ~]# dig txt concordia.net +short
"v=spf1 -all"

Select allOpen in new window

That says that concordia.net says that nobody is allowed to send mail from concordia.net ;)

The following assumes the mails you are sending have an envelope-from of @concordia.net or a subdomain of that.


You SPF record needs to be put into DNS at concordia.net as a TXT record, and should look like this:

"v=spf1 ip4:202.175.126.170 ~all"

Select allOpen in new window

That assumes 202.175.126.170 is you only sending IP, if for example .171 sends mail for concordia.net as well, then you simply add another ip4 mechanism

"v=spf1 ip4:202.175.126.170 ip4:202.175.126.171 ~all"

Select allOpen in new window

OK hold on, there is some conflicting information in your question.

It is noticed that a email server (recipient side) unable to receive email from concordia.mo (Sender Side) is because there is a problem with the sender's SPF (Sender Policy Framework) record.

The recipient side provide the following information:
It seems that the mail server claims it is concor-mail.concordia.net but the SPF record of concor-mail.concordia.net denies almost all IP addresses.

Is the envelope-from of the mails you are sending @concordia.mo or @concor-mail.concordia.net ?  SPF doesn't care what the mail server says it's hostname is, what matters is the MAIL FROM or envelope-from, return-path, etc.

So, first off, mail.concordia.mo DNS looks good

[root@broken ~]# dig mail.concordia.mo +short
202.175.126.170
[root@broken ~]# dig -x 202.175.126.170 +short
mail.concordia.mo.

Select allOpen in new window

However you have no SPF record for concordia.mo.  If you are in fact sending mails from @concordia.mo, then that is where you need to put the SPF record I suggested.  If you are also sending mail from @concordia.net as well, then that domain will need the same SPF record.

"It seems that the mail server claims it is concor-mail.concordia.net"

This is no longer the case as the mail server responds as mail.concordia.mo - so if you have changed this recently, then good.

Reverse DNS record is correct and is currently set as mail.concordia.mo

You don't have an SPF record for the domain concordia.mo, so there is nothing to add to SPF unless you want to set one, but nothing will be rejecting you now as you are RFC compliant.

If you want to add an SPF record and ONLY send mail for the concordia.mo domain from your Exchange 2003 server, then the following should be sufficient:

v=spf1 mx mx:mail.concordia.mo ~all

This record is added as a TXT record in your domain's DNS Control Panel.

Please follow my instructions for proper SPF setup.

"v=spf1 ip4:202.175.126.170 ~all"

Select allOpen in new window

This is not valid with your current DNS records.

v=spf1 mx mx:mail.concordia.mo ~all

Select allOpen in new window

There is no MX record for mail.concordia.mo.

Even if there was an MX record for that which pointed to 202.175.126.170, all that is doing is requiring 2 (minimum) additional lookups to be performed for each SPF check, one for the MX RRSET for mail.concordia.mo, and another one for each MX that might be listed.  This is unnecessary -- just put the IP.

Hi Alan,

You are seeing the results for the MX record of concordia.mo, not mail.concordia.mo.

Correct variants of your suggested record would be:

v=spf1 mx:concordia.mo ~all
v=spf1 a:mail.concordia.mo ~all

Select allOpen in new window

But even then, it is best to just put the IP so that additional lookups to get the same end-result are not required.

Please check your facts before you post incorrect information.

Thanks for the advice, perhaps you should follow it as well.

[root@broken ~]# dig mx mail.concordia.mo

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> mx mail.concordia.mo
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50212
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;mail.concordia.mo.             IN      MX

;; AUTHORITY SECTION:
concordia.mo.           10800   IN      SOA     vassun1.macau.ctm.net. anita.macau.ctm.net. 2008021001 5600 5900 2000000 86400

[root@broken ~]# dig mx concordia.mo

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> mx concordia.mo
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45802
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;concordia.mo.                  IN      MX

;; ANSWER SECTION:
concordia.mo.           86400   IN      MX      10 mail.concordia.mo.

;; AUTHORITY SECTION:
concordia.mo.           172800  IN      NS      vassun2.macau.ctm.net.
concordia.mo.           172800  IN      NS      vassun1.macau.ctm.net.
concordia.mo.           172800  IN      NS      ns3.macau.ctm.net.

;; ADDITIONAL SECTION:
mail.concordia.mo.      86400   IN      A       202.175.126.170
vassun1.macau.ctm.net.  86161   IN      A       202.175.3.3
vassun2.macau.ctm.net.  86161   IN      A       202.175.3.8

Select allOpen in new window

RFC 4408             Sender Policy Framework (SPF)            April 2006


5.4.  "mx"

   This mechanism matches if <ip> is one of the MX hosts for a domain
   name.

   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]

   check_host() first performs an MX lookup on the <target-name>.  Then
   it performs an address lookup on each MX name returned.  The <ip> is
   compared to each returned IP address.  To prevent Denial of Service
   (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
   evaluation of an "mx" mechanism (see Section 10).  If any address
   matches, the mechanism matches.

   Note regarding implicit MXs: If the <target-name> has no MX records,
   check_host() MUST NOT pretend the target is its single MX, and MUST
   NOT default to an A lookup on the <target-name> directly.  This
   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
   Section 5.  If such behavior is desired, the publisher should specify
   an "a" directive.

@Papertrip - I am not going to debate this with you - you are not correct in what you are saying.  I have setup numerous SPF records correctly for countless domains and none of them follow your suggestions and none of them have any issues with sending mail to anyone.  Check my credentials and you will see that I am more than au-fait with Exchange and it's various elements, including SPF records.

As there isn't currently an SPF record - then this isn't the issue.  Mail has never been rejected through a lack of an SPF record, but it has been rejected by the wrong SPF record being configured.

The biggest issue that is being faced here was the fact that the FQDN on the server was set incorrectly - which has now been changed, so adding an SPF record is not even necessary to resolve this question as the issues was the incorrect FQDN on the SMTP Virtual Server.  

The SPF record I have suggested is perfectly valid and you can put the IP or the MX record - either is valid and what do you care if someone else has to perform an extra DNS lookup?

@GT666 - If you want to setup your own SPF record, please visit the following Microsoft Site, fill in your domain name, follow the prompts and then copy / paste the output as your SPF record:

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

Check my credentials and you will see that I am more than au-fait with Exchange and it's various elements, including SPF records.

Check out my credentials once I've been a member for 2 years like yourself.

You don't need to debate it with me, you can however debate with the authors of RFC 4408 if you like.

@GT666, just so that you can have all the information you need, I changed the SPF record of one of my domains to match what has been suggested by others for your SPF record, then tested it at http://www.kitterman.com/spf/validate.html

I have changed the domain name in this paste, but it was tested using the real domain name.

Input accepted, querying now...
evaluating v=spf1 mx:mx.domain.com ~all ...
Results - record processed without error.

The result of the test (this should be the default result of your record) was, ambiguous . The explanation returned was, SPF Ambiguity Warning: No MX records found for mx mechanism: mx.domain.com

That result is correct, there is no MX record for mx.domain.com, there is only an A record.  There are however MX records for domain.com.

All you need for in your SPF record for concordia.mo is

"v=spf1 ip4:202.175.126.170 ~all"

Select allOpen in new window

good answer