A few weeks ago, I started noticing that many EA organisations I work with have not correctly configured their domain names to stop their emails from being marked as spam. This came from a few specific requests where people had seen such issues, which prompted me to analyse all 25 or so organisations I had already worked with at that point. More than 35% of the organisations I looked at exhibited the problem.
A simple way to check if you need to improve your domain configuration is to use the Mail-Tester spammyness tool. Just send a preferably non-empty email to the given test address from an email address at the domain you want to check, then click the “check your score” button to get a report that highlights any issues.
You can use various strategies to avoid getting marked as spam, many of which are outlined here. One of the less apparent techniques that non-technical people have probably never heard of is enabling email authentication. This usually involves three technologies: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC). SPF allows an email server to check that a received email comes from the domain it says it’s coming from. For example, if it sees an email from user@altruistic.agency it can look up the domain altruistic.agency for information on what email servers are allowed to send emails using that domain and whether this email matches it. DKIM is about signing outgoing emails with a digital signature that the email server can check to confirm it’s an authorised email. DMARC uses SPF and DKIM to set a policy for how emails should be handled by the server depending on whether they pass the tests applied by those technologies.
I won’t go into too much detail on how these three technologies work, but all use DNS records to perform authentication. This means a lookup is made for the domain name to get authoritative data on something, which can be used to verify the ownership of a website and many other things. If you are interested, see this page for an exhaustive guide on exactly what SPF/DKIM/DMARC does. What you need to do to enable email authentication is add some DNS records.
What records to add depends on what email provider you use. Typically you will find this information in your provider’s documentation. For example, Google has instructions on adding the proper records for SPF and similar ones for DKIM if you use Google Workspace as your email service. The process is very similar for other email providers, but you need to be confident about how to add DNS records. Setting up DMARC can be a bit more involved depending on how you want to handle its reporting capability.
If you are not exactly sure what you’re doing, you could break your website or email.
For that reason, you should ask an experienced tech support person, web developer, or someone else used to editing DNS records. Altruistic Agency is happy to help with this, just send us an email, and we’ll take it from there. It usually does not take us more than 5–10 minutes to make the necessary changes, but it requires some access, so a conversation is a good first step.
Note that emails might pass through many servers before reaching their destination, and any server along the way might flag the email one way or another. The goal is to make sure no servers have any valid reason to think the email is spam. Many other filters are used to determine the final status, including directly in the user’s email client, but the above are some definitive steps to reduce the risk significantly.
Finally, if you see legitimate emails in your spam folder, make sure to unmark them. Similarly, if someone tells you your emails ended up in their spam folder, remind them to unflag them. This helps train the algorithm used by the email provider so that it learns over time that emails from your domain are legitimate.