Sign In Scheduling sends thousands of email messages every day. Most emails sent from Sign In Scheduling are delivered successfully. Delivery issues may be more common in corporate environments with enterprise IT.
This guide outlines Sign In Scheduling's email delivery process and provides troubleshooting steps for your IT team.
SECTIONS:
AWS Simple Email Service (SES)
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, which have the following 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
Note: these IP addresses are subject to change. SPF makes IP address filtering redundant, so we strongly advise against it.
All of Sign In Scheduling's emails are delivered from reply@comms.10to8.com.
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 fraudulent emails from what looks like the Sign In Scheduling domain, would fail. These emails would not originate from an IP address approved by Sign In Scheduling, so 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 from 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.
Sign In Scheduling has SPF DNS TXT entries for all outbound emails. Our setup 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 that 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.
Sign In Scheduling uses DKIM verification, with AWS's SES standard configuration.
You can read more about SPF and DKIM here.
DMARC
DMARC is a mechanism for domains to set policies and report on email deliveries. This means that recipient email systems send daily reports back to Sign In Scheduling about emails that they have received, apparently from 10to8.com, so that Sign In Scheduling can monitor attempted fraudulent behavior by bad 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 - Sign In Scheduling requests a report.
2) Which email address reports on failures and deliveries should be sent to.
DMARC isn't as widely supported as SPF and DKIM, but is still a vital tool in identifying delivery issues.
Sign In Scheduling fully supports DMARC. Our DMARC feedback email address is dmarc@10to8.com. We monitor these reports to identify email delivery issues early on.
Things to check
While Sign In Scheduling 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 on errors regarding SPF and DKIM?
3) Do you have auto-forwarding set up for 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.
Need more help?
We hope this guide has been useful! If you need further help, reach out to our support team who will be happy to assist.