So, I built a website for a customer of mine, and hosted it on the customer's GoDaddy economy hosting account.
The site works fine, except for one thing. My customer never sees email sent from the site! I get the as emails, and I can see they are addressed to the customer, but he never sees them.
The email address on which my customer receiving mail is the Office 365 email that comes with his hosting package. Are the missing emails in his spam box? He's using Thunderbird, so we may never know. A GoDaddy rep suggested that I get the client to look at his email via the web interface, which I will ask him to do.
So, I'm thinking... "the SPF record for the domain must be set up to only authorize Microsloth's O365 servers to send mail on behalf of my customer's domain". So, I need another SPF record that authorizes the webserver as a sender for the domain, right? Makes sense to me, anyway.
So I consulted the Google. "Godaddy add SPF record" returned among other things a few GoDaddy help pages. "Cool", I thought, "I'll have this done in no time!" Wrong.
The help pages all require use of Classic DNS Manager, which seems to have been removed. The comments on the page indicate that others have noticed this problem, some as long ago as December 2015!
One comment suggests browsing to dns.godaddy.com. This would probably work for domains that I own, but doesn't give me access to my customer's domain that I access through the pro program. Therefore, this is not a solution.
GoDaddy telephone support is usually excellent, so my next thought was "I'll call the wizards at GoDaddy, surely they will know the answer!"
About 40 minutes and two departments into the tech support call, while sitting on hold, I found spfwizard.net. This site helps you interactively build an SPF record for a zone file. Note that I said "build an SPF record for a zone file". Records in a zone file are actually lines of text, while the interface that GoDaddy provides is a dialog. So, what I did was using GoDaddy's online interface, I created a new TXT record. The hostname was @, and the TXT value was v=spf1 mx a ip4:22.214.171.124/32.
The TXT value came from the portion of the zone record created by spfwizard.net that is in double quotes. The zone record looked like this:
example.com. IN TXT "v=spf1 mx a ip4:126.96.36.199/32"
... so I took the part enclosed in double quotes above, and used it for the TXT value.
Now, it would be nice if GoDaddy hadn't taken away the Classic DNS manager, or had at least updated their help documentation when they did so. But, they didn't. So, if you need an SPF record, go to spfwizard.net, fill in the blanks, and use the portion of the text generated by spfwizard.net enclosed in double quotes (omitting the double quotes) as the TXT value of a DNS TXT record.
That should get you going.
I am writing this right after doing it, so I am not sure if the desired result is achieved. I'll either edit this note or comment on it when I find out wither way.
Solved! Go to Solution.
No Comments? Is this too much "inside baseball"?
My "solution" did not work. A little research revealed that multiple SPF records are not recommended, so I combined the information from the two I had. Here is the resulting TXT Value:
v=spf1 ip4:188.8.131.52 include:spf.protection.outlook.com ~all
Now we'll see how that works!
Even the revised SPF record did not solve the problem.
What did solve the problem is a setting in cPanel.
In the Email category in cPanel, click MX Record. On that page, make sure that Remote Mail Exchanger is selected, not Local mail Exchanger.
In my clients account, for some reason, Local Mail Exchanger was selected. This caused the server to try to contact a non-existent local mail exchanger. GD support said that despite this, *some* emails would eventually get through.
Now, about that SPF record... it's a good thing to have anyway, to make sure your site is known as an authorized sender for the domain.