Why are my emails being sent to spam - a guide for GSuite
“This email to an investor was marked as spam! They only noticed it by accident. Why is this happening?”
Argh. Email deliverability. Like car brakes, we can all agree that they’re important, but we don’t want to have to learn how they work.
I got this email from a client, asking me to help: “This email to an investor was marked as spam! They only noticed it by accident. Why is this happening?”
So this is the high-level guide I wish existed, focused on the practical steps you need to take to make sure your emails don't go to someone else's spam folder.
It’s probably most relevant if you’re using GSuite (Google’s tools for organisations, including Gmail email), and a separate host for your domain/DNS (GoDaddy in their case).
There are 3 acronyms that matter for making sure your email doesn’t get marked as spam:
- SPF - Sender Policy Framework
- DKIM - Domain Keys Identification Mail
- DMARC - Domain-based Message Authentication, Reporting and Conformance
For modern email deliverability, SPF is essential, DKIM is also very important, but you can maybe get away without DMARC at first.
Unfortunately, Google’s basic setup guide for linking up your GSuite/professional Gmail to your domain doesn’t mention setting up any of them. So you may have working email, but occasionally find that it’s showing up in your recipients’ spam folders.
Note: If you’re using Google Domains for your DNS, they’ll have set all this up for you automatically. This guide is most relevant if you use a separate DNS provider (GoDaddy in this case).
Step 1: What do you have set up currently?
Start by finding out what kind of shape you’re in. Take screenshots before you start making changes, so you can be sure later whether you’ve improved things.
Check if your domains have SPF, DKIM and DMARC
1) Google has a handy tool that checks your domain for you. If your SPF and DKIM have green ticks, and there’s nothing red, you’re probably in decent shape:
Note: The ‘Effective SPF Address Ranges’ line is confusing - this gives you an indication of what to look for.
2) As a followup, try sending an email from your domain to ping@tools.mxtoolbox.com to receive a detailed report (make sure to click through, rather than just looking at the summary in the email).
For reference, mine looks like this (where I think the important things are correct, but I haven’t bothered with DMARC):
Note: I had hoped to use Google’s Postmaster Tools to get a sense of deliverability rate etc, but it always tells me that there’s no data to display, and to come back later.
Check if your domain has been added to spam blacklists
I also did some quick checks to see whether the domain had been added to any spam blacklists:
https://talosintelligence.com/reputation_center/email_rep
Blacklisted: no
http://www.sorbs.net/lookup.shtml
It told me that mydomain.com was “not found in the database”.
Great!
Note: I’m not convinced that these checks are sensitive enough. If you know of a better way to measure the email deliverability/spam rating of a domain, I’d love to hear from you!
Step 2: Set up the missing pieces
How to set up SPF
If your SPF is missing, that’s an easy fix - add a single TXT record to your DNS.
How to set up DKIM
If your DKIM is missing, that’s slightly more involved, since it involves both 1) a change to your Google Admin Console and 2) adding a line to your DNS.
After you’ve done those, run the checks again from above to make sure they’re passing.
Note: Even though you may need to wait 24-48h for the DNS changes to fully propagate to all clients, it seems that at least Google’s CheckMX Toolbox noticed changes immediately.
A few DKIM gotchas to watch out for:
- If you have multiple domains, make sure you pick the one you’re using for sending emails in the Google Admin page for email authentication:
- Make sure to press the ‘Start authentication’ button after generating the record on the Google Admin page. It seems to then stay permanently in a ‘Stop authentication’ state, which I think means everything is working.
- These Google instructions for DKIM suggest you can test things are working just by looking at the message header. I got burned by this, because I think I had forgotten the 3rd step (and so it wasn’t correctly aligned with my DNS record), the message header seemed to be fine, i.e. this seems to be a necessary but not sufficient test. For that reason, I now prefer the more stringent ping@tools.mxtoolbox.com test described above.
- As I understand it, not all DNS hosts can support longer (i.e. 2048-bit) DKIM keys, so I simply opted for a 1024-bit key as sufficient for now.
How to set up DMARC
DMARC is the icing on the cake, but it’s a bit more complicated for a few reasons:
- Configuration. You have to make some choices about what should happen when there’s a problem. The smart move is to start with monitoring-only (‘none’), then gradually ramp up to quarantining, starting with a small proportion of messages - see ‘Deploy DMARC slowly / Example deployment’.
- Monitoring. Unlike SPF and DKIM, DMARC gets input back from the email recipient. So you can nominate an email address to receive a daily aggregated report (or even a detailed immediate forensic one).
- 3rd-party sending. Until now, I had focused on sending from GSuite (via the Gmail-style interface), and ignored the Klaviyo newsletter that was being sent from the same domain, since deliverability and spam ratings were good for the newsletter (>99% deliverability). Importantly, Klaviyo has its own separate mail transfer agent and DNS setup, and it shouldn’t be affected by any of the SPF/DKIM changes we’ve made so far. However, be aware that DMARC (mis)configuration might affect 3rd-party sending.
- One final tip that had me tearing out my hair. All the guides seemed to suggest using _dmarc.example.com for the TXT record name - but in practice, that means setting it to just _dmarc on GoDaddy.
Conclusion
At the time of writing, I’m still not certain that things are working perfectly. It takes up to 48h for DNS changes to propagate, and it took months after the last set of changes to realise there were still some lingering deliverability issues. But the hardest part was finding a set of tools to test that everything was set up correctly - with those in hand, I feel much more confident of zeroing in inexorably on a stable configuration.