In a previous post, we covered some high level details of our new SMTP service that acts as a bridge between SMTP clients and our transactional (RESTful) email API.
In this post, we’ll go over some of the implementation details of the SMTP service and how its architectural design provides benefits people have come to expect from highly reliable and secure web services and protocols.
See Also: HIPAA Compliant Email: The Definitive Guide
At a high level, email is essentially a queueing system. After a client connects to an email server and hands off their message, the server puts that message in a queue and moves on to processing requests from other clients while another background process figures out the best and most secure way of delivering it to its intended recipients.
Our SMTP-to-API bridge is built with the same queueing design considerations, except instead of connecting directly to another email server, it connects to our REST API. Just like with other email servers, our service is designed with reliability in mind so that it functions correctly even if there are problems with the network or other services.
If an email is accepted and passes all the necessary validations, then you can be sure that it will be delivered to its intended recipients.
The first thing that happens when a client connects to our SMTP service is the establishment of a secure communication channel. After establishing the secure channel, the clients are then required to authenticate with an API key associated with a validated domain.
This is because as part of a trusted and distributed network of email providers, we want to maintain trust and security of the network to make sure legitimate (non-spam) emails continue to be delivered to their intended recipients. Spam scores will often take into account the status of the originating server for the message and at Paubox, we strive to make sure our servers are highly trusted by all the major email providers (e.g. Google, Microsoft, Yahoo, etc).
This is why we require authentication and validated domains, mainly because we want to prevent spammers from gaining a foothold and clogging up the network with spam.
So if you have a validated domain with properly configured SPF and DKIM records, you can be sure that your emails will not be marked as spam by other email providers and your intended recipients will see the messages you send in their inbox (instead of the spam folder). After an email is accepted by our server, it's placed in a queue (just like other email servers) and then handed off to the REST API by another background process for its final delivery to its intended recipients.
It is possible network failures and other issues can prevent this hand off and in such cases, the message is placed back into the queue to be resent at a later date. This means that if an email is accepted by our SMTP service, you can be sure that short of a catastrophic failure (e.g. a flood or fire at a data center), that message will be delivered to its intended recipients.
If you have any questions please reach out and let us know. We are always looking for ways to make our services more useful for our customers, so we are always happy to receive feedback and suggestions for improvements.