Experiencing delays? Check our Status Page for the current state of all SendGrid Services.
As you send emails, you may encounter scenarios where mail seems to take more time than it should to get to its final destination. Mail delays can manifest in a number of ways, so we've collected a list of tips to help you try to track them down!
1. If you are integrated with SendGrid using code, we highly recommend using the official SendGrid libraries available on our GitHub account. These are written with efficiency in mind. If you need help getting started with our libraries, check out the tutorials in each of the languages:
2. You can use our SMTPAPI to greatly increase your message throughput. As with SMTP, 5000 messages can be sent with each connection, but there can be 1000 TO: recipients for each message using the x-smtpapi header. You can use this option through SMTP sending as well as the Web API v3.
3. Lastly, you can try to open additional connections from your end: Generally, we recommend a maximum of 10 concurrent connections. However, please note that SendGrid can generally handle as much mail as you can throw at us. One thing to ensure is to make certain that the maximum amount of mail is passed before terminating each connection. We recommend using caution when incrementing your number of active connections.
More often that not, one of the 3 suggestions above will resolve a latency problem. However, some latency issues are simply due to the quality of your connection or traffic shaping. There is always the possibility that network problem issue lies with either yours or your ISPs configuration. Below are a number of methods that will help you determine where a latency issue really is.
How to run hping: Open “terminal”. Type “sudo hping smtp.sendgrid.net -p 587 -S” and you will see a ping occur continually.
sudo hping smtp.sendgrid.net -p 587 -S Password: HPING smtp.sendgrid.net (gpd0 22.214.171.124): S set, 40 headers + 0 data bytes len=44 ip=126.96.36.199 ttl=49 DF id=0 sport=587 flags=SA seq=0 win=29200 rtt=40.5 ms len=44 ip=188.8.131.52 ttl=49 DF id=0 sport=587 flags=SA seq=1 win=29200 rtt=40.5 ms len=44 ip=184.108.40.206 ttl=49 DF id=0 sport=587 flags=SA seq=2 win=29200 rtt=45.7 ms len=44 ip=220.127.116.11 ttl=49 DF id=0 sport=587 flags=SA seq=3 win=29200 rtt=42.8 ms len=44 ip=18.104.22.168 ttl=49 DF id=0 sport=587 flags=SA seq=4 win=29200 rtt=47.2 ms len=44 ip=22.214.171.124 ttl=49 DF id=0 sport=587 flags=SA seq=5 win=29200 rtt=51.8 ms len=44 ip=126.96.36.199 ttl=49 DF id=0 sport=587 flags=SA seq=6 win=29200 rtt=42.4 ms len=44 ip=188.8.131.52 ttl=49 DF id=0 sport=587 flags=SA seq=7 win=29200 rtt=45.2 ms ^C --- smtp.sendgrid.net hping statistic --- 8 packets tramitted, 8 packets received, 0% packet loss round-trip min/avg/max = 40.5/44.5/51.8 ms
Anything exceeding 150.000 ms should be the first indication that something may be amiss regarding your network connection. Let your IT department know pronto.
Hping - traceroute mode
How to run a traceroute: Open “terminal” and type “sudo hping smtp.sendgrid.net -p 587 -S -T -c 10”
sudo hping smtp.sendgrid.net -p 587 -S -T -c 10 HPING smtp.sendgrid.net (en0 184.108.40.206): S set, 40 headers + 0 data bytess hop=1 TTL 0 during transit from ip=172.22.16.1 name=UNKNOWN hop=1 hoprtt=2.8 ms hop=2 TTL 0 during transit from ip=220.127.116.11 name=UNKNOWN hop=2 hoprtt=15.9 ms hop=3 TTL 0 during transit from ip=18.104.22.168 name=ae-1-3501.ear3.sanjose1.level3.net hop=3 hoprtt=28.0 ms hop=4 TTL 0 during transit from ip=22.214.171.124 name=UNKNOWN hop=4 hoprtt=25.9 ms hop=5 TTL 0 during transit from ip=126.96.36.199 name=ae6.cbs02.eq01.sjc02.networklayer.com hop=5 hoprtt=25.2 ms
As with the hping method, keep an eye out for any large times over 150.000 ms. You'll also want to pay close attention to notice if there are any major increases from one hop to the next. This could indicate the inherent latency from when the packet leaves a server in France en route to a server in Canada. Another flag to watch out for are any of the increases early in the transit, as this could mean the latency lies within your local network, or at a certain ISP.
Keep in mind that many modern network nodes will de-prioritize ICMP packets, which traceroute sends, so timeouts at certain hops may not necessarily be indicative of a faulty connection. That said, a traceroute can still go along way in helping isolate where a network issue exists.
Google Header Analyzer
Google provides a great free header analyzer tool that you can use to analyze the headers of an email, and find out how long an email spent in a particular location. For more information on how to grab the original headers from an email, check here.
The results provided should show the exact journey a message takes from one Mail Transfer Agent to the next, and how long it spent at each one! This tool can be invaluable for figuring out who to "blame" for email delays.
Support may ask you for a PCAP sometimes during issue troubleshooting, here is an excellent guide on how to perform the capture and begin using Wireshark here. Make sure that you capture when attempting to send a single message to SMTP.sendgrid.net. Once we receive the PCAP file from the you, we can open it up in Wireshark on our side. The steps below are the same step[s we would take to analyze such a file, so feel free to follow along!
Let us know how we’re doing! Please rate this page:
Please note, we cannot resolve account and login issues reported on GitHub. Contact support for account assistance.
Thanks for helping us improve our docs!