Question/help with SPF Record - ORF Forums

@Josh: Is the local DNS server configured in ORF the authoritative DNS server for your domain?

http://blog.vamsoft.com/2010/04/08/tales-from-tech-support-part-13-dns-issues-with-own-domain/

@Josh: I tested your domain using nslookup and I was able to successfully query your MX, A and SPF records, so either your authoritative DNS was down when ORF tested, or there is something wrong with the local DNS server configured for the ORF lookups.

As for testing, I doubt there is a service like that (spammers would abuse it). You can test the policy without sending emails on our website (it uses the same evaluation process as ORF):

http://vamsoft.com/support/tools/spf-policy-tester

Also, as your current SPF policy ends with a SoftFail qualifier (~all), ORF will block emails which fail on the SPF test only if you configure it to "Blacklist emails on SPF SoftFail" (http://vamsoft.com/r?o-hto-adm-spfsettings), or if you change the policy to Fail (-all).

@Josh: According to the SPF standards, SoftFail should be used temporarily in testing/transition periods only. For example:

1. You publish an SPF policy (ending with -all) which allows only your MXs to send emails in the name of your domain (v=spf1 mx -all).
2. Someone tries to spoof your domain, recipient A checks your SPF record via a public DNS server. It returns your SPF record and caches the query result.
3. Recipient B (using the same DNS service) also receives an email which spoofs your domain. Instead of querying the authoritative DNS of your domain again, the DNS server returns the query result it cached earlier. That is OK, since the SPF policy has not been changed in between the two queries.

Now, let's assume you create a website, hosted by a third-party provider. The website will send newsletters and confirmation emails using the hosting provider's mail server. You want these emails to be sent with your domain name, so you will need to add the hosting provider's mail server(s) to the SPF policy as allowed senders. You modify the SPF policy to v=spf1 mx include:hostingprovider.com -all

Problem: your website sends an email from the mail server of the hosting provider to recipient C, but when it queries your SPF record, it receives your old, outdated (cached) SPF record, and the email gets rejected (since the third party server is not allowed as a sender by the old policy).

That is when SoftFail comes into play. To avoid the problem, you should

1. Switch your SPF policy to SoftFail first (transition period): v=spf1 mx ~all. Wait a bit so the previous SPF record "wears off" in DNS caches.
2. Modify the SPF policy, but keep it SoftFail: v=spf1 mx include:hostingprovider.com ~all. Wait a bit so the previous SPF record "wears off" in DNS caches.
3. Now you can switch your new SPF policy to Fail: v=spf1 mx include:hostingprovider.com -all

So basically, the above scenario is what SPF SoftFail was meant to address. Unfortunately, many people don't care and keep their SPF policy indefinitely in the SoftFail state, because they are not sure what they are doing and want to play it safe. Of course, It is understandable to use SoftFail if you are a huge provider with constantly changing MXs like Gmail (i.e., they are constantly in transition), but if your MXs change rarely, it does not make any sense, and you will not stop spoofing (since, according to standards, SPF client should accept emails on SoftFail, thus spoofed emails will be allowed in).

Personally, I always recommend all of our clients to use "-all", so they explicitly tell others which hosts are authorized to send emails with their domain name.