10to8 sends many thousands of emails per day, most of which are delivered successfully.


However, there are cases where emails do not arrive in the inbox of the recipient, in particular corporate environments with enterprise IT.


This guide outlines what 10to8 does to ensure email delivery, and how we can work with your enterprise IT to ensure delivery.


TABLE OF CONTENTS


AWS Simple Email Service (SES)

We use Amazon's SES with AWS to deliver all of our emails. Many of our emails come from IP addresses managed by AWS. AWS has the following IP address ranges:


  • 199.255.192.0/22
  • 199.127.232.0/22
  • 54.240.0.0/18
  • 69.169.224.0/20
  • 76.223.176.0/24
  • 76.223.180.0/23
  • 76.223.188.0/24
  • 76.223.189.0/24
  • 76.223.190.0/24


We also use dedicated IP addresses for many of our emails:


  • 23.249.217.229
  • 23.249.217.230
  • 23.249.221.54
  • 23.249.221.55
  • 23.249.221.56
  • 23.249.221.57
  • 23.249.221.58
  • 23.249.221.59


Please note that these IP addresses are subject to change, and that SPF makes IP address filtering redundant so we strongly recommend against IP filtering.


All 10to8's emails are delivered from addresses with this format:


reply-aXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX@comms.10to8.com


The long code uniques identifies the message.


SPF

SPF is an email standard designed to prevent email spoofing by allowing domains to announce which IP addresses are allowed to send emails for that domain. This announcement is done with a DNS TXT record, so uses the authority of the DNS system. A bad actor, attempting to send emails faked as coming from the 10to8 domain, would fail since their emails would not originate from an IP address approved by 10to8, and recipient email systems could then reject the email.


All modern email systems support SPF verification. SPF is defined in rfc7208.


When one system receives an email from another server, claiming to be for a particular domain, the receiving system can query the DNS TXT records for the domain, read the SPF details and verify the sending server is permitted to send that email.


10to8 has SPF DNS TXT entries for all outbound email. Our set up differs from the default AWS SES SPF configuration, so that we can support DMARC.


DKIM

DKIM is an email authentication system designed to prevent email spoofing by allowing domains to publish encryption keys that can be used to verify an email is from the person it claims to be from. These encryption keys are public, and are shared as TXT records in the DNS system. A bad actor, attempting to send phishing emails, would fail this test because they would not be able to generate a valid digital signature for the email.


All modern email systems support DKIM verification. DKIM is defined in rfc6376.


When a system receives an email, the email will contain a digital signature in the DKIM header. The receiving system then queries the sending domain's TXT records to find the public key against which the digital signature is verified.


10to8 uses DKIM verification, with AWS's SES standard configuration.


For more information on SPF and DKIM, check out this blog article: https://www.sparkpost.com/blog/understanding-spf-and-dkim/


DMARC

DMARC is a mechanism for domains to set policies and reporting on email deliveries. This means that recipient email systems send daily reports back to 10to8 about emails that they have received, apparently from 10to8.com, so that 10to8 can monitor attempted fraudulent behavior by had actors. As with SPF and DKIM, these are configured with a DNS TXT entry. Using these policies, a domain such as 10to8.com can specify:

  1. What should happen to emails that fail SPF and DKIM tests - 10to8 requests a report
  2. What email address should reports on failures and deliveries be sent to

DMARC is less widely supported than SPF and DKIM, but is still a vital tool in identifying delivery issues.


10to8 fully supports DMARC. Our DMARC feedback email address is dmarc@10to8.com. We monitor these reports to identify email delivery issues early.


Troubleshooting

While 10to8 makes every effort to guarantee delivery, there can still be problems, especially with email servers that predate modern anti-spam techniques. Several things that your IT team might be able to check are:


  1. Do you use SPF and DKIM for verifying inbound emails?
  2. Does your system report and errors regarding SPF and DKIM?
  3. Do you have auto-forwarding set up on inbound emails? We have seen cases where forwarding an email damaged the DKIM cryptographic signature.
  4. Does your system support DMARC delivery reporting? If so, it is possible that your system could report back to us automatically when there are delivery issues, reducing the complexity of fixing the problem.