Email deliverability.
Email deliverability. In this post I’ll be talking about what email deliverability is, why it’s important for you, what affects email deliverability and improve your email deliverability.
What is email deliverability?
Email deliverability is essentially the probability of an email you send being received by the intended recipient.
Although a lot of people think of emails as an electronic version of post or mail (and you can’t really blame people for thinking this given that the word email itself is an abbreviation of electronic mail). You send an email, it goes and someone receives it.
Unfortunately it doesn’t quite work like this. Why not? Spam. Because of spam.
About half of all email traffic on the internet is spam. Nobody really wants to receive spam. If all emails that are sent were delivered, we’d get about the same amount of spam emails that we do legitimate emails.
Mail providers are always trying to reduce the amount of spam that’s received. Whilst it may be easy for you or I to look at an email and know it’s spam, computers don’t have any intuition like humans. they have to be programmed to do everything. As you can’t really program intuition, mail providers have to come up with “rules”, anti spam methodologies, and anti spam logic.
The anti spam methodologies that are used aren’t entirely foolproof, so legitimate emails can sometimes be classed as spam by recipient providers, and be routed to recipient’s spam folders in their mailboxes, or possibly even completely rejected.
Due to this when you send an email, there’s a chance it will be received, but also a chance it won’t.
Improving your email deliverability increases the probability of emails being received by intended recipients.
why email deliverability is important to you.
As I’ve mentioned above, when you send an email there’s a chance of it being received by the intended recipient. Due to this there’s no guarantee that the email you send will be received.
Email deliverability is important to you, as it increases the chance of your email being received by the person you’ve sent it to.
Have you ever sent an email, not got a reply, then queried this with the recipient only to be told your email was in their spam folder? Frustrating isn’t it?
Improving your email deliverability reduces the chance of the emails you send ending up in spam folders in recipient’s mailboxes.
What affects email deliverability.
Generally speaking there are two factors that affect email deliverability.
One is the content of the email being sent.
The other is the authenticity of the email being sent.
There are commonly available technologies available that can be used to make your emails appear more authentic to recipient providers, such as SPF and DKIM records (I’ll go in to more depth about these in a moment).
When an email is received by a recipient provider, its content and authenticity are checked. What’s found when these checks are undertaken often results in a “score” being assigned to an email. The greater the score the more chance the email has of being routed to junk or spam folders, or perhaps being completely rejected.
What causes the score to increase is the email having multiple spam like qualities.
Email contains a link. Have a point.
Email only contains a small amount of text. Have a point.
Email mentions the word “invoice”. Have a point.
Enough points, and your email will exceed a spam score threshold, and be junked or maybe even rejected.
The best way to consider your email’s content is to think of what spam looks like, then compose your emails so that they don’t look similar to spam. Some good practices to apply to your email’s content would be:
- Use HTML format (spam is often plain text, or rich text)
- Don’t include lots of links in your emails (a lot of spam has small amounts of text and numerous links). Containing links to every single one of your social media profiles in your signature, then sending a one line email (plus signature) is going to look spam like.
- Send a reasonable amount of text, not just one line.
- Make sure you put something in the subject line.
- Don’t attach files that have been historically used to spread malicious content (such as .eml files).
- If you attach an invoice, don’t use the word invoice in the attachment’s file name.
- Don’t use spam like subjects (lots of exclamation marks, or all capitalised text in the subject line, for example).
- Don’t actually be a dictator trying to get a lot of money out of a country with the help of a stranger, and making the respective arrangements via email.
Recently some major mail providers have started rejecting emails if there’s no SPF or DKIM record in place for the domain (the part of the email address after the @sign) of the from address. These rejections usually look something like this (the key word here is “unauthenticated”):
550 5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked. The sender must authenticate with at least one of SPF or DKIM. For this message, DKIM checks did not pass and SPF check.
Consequently having no SPF or DKIM record in place for the domain you’re sending from will decrease the chance of your email being received, in some cases (depending on the recipient provider) to none.
How to improve your email deliverability.
To improve your email deliverability:
Send from an email address that actually exists.
This causes sender verification to succeed. Sender verification is a check that a recipient mail server carries out on the transmitting mail server (effectively “do you hold this address?”). Although sender verification is a little old, and not all mail providers undertake this check, there are still some that do. You might wonder why someone would not do this (why would you send from an address that doesn’t exist as a mailbox?), but in the context of a contact from on a website, just making up a from address (or specifying a from address that doesn’t exist) would cause sender verification to fail.
Deploy an SPF record.
I’ll cover how you actually do this in a moment. SPF records are deployed as DNS TXT records. What they define is where emails for the domain of a from address should originate from (this mitigates from address spoofing). When a recipient server that’s configured to undertake SPF checks receives an email it:
- Checks the from address of the received email.
- Looks up the SPF record of the domain of the from address.
- Checks the email has come from a source defined in the SPF record.
SPF records define where emails for a domain should originate from. An SPF record might look like this:
v=spf1 ip4:185.229.21.109 +a +mx -all
For example’s sake, let’s say the from address of the email is hello@example.com, and so the domain is therefore example.com, and the SPF record above is what’s been deployed for example.com. In this context the SPF record above means:
v=spf1 means “this is an SPF version one record”.
ip4:185.229.21.109 means “Emails with @example.com from addresses can come from a server with an address of 185.229.21.109”.
+a means “Emails with @example.com from addresses can come from the same place that the example.com domain’s A record (usually where the website is held) points or resolves to”.
+mx means “Emails with @example.com from addresses can come from the same place that the example.com’s domain’s MX record (usually where @exmaple.com mailboxes are held) points or resolves to”.
-all means “hard fail (reject) emails that don’t conform to this SPF record”. An alternative to -all would be ~all which means “soft fail (warn about) emails that don’t conform to this SPF record”.
Deploy a DKIM record.
DKIM (DomainKeys Identified Mail) is a little like SPF in the sense that it validates where emails have come from as a valid source but it does this in a different way. DKIM also validates the original content of emails.
Again DKIM records are deployed as DNS TXT records and they look like this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0di5RPOmvEYjkJfH88zTeSeUVFOyFq9vCJqEtZpXbwsHsKw2i3pH4ZcneM/d2NS3Ji2vSPND7KLw9lfCPG84fR2DRRyfaNJm8u+bVEQ2NF5+c+lQ6y7Yh/hoZUW56i83RRlK7TnRb+PHif6yfr3JQQ94dmnqw3JX+VuvrgNRhpukPSUN5Iin/eUmlNgOI/+e0UooMrg++yYCaGF1cNTQHN/iy/OxYVP/bKbCWGJw/DqaOvOAX6VsQ/dKUmT4m5TLRrJQ/clmoMkQbG33uGd9Ofk0lkxl7CWdADro8Kv7NoG19i5Mq0DjwitusGsRVMRakeHCWnyNLBZ6HwRuWvZdtwIDAQAB;
What this is, is a DKIM key.
With DKIM there are two keys, on is the public key (which is the one publicly advertised as a DNS TXT record) and the other is a private key which is held on the transmitting mail server.
When an email is sent from the transmitting mail server the private key is used to “sign” the email (This signature includes information about the email, such as the sender’s domain, the recipient, and the email’s content).
When the recipient server receives the email, it looks up the public key for the domain (based on the from address of the email), and uses this to decrypt the DKIM “signature” on the email.
If the signature is valid and matches the email’s content, the receiving mail server can be confident that the email was not altered during transit and that it genuinely came from the domain found in the from address.
Deploy a DMARC record.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is another type of DNS TXT record. What a DMARC record does is define a policy for what should SPF and DKIM checks fail when emails are received.
There are multiple parts to a DMARC record, which are effectively:
What should be done if DKIM and / or SPF checks fail?
- none – No action should be taken, just report for analysis
- quarantine – Route the email to junk or spam folders
- reject – Reject the received email
If reports should be based on individual failures or if they should be forensic (more information).
If failure reports should be generated, and for which failure (DKIM or SPF or both).
Who should be told if DKIM and / or SPF checks fail, which is usually an email address of the domain’s administrator.
If the policy applies to just the domain or to subdomains as well.
The percentage of emails DMARC should be applied to.
A DMARC record might look like this:
v=DMARC1; p=quarantine; rua=mailto:administrator@example.com; ruf=mailto:administrator@example.com; fo=1; adkim=s; aspf=s;
Which means:
v=DMARC1 = This is a DMARC version 1 record
p=quarantine = Quarantine messages that fail the defined checks
rua=mailto:administrator@example.com = Send DMARC reports to administrator@example.com
ruf=mailto:administrator@example.com = Send DMARC forensic reports to administrator@example.com
fo=1 = Generate reports for all failed messages, both SPF and DKIM.
adkim=s = The domain value in the DKIM signature must match the From header domain.
aspf=s = The “mail from” domain in the SPF check must match the From header domain.
There are a variety of DMARC generators that can be used to define your DMARC policy by answering step by step questions.
And if you’re mass (or bulk) mailing…
If you’re sending large volumes of emails, you need to consider that recipient providers scrutinise a large volume of emails that come from one source to a greater degree than a human like volume of emails. This is simply because spam tends to be sent in large batches. Sending a large amount of emails in one go, in an automated manner does look quite spammy.
Recipient providers don’t tend to explicitly state how large email volumes are analysed (doing so would be a bit like giving spammers tips on how to negate anti spam mechanisms), and methodology varies between providers. They do, however provide “bulk sender guidelines” which are guidelines you’d need to adhere to for bulk emails to be received by the intended recipients. You can find these here:
Microsoft (which covers hotmail, outlook.com, live, MSN, and office365 based recipients).
Google (which covers GMail, googlemail, and google workspaces based recipients).
Yahoo (which covers yahoo, AOL, sky, btintnernet, btconnect and ymail).
Be VERY careful with bulk mailing, as these providers blacklist parties believed to be spamming (yes, you can get blacklisted for sending a poorly conceived mailshot) and being delisted can be tricky. If you do get blacklisted by a provider, all mail from your domain will be rejected by the provider. Consequently, you could send a badly set up mailshot, then find that you can’t email anyone with a hotmail, outlook.com, live, MSN, or office365 based address. Not much fun.
How to Deploy DKIM and SPF records.
If you’re using cPanel, and your domain is using your hosting provider’s nameservers AND your site and mailboxes are all held in the same hosting account, deplying DKIM and SPF records is really easy. You just log in to your cPanel, then click on “Email deliverability”:
Then, on the same line as your domain, click “Repair”:
You’ll then be show the records that will be installed, and also come cautionary warnings, which I’ll come to in a moment, but if your mailboxes are held in your cPanel, and you’re using your hosting provider’s nameservers, you can just click “Repair”:
Then you simply wait for the records to be installed and then you’ll see this (confirmation that you have valid DKIM and SPF records):
But what if you’re not using your mail providers nameservers, or your site is held on one server and your emails/mailboxes with another party? What then?
Think of it like this:
The nameservers dictate where you put the SPF and DKIM records (i.e. in the respective DNS zone manager).
Where your mail is held dictates part of the SPF record and one of he DKIM records.
If your site generates emails (such as contact form emails, subscriber notifications, or purchase receipts), this needs to be taken in to account, so where your site is held dictates another part of the SPF record and another DKIM record.
You’d have to obtain or find out the required DKIM and SPF records from the party that hosts your site and your mailboxes, then deploy these in the zone manager where DNS is administered for your domain.
That’s the reason for the warning messages in cPanel. If you deploy SPF and DKIM records incorrectly either it won’t do anything, or it could make recipient servers start rejecting all of your emails.
Hosting providers don’t always know how customers will operate when they sign up for a hosting account. It’s for this reason that SPF and DKIM records aren’t deployed by default.
Generally speaking, obtaining the SPF and DKIM records from your site hosting and mail hosting providers will tell you what the records are (or at least work them out), and then it’s just a case of adding these records in the zone manager that’s used to administer the DNS zone for your domain (this will add the record to the DNS zone for your domain that’s held on the nameservers set against your domain).
in conclusion.
- Email deliverability is important as it affects the chance of your emails being received successfully.
- Both validation / authentication records and the content of emails affects email deliverability.
- Recipient providers check and score emails based on validation records and content.
- Emails with high spam scores get routed to junk or spam folders or rejected.
- Email deliverability can be improved using SPF, DKIM and DMARC records, and by sending from a valid email address.
- DKIM and SPF records can be easily deployed when using cPanel.
- DKIM, SPF and DMARC records are all deployed as DNS TXT records.
- DKIM and SPF records can be obtained from web and mail hosting providers if you can’t find them out, or don’t know what they are.
- You need to take your site in to account when deploying SPF and DKIM records if your site generates any emails.