18

I'm setting up SPF records for my domain, and am not getting the results that I expect. It's quite possible I'm making some sort of mistake, but first I'd like to ask: does it take time for the changes I make to SPF records to propagate?

Daniel Griscom
  • 493
  • 1
  • 4
  • 15
  • 2
    note that some DNS caches ignore TTLs and just cache the record for however long they want. This is broken, but is unfixable because those broken DNS caches are running on machines you have no control over. – cas Sep 22 '15 at 01:32
  • @cas the servers are not really broken so much as the whole concept of TTL for DNS is incomplete and naive. It's the only way to control abuse and traffic levels. This doesn't just mean servers are ignoring the right TTL, in cases they have been passed a lengthened TTL from an upstream server. – JamesRyan Sep 22 '15 at 12:20
  • 1
    @JamesRyan Many, many ISP DNS resolvers completely ignore TTLs they are handed. This is not a case of them being given a longer TTL, it is a case of not operating according to standards. – EEAA Sep 22 '15 at 12:46
  • @EEAA no it is a case of the standard not being real world usable and an unofficial norm taking it's place through necessity – JamesRyan Sep 22 '15 at 14:40
  • 3
    All DNS changes take time to propagate, there's nothing special about SPF records. They propagate in the exact same way as the rest of DNS. – Barmar Sep 22 '15 at 20:43

3 Answers3

15

Yes, there might be caching or other delays depending on how the zone is being edited (nsupdate results in fairly immediate changes, less so if some web front-end talks to a database that maybe eventually does something to update a zone), how zone transfers are done (the master DNS server might push changes, or the slaves could instead be configured to periodically poll that server for updates), and whether you are querying an authoritative DNS server or something else that might have cached the previous TXT record due to a previous query from your client, and thus is unaware of the changes the master server(s) might already know about.

Use nslookup or dig to query different servers (and also check the SOA serial number, it should have bumped on a change, if not, you're looking at old data).

% dig +short @8.8.8.8 -t TXT google.com
"v=spf1 include:_spf.google.com ~all"
% dig +short @8.8.8.8 -t SOA google.com
ns2.google.com. dns-admin.google.com. 103585632 900 900 1800 60

The TTL of the TXT record might be an important thing to know; the full dig output should include that.

thrig
  • 1,626
  • 9
  • 9
  • Interesting. The TTL of my TXT record is 14400 (4 hours), but still fetching through Google shows changes fairly quickly (well within a minute). Your `dig` command to fetch via Google's servers is what I needed, though: thanks. – Daniel Griscom Sep 22 '15 at 00:11
  • 2
    @DanielGriscom Keep in mind that "8.8.8.8" isn't a single machine, but rather a global cluster. You may very well be hitting different resolvers each time, and each one of those might have to prime their cache separately. – user Sep 22 '15 at 14:58
9

First off, DNS records do not "propagate", at least in an active sense. Records are cached at various layers, and the delay in updating records is caused by waiting for cached records to expire and be fetched anew from upstream servers.

Now, for your question - yes, SPF records are DNS TXT records and as such, can take some time to update.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • The wait for delays in the layers of cached records being updated IS propagation! – JamesRyan Sep 22 '15 at 12:14
  • 3
    @JamesRyan Propagation implies that there is an **active** motive behind the records spreading. That is not the case. Many people who aren't familiar with DNS do assume there is active propagation, which is why I included this part of my answer and also why I qualified the "active" part. – EEAA Sep 22 '15 at 12:18
  • It does not imply an active motive, merely a process that has to go through layers. In any case Propagation is the technical term used to denote this process specifically in DNS so it should not be quoted as if it is an incorrect term. Your emphasis is on the wrong part. – JamesRyan Sep 22 '15 at 12:25
  • 1
    @JamesRyan I disagree. – EEAA Sep 22 '15 at 12:39
  • The term "propagation" is actually used with this meaning in many DNS RFCs: section 5 of RFC 2916, sections 2.3 and 3.1 of RFC 1912, etc. – Chris Down Sep 22 '15 at 13:02
  • 2
    People, this is why I qualified the usage of the term "propagate". I understand what the DNS RFCs say, and I understand what propagate means. I was clarifying the term, as way too many people assume it means something that it does not. – EEAA Sep 22 '15 at 13:13
  • Well you have just not expressed that very clearly. Quotes around a word imply that you are questioning the use of that word, not that it's meaning is misunderstood. It's all very well 'disagreeing' with English, but it won't help people understand what you mean when you say something conventionally different to what you mean. – JamesRyan Sep 22 '15 at 14:46
  • 1
    @JamesRyan You're always free to edit answers to clarify. – EEAA Sep 22 '15 at 14:46
3

If you changed the record; is dependant on your TTL, check out https://www.whatsmydns.net/ to see propagation status across common servers globally, if not; it's dependant on your negative cache. All this information is part of the SOA record, TTL can be changed per line.

Another good resource is https://dmarcian.com/spf-survey/

Good Luck.

Jacob Evans
  • 7,636
  • 3
  • 25
  • 55