• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 920
  • Last Modified:

spf records

i created an spf record using a wizard but when i test the spf by sending an email to spf-test@openspf.org, i believe the results show that it is not working properly.

"spf-test@openspf.org
mailout02.controlledmail.com #550 5.7.1 <spf-test@openspf.org>: Recipient address rejected: SPF Tests: Mail-From Result="none": Mail From="xxx@simex.ca" HELO name="mail.simex.ca" HELO Result="none" Remote IP="216.191.157.78" ##"

Here is my spf record;
"v=spf1 a mx mx:mail.simex.ca -all"

In the DNS Manager, the zone record type is "TXT" with the subdomain name of "simex.ca"

Please advise.



0
jnsimex
Asked:
jnsimex
  • 5
  • 4
1 Solution
 
PapertripCommented:
[root@broken ~]# dig txt simex.ca +short
"mail.simex.ca. 86400 IN TXT v=spf1" "a" "-all"

Open in new window

That is what your TXT record looks like when queried.

It should look like this:
"v=spf1 ip4:216.191.157.78 ~all"

Open in new window


0
 
PapertripCommented:
Unless you plan on changing the IP of mail.simex.ca often (probably not), then using the SPF mechanisms "a" and "mx" don't need to be used, all they do is cause another lookup to be performed.  Putting in just the IP of server(s) sending your mail is the best approach.  Also, even if you were to use "a" and/or "mx", you don't have the syntax correct for it in either your example or in the "real" results from my external query.

0
 
PapertripCommented:
If you have more than 1 IP you can do either of the following, depending on how many IP's there are (SPF TXT record character limit is 255).

"v=spf1 ip4:216.191.157.78 ip4:1.2.3.4 ip4:5.6.7.8 ~all"

Open in new window

or, if there are too many IP's for 1 record, use CIDR notation
"v=spf1 ip4:216.191.157.78/29 ~all"

Open in new window

0
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
jnsimexAuthor Commented:
I went with your idea of using a fixed ip in my spf record.

The dns lookup for my TXT record returned "v=spf1 ip4:216.191.157.78 ~all"

I resent the test email and the results are the same.

"spf-test@openspf.org
mailout02.controlledmail.com #550 5.7.1 <spf-test@openspf.org>: Recipient address rejected: SPF Tests: Mail-From Result="none": Mail From="xxx@simex.ca" HELO name="mail.simex.ca" HELO Result="none" Remote IP="216.191.157.78" ##"


0
 
PapertripCommented:
While you are editing DNS, you should try and make the PTR for mail.simex.ca match the A record:
[root@broken ~]# dig mail.simex.ca +short
216.191.157.78
[root@broken ~]# dig -x 216.191.157.78 +short
157-078.tor.economux.com.

Open in new window


Cool your new record looks great
[root@broken ~]# dig @156.154.70.1 txt simex.ca +short
"v=spf1 ip4:216.191.157.78 ~all"

Open in new window


Your SPF record has a TTL of 7200 -- 2 hours.  You can't rely on test results from the same tool if it looked up your SPF record within the last 2 hours, have to wait for it to expire from their cache.
0
 
jnsimexAuthor Commented:
So I created a PTR record for host name mail.simex.ca

78.157.191.216.IN-ADDR.ARPA

Not sure if this correct but in the text box, it said to enter in the IP address in reverse order + ".IN-ADDR.ARPA"

Yes, it looks much better now.

Thanks for your help.
0
 
jnsimexAuthor Commented:
Can you explain your logic for using a softfail vs a fail in the SPF?
0
 
PapertripCommented:
SPF hardfail will break forwarding 100% of the time.  If you are not concerned with people being able to forward emails from your domain, then you can turn on hardfail.   This is an inherent and well-known problem with SPF.  Keep in mind that it is a common practice for users to setup auto-forwards for their mail, say from their vanity domain to their gmail account for example.

How the receiving server treats SPF softfails is completely up to them.  Also how your mail client interprets results in the headers from authentication checks plays a role.  That is one of the problems in the email world -- you can't dictate how everyone will setup (or break) their receiving servers.  Gmail for example will display a warning that SPF softfailed, and that you should be concerned of a potential spoof.

Basically SPF is far from the end-all for mail authentication, it should be used in conjunction with at least DKIM.  I realize now I should have included that in the earlier replies, not sure why I didn't in hindsight.

How you decide to implement it is completely up to you -- even the big guys do things their own way because they take into consideration things like DKIM signatures, ADSP, receiver policies etc etc... all depends on how you want your mail to be treated.

[root@broken ~]# dig txt _spf.google.com +short
"v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"
[root@broken ~]# dig txt hotmail.com +short
"v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all"
[root@broken ~]# dig txt paypal.com +short
"v=spf1 include:pp._spf.paypal.com include:3rdparty._spf.paypal.com include:3rdparty1._spf.paypal.com include:3rdparty2._spf.paypal.com include:c._spf.ebay.com ~all"
[root@broken ~]# dig txt facebook.com +short
"v=spf1 ip4:69.63.179.25 ip4:69.63.178.128/25 ip4:69.63.184.0/25 ip4:66.220.144.128/25 ip4:66.220.155.0/24 ip4:69.171.232.128/25 ip4:66.220.157.0/25 ip4:69.171.244.0/24 mx -all"

Open in new window

0
 
jnsimexAuthor Commented:
Cool man. Thanks for the following up.
0
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

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

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