0

I manage a small web server and have had some issues getting SPF/DMARC setup correctly for the domain. I'm trying to figure out why SPF validation sometimes passes and sometimes fails. This occurs when using the same validator and when no changes have been made to the record. It's almost as if it is reading different records from different sources on some attempts.

For this example, I'm using dmarcian.com as an SPF validator.

If I go to the site and use Tools--> Domain Checker, sometimes it says "Your domain has a valid SPF record and the policy is sufficiently strict." If I click "Check domain" multiple times (no chance of misspelling), sometimes it states "Your domain does not have an SPF record." Why would I get two different results on the same check when nothing has changed?

The provider is Arvixe (changing soon). The web server is Windows VPS, and the web server is not the email server. We pay for a separate bulk email service although we don't send very much.

I'm using WebsitePanel to edit the DNS records. SPF records are not supported, so I'm using a TXT record. It looks like this:

Name: _spf Type: TXT Data: v=spf1 +a +mx +ip4:207.210.200.162 +ip4:143.95.68.96 ~all

Domain: theiaicertification.org IPs: 108.167.130.38 / 108.167.130.39 Mail Server: 207.210.200.162 / 143.95.68.96

Improve this question
6
  • So your question is about why the MxToolbox SPF record check randomly fails?
    – joeqwerty
    Aug 24, 2018 at 22:20
  • 1
    No, I mentioned that, but it is unrelated. Then, I state that I am using dmarcian and explain that the same validation returns varying results. However, my post wasn't worded well. I somehow even posted the wrong spf record. I've proofed and corrected it for content and hopefully for clarity.
    – iAwardYouNoPoints
    Aug 25, 2018 at 1:22
  • 1
    I can't reproduce the problem you report. I consistently get "Your domain does not have an SPF record". That's probably because... you don't. SPF records go on the domain being protected, not an _spf subdomain.
    – womble ♦
    Aug 25, 2018 at 23:30
  • At the moment, it is consistently failing for me as well. Previously, I was literally clicking the button to verify it every minute or so, and it would vary. On the _spf, I've read several times that if you are unable to create a SPF record, that a TXT record is created with _spf as the name. However, I have also seen it stated to use "@" or leave it blank.
    – iAwardYouNoPoints
    Aug 26, 2018 at 1:35
  • Who says you should use _spf IN TXT? Source? That's simply not true. Who guides to use the SPF record type and the TXT only as an alternative? The SPF record type was deprecated in 2014, replaced by the TXT record. See RFC 7208, 3.1.
    – Esa Jokinen
    Aug 26, 2018 at 5:03

1 Answer 1

Reset to default
2

Your DNS zone is hosted on two DNS servers which isn't an unreasonable number of DNS servers to be hosting your domain on. Both DNS servers suffer from lack of IPv6, which can become a problem in the future.

Both authoritative DNS servers provide the same response when asked for TXT records for the domain, so that's not a problem either. The exact response I see is this:

theiaicertification.org. 86400  IN      TXT     "v=spf1 +a +mx +ip4:207.210.200.162 +ip4:143.95.68.96  ~all"

There is a few things I want to point out here.

The use of a and/or mx can be problematic for an IPv4-only mail server. That's because you have no control over which IP addresses will need to be validated against your SPF record, so your SPF record has to be standards compliant for validation of both IPv4 and IPv6 addresses. There is a limit to how many DNS lookups with no response are permitted during validation of an SPF record. However in your case you narrowly avoided that trap.

Prefixing every entry with + is not how SPF records are commonly written, but it appears to work.

I tested that it is possible to validate IP addresses against your SPF records using the Python implementation of spf validation:

>>> import spf
>>> spf.query('192.0.2.1', '[email protected]', '').check()
('softfail', 250, 'domain owner discourages use of this host')
>>> spf.query('2001:db8::1', '[email protected]', '').check()
('softfail', 250, 'domain owner discourages use of this host')
>>>

Neither of these would explain why you see different results though. A possible explanation of different results is caching. The TTL on your TXT record is 86400 seconds, which is 24 hours. If you recently changed it and the TTL also was 24 hours before, it can take 24 hours for your change to take effect everywhere.

I am guessing the service you are using to validate your SPF records has more than one recursive resolver and at least one of them has cached an older version of your TXT record.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .