Troubleshooting SPF and DKIM for Hosted Mail with Name.com (Part 1)

There is a real reason why you and your clients have suddenly started getting more bounce backs. Bonus: Why it’s important to regularly review your technology stack to ensure it fits the business need.

At the end of the year we’re all distracted, just trying to creep and gasp over that finish line. So it starts with you making a note to yourself that it’s odd… you seem to be getting more and more bounce back emails that look like this:

At their article, Google notes that “Important: Starting November 2022, new senders who send email to Google Gmail accounts must set up either SPF or DKIM. Learn more.” This explains why I started seeing it more at the end of the year. I thought I had already configured SPF previously. As we will later see, I had not.

Stick around to the end of this topic for an overview of DKIM and SPF, in a later part.

Name.com is my preferred host and registrar for a ton of reasons from reliability, reasonable prices, professional, nonjudgemental customer support. They also make it stupid easy to do administration tasks either via api/automation or using a friendly graphical interface.

Name’s documentation on how to do these is great, so please give them a click so they see their documentation in use. My copy here has notes on what I noticed as I followed through the steps. The short version of this issue is that I discovered that the documentation only applies to name.com’s hosted email product, which I do have, but not their standalone email product.

Crucially, when I first set up the services for my personal use, I had gotten their standalone hosted email and only later bought hosting to start a website. In a case of the cobbler’s children truly having no shoes, my personal services rotted while I languished in MSP-style hell for a few years. Now that I have a better work-life balance, all of the backlogged tasks are finally getting dealt with.

Adding DKIM and SPF Records for Hosting Email

Last Updated: Jul 14, 2022

Adding DKIM and SPF records to your domain will improve your email reliability, and will reduce the chance of it being filtered to the receivers spam folder. You first need to activate these records in your Name.com hosting plan’s cPanel. Once they are active, you will add the DKIM and SPF records that it provides you to your domain as TXT DNS records:
 
You will first need to active the SPF and DKIM records in your cPanel

• Log in to your cPanel account.
• Click the Email Deliverability icon, located in the Email section of the cPanel.
• Click the Manage button, next to the domain you wish to verify.

• Starting with the DKIM record. Copy the Value for the DKIM record by clicking the Copy button.

• You will then want to add these records to your domain as DNS records. To do that, return to your Name.com account, and
  • Click the green My Products link.
  • Scroll to Hosting, click Manage of the specific product.
  • Scroll down to the DNS Management section
• Here we add the 2 different TXT DNS records’ one for the SPF, and one for the DKIM.
• DKIM – Enter default._domainkey in the Host field. Also paste the long string of code into the answer box. The string begins with “v=DKIM1; k=rsa;

• SPF – Repeat steps 4-6 for the SPF record. Leave the host field blank and paste the SPF string into the answer field.

Note: The Install the suggested record button is not functional and will not do anything.
Note: These records and functionality may take upwards for 48 hours before working.
 

Now, the final test is to check with an outside service. Given that it may take time for DNS records to propagate, checking immediately and seeing a DKIM fail is expected. However, we pay attention to the entire check to ensure that the tools we have for internal checking of SPF/DNS record are reporting correctly. I am a fan of using LearnDMARC to check SPF and DKIM configuration as it will tell you what configuration errors you have and why its DMARC did not pass.

In the following image, DKIM auth not being present is expected behavior. But notice that even though the Email Delivery check indicated that SPF was properly configured, and we had a matching TXT/DNS record to that effect, the DMARC results gave it a softfail.

My hypothesis at the time was because I do not specify a sender domain in SPF, per seanthegeek’s article on the subject. “You might not even need to include every vendor in your SPF records anyway. If the vendor supports DKIM signing, you can rely on that to pass DMARC, even if the sender is not in your SPF record. Just make sure you are using ~all in your SPF record.”

I am using ~all in my SPF record. Since I do not manage the mail servers that name.com might assign my domain to, I think I’ll leave it this way for now and see what happens as DNS records propagate in the next few days.

Here is an example of how learndmarc helps troubleshooting:

Part of the troubleshooting process is to form hypotheses and tweak the setup to test them.

The change I also made to my SPF record is to change the option on A and MX to +.
This will be an easy change to notice, since uriports will flag these + as implied. Click the little magnifying glass next to the SPF fail in learndmarc and it will take you to the uriports SPF analysis tool.

52 hours later, I am still getting softfail on SPF alignment and fail on DKIM. I inspect the outgoing IP address listed on my email headers and find it is unchanged, so I will add 64.98.42.60 to my list of authorized IP addresses to send email.At this point, I started finding more and more outgoing IP addresses and suspected that their outgoing services are in some kind of round-robin setup that all answer to the same domain. Since I didn’t know what that name was…

I ended up submitting a support request.
The request was fruitful enough – they provided a SPF record that covers all of the various outgoing email servers.

v=spf1 include:_spf.hostedemail.com ~all

With SPF passing, Google no longer bounces my emails back. But I wanted the email service I’m paying for to sign my outgoing emails with the DKIM headers – if I’m going to all this work, I want to do it fully and completely right. I wrote back asking if there was a way to have RoundCube, the standalone email product, apply DKIM.

I suspected the answer is no – and it is; for the standalone email product. But not for the hosted email product, which I learned during this support conversation that I’m already paying for with my hosting plan.

This kind of situation is extremely common in progressive sales situations – I’ve been on the other side of migrations where a client buys one service, and then buys more of a product(s), but the migration to the most efficient use of resources and capital doesn’t happen for a variety of legitimate and less understandable reasons.

Regularly reviewing what products and services are being paid for even if you’re sure you know everything is fine is, in part, meant to capture exactly this kind of situation so that a change plan can be put in place. For a small business like mine, this is going to save under a hundred dollars a year. But at a bigger organization, I’ve seen catching this kind of thing trim thousands, if not tens of thousands or more, of excess from budgets that can be immediately reinvested into initiatives like employee training and retention, or a better tool or process that helps deliver more value to customers. In Part II, I will go over how to I migrate from the standalone email product to the hosted product (which allows me to set up additional mailboxes, excellent). I am also planning on creating a reference article on DKIM and SPF, and looking into the relationship between email security tools like these and email integration in web apps for the interest of my fellow developers.

Thank you for reading. Please let me know if there are any clarifications I can make or further questions I can answer either down in the comments, on LinkedIn, or hit me up on Mastodon.