We’ve delivered more than 2 billion emails

July 19th, 2010

TechCrunch says we have delivered a Bajillion emails … close … actually, we have now delivered more than 2 Billion emails!

This has all been made possible by the 8,000+ awesome companies that have used our service and by putting together a phenomenal team. In the last few months we went from a team of 5, to a team of 18 and growing (we are hiring).

Our engineering team has adopted an awesome development process to produce higher quality software, with key feedback from companies like TwilioGetSatisfactionGnip, and SimpleGeo. Thanks guys! Meanwhile, our support team keeps rocking, they even help debug code on a Saturday night!

In addition to growing our team and enhancing our systems & processes, we have been expanding our feature set, mostly thanks to some great suggestions from our growing community. Friday was a particularly exciting day for us, just as we broke a milestone of achieving over 20 Million emails processed in a single day, we released the following features:

Read the rest of this entry »

Which protocol should I use to send email, SMTP or REST?

June 21st, 2010
We get asked quite often why we recommend customers use SMTP to send email to SendGrid, as opposed to using our REST API, and where one would be used over the other.  For options on how to integrate with SendGrid go here.


To start, the absolute best method to send email through SendGrid is to set up a local mail server that queues all email from your application, and then relays the messages through SendGrid as a smart host.  This will have the least latency from your application’s perspective, and has the added benefit of handing your email off to a server that is fault tolerant.  If something goes wrong with internet connectivity between your servers and ours, a local mail server can gracefully handle queuing and resending the email, as opposed to having to build that intelligence into your sending application.  Local mail servers also have advantages at high volume of being able to use some of the more complex parts of the SMTP protocol, such as connection reuse and pipelining.  With these techniques a mail server will be able to send significantly more traffic in a given time than if you have individual scripts making connections for each message.


That being said, many people want to use SendGrid for the purpose of getting away from the need to have a local mail server.  At that point, SendGrid’s recommendation to use SMTP is based on the large number of libraries and documentation available to integrate using it. SendGrid is a big believer in open standards, and for sending email SMTP is the standard. All that being said, there are some cases where the REST API has some advantages.  These include
  1. If your ISP is blocking all output mail ports, the REST API could be your only option
  2. If there is extremely high latency between your site and ours, the REST API can be quicker since it does not require as many client <-> server message / response interactions.
  3. If you do not control the environment that your application runs in, and it is difficult to install / configure an SMTP library


I hope this has helped to clarify some of the technology based reasons we have for recommending the usage of SMTP compared to the REST API. In the end, the final choice of what to use should be based on what works best for your company.

Ready to make a difference? SendGrid is hiring!

February 15th, 2010

SendGrid is a cloud based service that delivers emails on behalf of companies to increase their email deliverability.  We have also developed a platform that solves many of the current email problems and flexible enough for other companies to plug in functionality to solve future problems.  SendGrid has been growing really fast after launch and we want you to be part of the awesome company we are building.  We are looking for talented engineers that can help us innovate the email space and make a huge difference.

Senior Web Applications Engineer

SendGrid is looking for a senior backend engineer that can help us manage and innovate our web applications.

Responsibilities:

  • Manage a team of web developers and be responsible for getting applications released on time
  • Design scalable and fast web applications
  • Work closely with designer to develop great UX/UI applications
  • Work closely with infrastructure engineer to make sure web applications scale on demand
  • Implement backend and frontend web applications in Symfony/PHP to automate tasks and to better present data to users

Qualifications

  • Experience managing a team of remote developers
  • Experience with management tools such as Basecamp or Pivotal Tracker
  • Experience with Symfony, YUI, and test-driven development
  • Familiar with UX design
  • Plus if familiar with Hadoop and Perl
  • Telecommuting will be considered for the right candidate

Senior Backend Engineer

SendGrid is looking for a senior engineer that wants to be part of the team that develops the fastest and most scalable cloud-based email platform in the world.  If you know what a context switch is and the difference between epoll() vs select() we want to talk to you.

Responsibilities:

  • Profile and benchmark OS and applications to find and improve bottlenecks
  • Implement distributed applications that can scale to millions of emails per day
  • Implement applications to provide better tools and insight on email delivery
  • Work closely with web developers to develop great user tools
  • Enjoy supporting users on technical issues as they are our biggest asset

Qualifications

  • Fluent in Perl, Python, and C
  • Linux systems administration experience
  • Experience developing large scale and mission critical applications
  • Familiar with spam filters
  • Familiar with an asynchronous programming frameworks such as AnyEvent, POE, or Twisted
  • Plus if familiar with Hadoop and statistical analysis
  • Telecommuting will be considered for the right candidate

Please emails us your resume at jobs@sendgrid.com and be part of a great team.

Why you should not use noreply@domain.com in your emails

February 8th, 2010

When we were designing our SendGrid platform, we tried to solve most of the existing email problems and make an extensible platform where other companies could add functionality and solve future problems. One of the current problems is taking incoming replies from emails. We noticed many companies sending automated or transactional emails to their users using a From email address in the form of noreply@domain.com. This creates two huge missed opportunities that SendGrid users can now easily take advantage of by using our parse API.

The first missed opportunity is communicating with users.  Companies such as Posterous, WordPress, Intense Debate, and Facebook have taken advantage of the wide adoption of email to develop great applications.  WordPress and Posterous allow users to write and publish a blog post by just sending an email.  In the same manner, Facebook and Intense Debate allow users to reply to comments by just replying to an email.

The second missed opportunity is increasing email deliverability.  Webmail email providers such as Yahoo and Gmail automatically add email addresses that users reply to often to their contacts list.  Messages from senders in the contacts list won’t be marked as spam in most cases.  The best way to start is to allow registered users to reply to emails to confirm their email accounts in addition to providing a confirmation link.

So why haven’t companies taken advantage of this in the past?  First, it is difficult to setup the infrastructure to handle this.  It requires setting up email server software, worrying about scalability, and maintenance.  Second, parsing emails correctly can be difficult.  Emails are encoded differently, have multiple parts, languages, etc.  Luckily, SendGrid makes all these pains go away.

Companies using SendGrid can get this functionality in minutes.  SendGrid acts as an email proxy to web applications.   Users just point a domain such as domainmail.com or a subdomain such as mail.domain.com’s MX record to our cluster  mx.sendgrid.net and give us a URL to post parsed emails to.   Any email sent to that domain/subdomain comes to SendGrid, we parse it (including attachements), and post it to a web application.  This allows programmers to develop regular web forms that are exactly the same as if they were taking user input from a web browser.  Companies can give unique email addresses to their users or use the same email address and include an unique identifier in the subject (such as ZenDesk) or in the body.  For more information go here.

If you are a SendGrid user using this feature please let us know so we see what cool applications you have developed.  We would love to feature them in our blog.  Also, we would love if you can provide feedback by taking our survey here.

How SendGrid Found the SpamAssassin Y2K10 Rule Bug

January 6th, 2010

One of the many things SendGrid does on the backend to determine if a user is having deliverability problems is scan the content through multiple enterprise spam filters multiple times per day for every user.  Some of the filters include Postini, CloudMark, Brightmail, IronPort, Barracuda, Mail Foundry, and SpamAssassin.  These filters are additional filters from our delivery monitory to ISPs such as Hotmail, Yahoo, Gmail, and AOL.  In the last couple of days we noticed that a lot of legitimate emails were triggering the SpamAssassin filter.  The following shows how our graph looks like: Read the rest of this entry »

Joe Scharf Joins SendGrid

December 11th, 2009

We are very happy to have Joe Scharf join our team.  Joe has tremendous technical experience as well as business development experience having degrees in Computer Science, Electrical Engineer, and an MBA.  Joe will wear many hats in the team so don’t be surprised if you see him all over the place.  Joe will help us provide much better support for our users and help optimize our infrastructure and better utilize our computing resources.

SendGrid is still looking for talented individuals to grow its team so please checkout our jobs page http://sendgrid.com/jobs.html and apply if you are the right fit.

Categories of Email Statistics

December 7th, 2009

Different types of emails vary in interest to users.  Emails such as shipping alerts, forum notifications, and account confirmations are well received by users and hardly generate any complaints since users already expect these emails.  On the other hand, unexpected emails such as certain newsletters, or email invitations from contact imports on sites such as social networks, event planning , or surveys are less likely to be expected by users and more likely to generate complaints.

SendGrid allows companies to tag each of their emails and assign them a category.  After this, SendGrid will track emails sent, clicks, opens, unsubscribes, spam reports, and bounces per category.  Companies using SendGrid will now be able to see what types of emails generate more complaints, higher click-though rates, or what emails generate more interest.  For more information on how to accomplish this and for a video on how easy it is to get started and how the statistics look please go here.

Special Thanks

April 28th, 2009

With this being our first blog post, we would like to thank TechStars for being such a wonderful help during the summer.  They helped us get to where we are today.  We cant forget the companies that shared the jouney with us! =)

Stay tuned for updates from our blog from time to time!

©2010 SendGrid