Ahh, the joys of computing. My plan for a 30 minute task dissolves once more into 3 hours of head scratching. As always, the solution was ridiculously easy.

The aim: To add Spam Protection Filter/Sender Policy Framework to our DNS.

The problem: Having more than one TXT entry wasn’t possible with my DNS provider (and if it was, it would have created an error)

The solution: Put all the TXT strings in the same TXT entry field, ensuring a space character is present WITHIN the strings if multiple strings are to be concatenated.

The TL;DR detail:
We use google apps, so google conveniently suggest the SPF code to use. At the time of writing, that’s:


To create an SPF record for a domain:

Publishing an SPF record that uses -all instead of ~all may result in delivery problems. See Google IP address ranges for details about the addresses for the Google Apps mail servers.
If your registrar also requires a host setting (such as @), see the TXT records for specific domain providers list for precise instructions.
Save your changes.
Keep in mind that changes to DNS records may take up to 48 hours to propagate throughout the Internet.
If you have difficulty creating an SPF record, contact your domain provider for assistance.


Which sounded so easy, except adding that to my DNS hosted with gandi failed with an error about a duplicate line.

The duplicate was a google site verification entry also using the txt field. From reading about BIND, it appears TXT fields can be on multiple lines but will be consolidated later. I guess the Gandi interface want’s you to do the consolidation yourself.

So for me, the correct SPF and Google Site Verifcation code look like this:


@ 300 IN TXT "v=spf1 a include:_spf.google.com ~all " "google-site-verification=1-3-y-blah"


Notice: The two strings enclosed by speach marks. I could have done this as one long string but I think I’ll find adding any other TXT entries easier if I can see where each one starts and finishes. Actually, I’ve simplified my TXT entry for the blog, I also list a couple of server IP’s and eventually will need to add some IP6 addresses. The a in SPF records appears to only picks up the domains @ host, not every single host in a domain.
Notice: The extra space character within the SPF string – because …~all” “goog… gets concatenated to …~allgoog… with the missing space causing a PERMERROR for SPF validation and probably breaking the site verification too.
Notice: using 300 seconds for the life is fine for testing but probably wants increasing to a larger number once you know it’s working. I’m going for 43200 seconds which is 12 hours.

or at least, I *thought* my SSL certificate wasn’t working in Safari.

When I launched our new company web site last month I thought I’d checked the SSL certificate was working in all browsers. It wasn’t, a customer quickly pointed out it didn’t work in for him and I tracked down a particular issue to do with chains. It seemed fine for google Chrome but Firefox couldn’t work it out. Anyway, fixed in half an hour, or so I thought.

Being extra vigilant, I fired up safari on my mac and cringed when I saw that although the url said https:// , safari wasn’t giving me a secure connection and I couldn’t view the certificate. Look, here’s a screen shot:

So, I spent an hour googling for people with similar problems, reading up on SSL certificates, studying the nginx config file thinking I probably had a typo (after all, it was working in both Chrome and Firefox) and then I stumbled upon a post (I can’t remember where, sorry, otherwise I’d link to it) that said safari looks just the same when on a secure connection as an insecure connection. I checked apple web site using https://www.apple.com and sure enough, no sign of things being secure. Except, there is…. look very closely in the top right corner of safari. If you click on the padlock you can view the certificate.

See, it was there all along, working fine. Ho hum, another hour lost to computing glitches.