The Differences Between Using SMTP or API with SparkPost

Dave Gray
Jun. 10, 2016 by Dave Gray

sending with SMTP or API

Sending email through SparkPost to your subscribers and/or customers can be done two different ways: using our API, or sending via SMTP. The deciding factor will usually be some combination of convenience for your use case, availability/cost of coding/hardware resources, and the relative priority for your business of things like sending speed and ease of migration.

There are pros and cons for both approaches. Naturally, we think our API is pretty great, and that it has advantages over SMTP, otherwise we wouldn’t have it. Offering SMTP in addition to our API lets us support a wider range of use cases. Let’s take a look at pros and cons for both SMTP and our API, as well as examples of each approach.

Sending via SMTP with SparkPost

Sometimes SMTP is the only choice that makes sense, given your constraints. Maybe your legacy system uses SMTP, and nobody is available to write the code to send via API instead. SMTP lowers the friction for this migration path. Common steps such as modifying existing messages by adding a custom header to set the campaign for different message streams, or enabling open/click tracking tend to be significantly less effort than starting to use a new API.

Which is a nice segue to show a pro/con list for sending with SMTP:

SMTP PROS:

  1. Platform-agnostic – SMTP is accepted everywhere
    • If you want to migrate again, it’ll be easier
  2. You have full control over your “mail merge” process
    • Can generate messages however you like
    • Continue to use existing tools
  3. SMTP failures are in-band and always include context
    • Failed command and error code tell you what failed and why

SMTP CONS:

  1. SMTP is not accepted FROM everywhere
    • Some environments’ firewalls block ports commonly used for SMTP
  2. You have to build your own “mail merge” messages
    • MIME and the various email RFCs can be tricky
    • This has a resource (hardware & bandwidth) cost, especially for bulk sends
  3. SMTP is a chatty protocol
    • Each message requires several round trips to our servers
    • This adds up to longer bulk send times

Here’s an example of injecting some test content into SparkPost with SMTP, using swaks. The API key you substitute below will need the Send via SMTP permission, or authentication will fail with 535 5.7.8 Sorry. .

Sending with the SparkPost API

We like our API, and we hope you like it too. We think you should use it, as there are quite a few advantages over SMTP for many use cases, for example, triggering mail directly from your app’s server-side code. Besides, with a paid account you’re really not getting as much as you could for your money without offloading everything from your systems onto SparkPost that you can, which the API allows you to do.

API PROS:

  1. HTTP is allowed by all but the most restrictive firewalls
  2. Generation AKA “mail merge” is handled by SparkPost
    • Removes load from your servers
    • Can mean generation hardware/horsepower is no longer needed
  3. One connection round trip per API call
    • No per-message latency
  4. Async sending and concurrency is handled by SparkPost
    • Up to 10k message batches for best performance
    • Reduces complexity (AKA things to break) in your app

API CONS:

  1. Using our HTTP API means writing code
  2. Replacing in-house generation may require refactoring
    • Things like pre-processing data to format dates differently
  3. Stats are generally out-of-band
    • Some sending errors are in-band (invalid email, for example)
    • Others require processing event data one of two ways:
  4. For larger sends (10k+ recipients) batching or concurrency is recommended
    • This is a performance sweet spot, not a hard limit

Here’s an example with the same test content as above, using cURL. The API key you substitute below will need the Transmissions: Read/Write permission, or the API call will fail with HTTP/1.1 403 Forbidden, and {"errors": [ {"message": "Forbidden."} ]}  in the body.

So there you have it! As with most things in life, the answer to which will work best for you is (spoiler alert) “It depends.”. We recommend using our API, unless there are reasons that won’t work for you, such as lack of development resources to make the switch. SMTP is there as a safety net to help support those cases.

Whichever way you choose, make sure you set up DKIM! Authenticating the source and content of your email is very important, and can have a huge impact on the deliverability of your email. Instructions for setting up DKIM are here.

What were the deciding factors for your choice between SMTP and our API? Let us know on Twitter @SparkPostDev, in our Community Slack channel, or in the comments, below!

-Dave

Dev Survival Guide Blog Footer

Share your Thoughts

Your email address will not be published.

Related Content

Community Spotlight: How Topol Makes Creating Beautiful HTML Email Templates Easy

Building HTML email templates is hard. Learn about the app that Jan Tlapak and Sendmark created for anybody in need of building beautiful HTML emails.

read more

5 Easy Ways to Enhance Your Customer Segmentation Strategy

With hundreds of ways to segment email lists and personalize campaigns, these 5 methods of customer segmentation are an easy place to start.

read more

Learn To Love Your Unsubscribers

Unsubscribers are inevitable in email marketing. They’re often looked at negatively, but we prove how they do a lot of work for marketers by cleaning lists.

read more

Start sending email in minutes!

The world’s most powerful email delivery solution is now yours in a developer-friendly, quick to set up cloud service. Open a SparkPost account today and send up to 100,000 emails per month for free.

Send 100K Emails/Month For Free

Send this to a friend