“Have you checked your spam folder?”, “Why are my WordPress emails going to spam?”. Probably, one of the most common issues we’ve had to deal with. Every website uses emails. Whether it’s a confirmation email for creating an account, a WooCommerce order notification or even a billing email to a client. Sometimes it won’t matter, and your business will take a massive hit, both repetitional and revenue, by missing out on potential clients, just because these crucial emails never reached the intended recipient. So what do you do if you or your business relies on emails?
In this article, I’ll go over the difficulties we encountered and how they were resolved, briefly talk about SPF, DKIM and DMARC. We’ll go over various DNS settings and I’ll show an example of how we set up emails with Microsoft Office 365. I tried to make this article beginner-friendly, so some overly technical terms are simplified for easier understanding. Let’s get started!
The “plugin” approach
One of the easiest and most straightforward methods to fix all your email problems is by using a reliable third party SMTP service. We tried many, and for individuals or small startups, we’ve found that Sendinblue is the perfect solution. Not only do they position themselves as an “all-in-one marketing platform”, allowing you to manage marketing email campaigns, setting up a chat environment on your site, buy they will actually give you an free plan with absolutely no expiration that has a generous daily limit of 300 emails!
And if you pair it with a free WordPress plugin, one of the more popular ones is WP Mail SMTP by WPForms, that allows for a quick and easy integration, it’s as easy as following the next 5 steps:
- Step 1. Install and activate the plugin;
- Step 2. Select the SMTP service of your choice (again, we went with Sendinblue, but any other service will work just fine);
- Step 3. Follow the wizard instruction, generate an API key and fill in the “Sending Domain”, “From Name” and “From Email” fields;
- Step 4. Select any additional options that might be required.
- Step 5. Complete the wizard (all the other optional steps can be skipped).
The process couldn’t been simpler!
However, sometimes using a third-party plugin or an external SMTP service is just not possible due to various restrictions or policies you or your company might have. Luckily, there’s another way to fix the email issue. It’s a bit more technical, however, it gets the job done.
Think that this is a bit too much? We can take over the technical hassle of managing your website and make sure your WordPress emails always reach the destination! Checkout out our website maintenance plans or drop us a line through our contact form. Feeling extra confident? Then the next part is definitely for you.
The “expert” approach
First of all, we need to understand the root cause of the problem. How are emails being sent in WordPress and why do they end up blocked or in spam folder? Let’s look at a quick visual representation of a typical email flow after you click on the “Send” button.
After an email is sent out from the sender (the sender can be either a person or a site component — contact form, order confirmation, etc), it is handed off to the SMTP server, where the website is hosted, let’s call this the “Outbound mail server”. The outbound mail server then forwards the email through the internet to the recipients “Inbound mail server”.
However, it’s not a straightforward process. When the email is sent out, the email headers will get parsed, and the
Return-Path header is extracted from the email, which is used to determine if the server from
Return-Path header is even able to send out emails. This is often the culprit, where majority of emails will get flagged as spam and either will get dropped or directed to the recipients spam folder. But to the rescue come SPF, DKIM and DMARC.
The Sender Policy Framework, or commonly known as SPF is a standard email authentication method. SPF helps protect your domain against spoofing (forged sender addresses), a technique often used in phishing and email spam, and helps prevent your outgoing messages from being marked as spam by receiving servers. SPF specifies the mail servers that are allowed to send email for your domain. SPF settings are controlled via
TXT records in DNS, and a typical entry would look something like this:
example.com. IN TXT "v=spf1 a mx -all"
In most cases, you won’t need to worry about creating DNS records directly on your server, and the domain provider will have a UI for managing the fields. What the above means is that the domain
example.com has a
TXT record with a value of everything between the brackets:
v=spf1 — Is the SPF version.
a — Indicates that if there’s an
A record for the senders email domain, than that address will be used for validation, and if the
Return-Path address, we talked about above, matches the value of the
A record, the SPF check will pass.
mx — Same as above, but validation is done against the
MX DNS record.
-all — This flag tells the server that addresses not listed in the SPF record are not authorized to send emails and should be rejected. Some prefer to use the
~all flag, which, instead of rejecting, will add a special tag to the email, saying that it is potential spam.
One of the most common issues with SPF is that sites will have multiple
TXT records for SPF. In this case, the server might not use the correct rule and a perfectly valid email might get rejected. So make sure to group all the rules inside a single entry.
For example, a typical Microsoft Office 365
TXT entry for SPF might look something like this:
example.com. IN TXT "v=spf1 a mx include:spf.protection.outlook.com -all"
The DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The
Similar to SPF, DKIM is set up through DNS records. The validation process is almost the same as well, but instead of checking the sender domain through DNS, the recipient system will look up the sender’s public key published in the DNS, which would be used to verify the email integrity. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed.
In other words, the outbound mail server will encrypt the email headers and send it forward to the inbound mail server, which will try to check the integrity of the message, using the public key from DNS. An important thing to remember — this is not full email body encryption, only the header of the email is encrypted.
If we have a look at an example from a Microsoft Office 365 configuration, we need to add two
CNAME entries to our DNS:
selector1._domainkey.example.com. 3600 IN CNAME selector1-example-org._domainkey.example.onmicrosoft.com selector2._domainkey.example.com. 3600 IN CNAME selector2-example-org._domainkey.example.onmicrosoft.com
The bold part is the
initialDomain, which you are assigned when registering for an Office 365 account. After publishing the
CNAME records, you’ll need to activate DKIM in the Microsoft Office 365 administration panel in
Administration - Exchange - Security - DKIM. If you’ve opted in for a Sendinblue integration, you will be provided with the required DNS entries after setting up a domain in the
Senders and IPs section of the control panel.
Ok, you’ve set up all of the above, but your emails still get flagged as spam! Why? While SPF and DKIM are really good preventative measures, unfortunately, they are not a 100% guarantee that the inbound mail server will be able to verify the sender. Look at these as instruments to help improve the decision making process on the recipient side. However, not all is lost – we still have DMARC.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from… you guessed it right — spoofing.
Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication, it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected.
For example, one email forwarding service delivers the mail, but as “From: [email protected]”. DMARC extends two existing email authentication mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the
From field presented to end users; how the receiver should deal with failures — and a reporting mechanism for actions performed under those policies.
A DNS entry for DMARC will look something like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:<email for reports>; sp=none; aspf=r;"
v=DMARC1 DMARC version.
p=none — Indicates what to do with emails. In this case — do nothing. Use this value only for setting up DMARC. The two other common values are to
pct=100 What percentage of emails to reject or quarantine. When setting
p=quarantine, it’s better to start with lower values, something like
pct=10, and gradually increase the value as you gain confidence that there are no false positives.
rua=mailto:<email for reports> Where to send reports.
Email providers that support DMARC will send out XML reports to the email specified in the
rua= value. The report will contain an IP-address of the sender and the status of SPF/DKIM checks. However, XML formats are not always easy to digest, so it might be a good idea to use a third-party service to generate reports, something like Postmark.
Emails are an important part of any business. There are multiple ways of making sure your users and clients get the intended correspondence. The best way to avoid loosing revenue because of an undelivered or blocked email – be proactive and always check your site before launch, make sure you have setup everything on your DNS and there’s a reliable SMTP provider that you can trust to delivery your mail.
If you’d like to find out more about SPF, DKIM and DMARC, a great article with a lot of details can be found on postmarkapp.com.
There’s also a few resources to help you test your setup. You can use a site like mail-tester.com or by sending a test email to [email protected].