Click processes millions of emails each day, sending them to recipients all around the world. For the vast majority of these emails, the time from someone clicking "Send" to the time it lands in the recipient's inbox is often a matter of seconds or minutes. Sometimes, though, an email doesn't get to someone's inbox when you might expect it to. And other times, the email makes it to the recipient very quickly, but you don't see a record of that in your environment. So let's take a look at what can make it seem like an email is taking longer than expected.
How deliveries are recorded:
There are two relevant times recorded on an Email Event record when considering this question: The "Created On" field, which is shown in a column of the Email Events view, and the "Time" field, which is shown on the Email Event form.
What can delay deliveries?
(Symptom: The UTC timestamp is many hours after you clicked “Send”.)
-
Rate limiting. When an email marketing service sends a bulk email, each ISP (Internet Service Provider) accepts messages at a different rate. For example, Yahoo might accept 100 emails per connection and allow 1 connection per minute. Outlook.com might permit 1 email per connection, but allow 1 connection per second. It varies for every ISP, and in many cases is closely guarded by the ISPs. (For more information on rate limiting, see the section “Delivery and Filtering Details” on this page: https://wordtothewise.com/isp-information/)
-
ISP problems. This can be a variety of factors, such as bandwidth at the ISP or recipient mail server, temporary DNS issues, heavy internet traffic in the region, etc. When Click sends bulk emails, it creates and sends the messages very rapidly. If a message is not immediately accepted by the recipient ISP, but is not yet bounced, Click will automatically retry every 15 minutes for up to 24 hours to get a delivery acknowledgment from the ISP before giving up. This is why if you send 10,000 emails, you will likely see a very large cluster of delivery events in the first 30 minutes, with additional delivery events hours or even 1 day later. This might make you think that it took that long for Click to send your emails, but in fact, it had been processed and sent very quickly with just a few stragglers waiting for the ISPs to accept the emails.
-
Processing issue on Click. If there is an unexpected problem on Click that causes it to take a long time to process the email job and begin creating the individual emails. If this happens, you would likely not see any indication of even a single delivery until the issue is resolved, at which time you might see all the deliveries process at once.
-
Performance issue or connectivity problem with customer’s environment. If Dynamics does not respond quickly to the queries we make for the email addresses, unsubscribe records, etc., then we will not be able to process the job quickly either.
What can delay recording the delivery in Dynamics as an Email Event?
(Symptom: The UTC timestamp on the Email Event shows a quick delivery, but the “Created On” date/time is many hours later.)
-
Processing issue on Click. Once an ISP acknowledges delivery, usually within microseconds of the email being sent, Click queues up that record and formats it in a way Dynamics will understand. If the queue that this piece of data ends up in happens to have a technical problem, or there is a broader systems issue with Click or Microsoft Azure, you may not see the Email Event record created in your environment until the issue is resolved.
-
Performance or connectivity problem with customer’s environment. If the Dynamics system is not able to accept the data that we are pushing to it, whether due to performance issues or connectivity, Click will retry once an hour for up to 1 week until the data is synced.
- Email Event Throttling. Click throttles the rate at which we sync email events back to the customer's environment in order to avoid affecting the Dynamics' system performance. If the Email Send went out to a large list and generated a high volume of email events, a deliver email event's Created On time stamp may list a time later than the time that the delivery was recorded because it took some time for all the email events to be synced into Dynamics.