A Better Way to Handle Rejection

The Simple Mail Transfer Protocol (SMTP) specification lays out the rules for moving electronic mail across the internet, from one host to another. Although the specification runs to ninety-four pages, SMTP really does earn the “Simple” in its name; at its fundamental level, it contains just a few basic commands and numeric responses to those commands. Any host responsible for sending or receiving email will have a full implementation of the SMTP rules in its software, and will be able to perform its role in each SMTP transaction as expected.

According to the specification, the responses to each SMTP command will begin with a three-digit number, and most of these responses will start with 2, 4, or 5. The easiest way to interpret these response codes is as follows:

  • 2xx – Successful command completion
  • 4xx – The command failed, but might succeed at a later time, so the client should feel free to retry the command later
  • 5xx – The command failed, and will not succeed at a later time unless some condition changes

A basic implementation of SMTP would likely react to 4xx replies by holding the messages for one or more retries at later intervals (commonly called “queueing”), while 5xx replies would mean that the message was returned to its sender. These are perfectly valid reactions, fully compliant with SMTP, and you can be sure that the Momentum(™) software that forms the basis of our SparkPost product offering is designed to react in just these ways.

SparkPost’s Adaptive Delivery

What sets SparkPost apart is an additional feature built into our software, a feature that we call Adaptive Delivery. Beyond the three-digit codes, SMTP allows for additional numeric codes and/or human-readable text in replies. While this additional information is not required, nearly all SMTP implementations out there take advantage of this option to communicate in more detail to the sender as to why an SMTP command failed. With Adaptive Delivery, we offer the ability to ingest the information from these replies and automatically tailor our system’s sending behavior in response to these signals. These behavior adjustments might involve slowing down delivery rates, throttling back on the number of connections we open to a particular domain, or even suspending delivery for a period of time in response to a serious issue, giving us time to address the issue before retrying email delivery. Regardless of the adjustment taken, they’re all done with the idea of giving your mail a better chance to get delivered, either immediately or eventually.

Our Adaptive Delivery (AD) feature is a rules-based engine that undergoes constant tuning and training. Every day, SparkPost employees monitor customer traffic on our platform, looking for any delivery issues that might be present. Once we identify an issue we’ll dig into it to learn the cause; if we can write a rule for AD to better handle the issue, we will. These rules are applied at the receiving domain level so any rule we write will apply to and benefit all of our customers, not just the one having the issue at the time the rule was written.

As stated above, the main purpose behind AD is to give your mail a better chance of being delivered and its rules are designed to do this in two key ways:

  • To comply with mailbox providers’ throughput limits, thereby providing one data point toward establishing and maintaining a reputation as a good sender
  • To suspend delivery for a period of time and allow for mitigation of any block or other issue that would otherwise result in mail bouncing

These functions allow for extending the window on delivery of messages that might otherwise not make it to their destination, and because they happen automatically, no action is required either by our customers or by SparkPost personnel, meaning that the adjustments can happen any time of the day or night.

Our SparkPost platform, backed by our Momentum(™) software, is a world-class mail service, one that’s capable of delivering mail to its destination at astonishing rates; however, sometimes those rates are faster than a given mailbox provider will accept, and so AD gives our platform the ability to adjust to their rates, rather than attempt (and fail) to overwhelm them. Sometimes, good email delivery isn’t just a matter of following best practices; being a good neighbor matters too. With Adaptive Delivery, SparkPost will be that good neighbor and put its best face forward to get your mail delivered.


Top 10 Blogs: Our Year in Review

We’re finishing out the year with a roundup of our top 10 blogs from 2016. The Mandrill announcement in April impacted our community, and as a result our blog, in a big way. We’re recapping that along with other top posts on deliverability tips and email marketing best practices down below. As always, our ears are open, so if there’s a certain topic you’d like to see on the blog, leave us a comment, tweet us, or ping us in slack.

Without further ado, we give you the top 10 blogs of 2016:

#1 Mandrill Alternatives

It’s no surprise that our Mandrill alternative blogs dominated our top 10 list (5 out of our top 10). We responded in real-time to the Mandrill crisis, and our CEO even weighed in and made you a promise he intends to stick by for the long haul. The Mandrill incident also inspired us to create SendGrid and Mailgun migration guides, check them out when you have a chance.

Mandrill Template Migration top 10 blogs

#2 PHP

But beyond Mandrill, we also had some other top posts. Coming in second was using SparkPost in PHP. Believe it or not, many of you use PHP through our WordPress plugin.

PHP in SparkPost

#3 Advanced Email Templates

For developers who want to get the most out of SparkPost templating capabilities, this post was meant for you! In this straight-forward post, Chris Wilson makes sending email easy and gives you some pro tips along the way.


advanced email templates


#4 What Recruiters Look for in a Dev Candidate

Everyone wants to know how to interview well. In this post we told you about what four tech recruiters look for when hiring developer and engineering candidates.

Recruiter for Dev Candidate

#5 Webhooks!

One of the most useful elements of SparkPost are our webhooks and in this post, Ewan Dennis walks you through the basics and beyond. Knowing what to expect functionally beyond the raw API spec is half the battle when consuming new data sources like SparkPost webhooks.

webhooks: beyond the basics

#6 Outlook and Hotmail Email Deliverability

The Outlook inbox is one of the major destinations for most email senders, especially those with large numbers of consumer subscribers. It also has a reputation for being somewhat tricky to get into. In this post, one of our deliverability experts, Tonya Gordon, shares what senders need to know in order to get the best Hotmail/Outlook deliverability and ensure their messages reach the inbox.

#7 Announcing Subaccounts!

Thanks to your feedback, the Mandrill event helped us expedite our release of subaccounts ahead of schedule. Our VP of Product told you about how we process your feedback and what’s available with subaccounts.

SparkPost #WeLoveDevelopers

#8 Are You an Email Rookie?

Sometimes you need to go beyond a top 10 list and in this case we did — 17 tips on how not to be labeled an email rookie. In this post we put together a list of common mistakes, with a heavy dose of snark, on how to avoid being labeled an email marketing rookie.

Email Marketing Rookie Kid Missing Steering Wheel

#9 Retail Marketing Stats You Need to Know

Do you know what the lowest e-commerce order generators are? In this post, we give you five tips and stats for mastering retail marketing. From social media, to mobile and beacon triggered emails.

Retail Marketing statistics mobile 2016

#10 Setting Up SparkPost as your SMTP Relay

You know you need to send email, but you don’t want to spend a lot of time or effort on it — you just want something that works out of the box. It’s not too much to ask! Many frameworks, languages, and tools come with SMTP support, but the last step is the most important – an SMTP server. In this post, we walk you through how to set up SparkPost as your SMTP Relay.

And that rounds out our Top 10 Blogs for 2016! Any industry trends or topics you think were under-represented? Leave us a comment below, or tweet us!


SMTP Port Graphic Laptops Ports Clouc

A common question for anyone configuring an app or mail system to send (or relay) email is “what SMTP port should I use?” Let’s run through the different ports commonly used for sending email today.

(TL;DR: If you’re configuring your systems to use SparkPost as an SMTP relay, you should use port 587, with 2525 as an alternate in certain circumstances when port 587 is not available.)

Any SMTP Port in a Storm

Email, like every other system that connects over a network like the Internet, uses the concept of addresses to determine where a system can be found. All of us today are familiar with the textual version of these addresses, like www.sparkpost.com. And most of us know that an easy-to-remember text address stands in for a numeric IP address like But not as many of use know that these network addresses also include specific “port numbers” that are a little bit like an apartment number in a real-world street address.

For example, the web and HTTP use port number 80. For email and SMTP that port number is… well, it depends. You might see information that tells you to use ports 25, 465, 587, or 2525 for SMTP. Which SMTP port should you use? Here are the details about the most common SMTP ports.

Port 25

If you’re a systems administrator of a certain age, you know the answer used to be straightforward: SMTP was designated port 25 in IETF Request For Comments (RFC) 821. Today, the Internet Assigned Numbers Authority (IANA), the group responsible for maintaining the Internet addressing scheme, still recognizes Port 25 as the default SMTP port. But in practicality, it’s not as simple as it seems.

Although port 25 continues to be used for server-to-server SMTP relaying, most modern SMTP clients should not be configured to use this port, because Port 25 usually is blocked by residential ISPs and business cloud hosting providers alike. Why? Thank the spammers. Port 25 is blocked on many networks to curb the amount of spam that is relayed from compromised computers or servers. Unless you’re specifically managing a mail server, you should have no traffic traversing this port on your computer or server.

Port 465

IANA initially assigned port 465 for an encrypted version of SMTP called SMTPS. However, IANA since has reassigned this port for a different use, so it should no longer be used for SMTP.

However, because of this brief historical use, there are some legacy systems that still use port 465 for SMTP, and some help pages on the Internet still suggest port 465 as the recommended setup. Our advice? Don’t do it unless your application absolutely requires it—port 465 is no longer an accepted standard for SMTP. (By the way, that’s why SparkPost does not accept connections on port 465.)

Port 587

Modern email servers use port 587 for the secure submission of email for delivery. For example, if you use an email client software like Outlook or Apple Mail, it most likely is configured to use this port to send your messages. It’s not just personal email client software, however. Systems that transmit messages to an email delivery service like SparkPost also should be configured to use this port.

All SparkPost customers should use port 587 as default, unless you’re explicitly blocked by your upstream network or hosting provider. Using port 587, coupled with TLS encryption, is the best way to ensure that email is submitted securely and reliably to SparkPost (or nearly any other provider).

Port 2525

Port 2525 is not an official SMTP port, and it is not sanctioned by the IETF nor IANA. However, SparkPost and many other email service providers support the use of port 2525 as an alternative to port 587 for SMTP, in the event the above ports are blocked. (One notable example where this is required is for services hosted on Google Compute Engine.) If you’ve tried port 587 but experience connectivity issues, try port 2525. Just like port 587, most implementations that listen on port 2525 also support TLS encryption.

Learn More

In summary, SMTP port 587 is the best choice for nearly every use case for connecting to SparkPost and other email delivery services.

I hope this information helped you learn a little more about which SMTP port to use! Want to learn more about using SMTP? Here are instructions for configuring SparkPost for SMTP relay and email delivery, the differences between SMTP and API message transmission, and troubleshooting your SMTP connection to SparkPost.


SMTP Relay Graphic Cloud Monitor


Note: If you’re using SMTP to route all of your personal mail through SparkPost, awesome! However, be sure to use an email address with a different sending domain (not one associated with your SparkPost account) for your account login. That way, if you ever run into any issues, you’re still able to contact us for help.

You know you need to send email, but you don’t want to spend a lot of time or effort on it — you just want something that works out of the box. It’s not too much to ask! Many frameworks, languages, and tools come with SMTP support, but the last step is the most important – an SMTP server. SparkPost fills that need with SMTP support and a simple setup process.

Today, I’ll be demonstrating how to set up an SMTP relay, so you can use your own email client to send emails from your personal domain. I’ll be using Gmail as my email client, and shopwithkindness.org as my sending domain.

Let’s get started!

How to Setup SparkPost as your SMTP Relay

There are a few things you’ll need before setting up an SMTP relay.

  1. A verified sending domain.
  2. An API key with the “Send via SMTP” permission enabled.
  3. An e-mail client or service which allows you to enable SparkPost as your SMTP relay.

For this walkthrough, I’ll be using Gmail. To begin, navigate to the settings.

navigate to the settings button smtp relay

From there, click on the “Accounts” tab.

click on the accounts tab smtp relay how to

Next, click on “Add another email address you own”.

add another email address you own smtp relay how to

In the pop-up menu, enter the (verified) email address and press next. I’d like to be able to send with “[email protected]”, so that’s what I type in.

enter the email address you'd like to use smtp relay how to

Then, enter “smtp.sparkpostmail.com” as the SMTP Server,“SMTP_Injection” as the username, and 587 as the port. Your password should be your API key with “Send via SMTP” enabled. This information can be found under Account -> SMTP Relay in your SparkPost dashboard.

enter your username and port smtp relay how to


Let’s get started!

Lastly, you’ll need to login to your inbox to confirm. After that, we’re done! Time to send some Shop With Kindness emails.

Other Resources

If it turns out that SMTP isn’t the right email solution for you, consider taking advantage of the SparkPost API. The API has many pros (and cons). Take a look at Dave’s blog for more information regarding the differences between SMTP and API.

Lastly, if you’re having problems setting up an SMTP relay, join our Community Slack channel, tweet us or check out these resources in our SparkPost Academy!


Dev Survival Guide Blog Footer

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:


  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


  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.


  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


  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!


Dev Survival Guide Blog Footer

Working with an Email Recipient List

CreateRetrieveDeleteWhenever you’re sending bulk email, or even email to more than a handful of recipients, it’s best to put them in an email recipient list. This is particularly true if you plan to send multiple emails to the same recipients. Otherwise, you’ll have to reference every recipient every time you send an email, and the packet will be large. You can avoid these issues by referencing a recipient list. You can create, retrieve, update and delete recipient lists using the SparkPost API.

A recipient list is a collection of recipients that can be used in a transmission. The Recipient List API allows you to manage these lists. When creating a new transmission, you can submit recipients “inline” as part of the transmission data or specify a stored recipient list ID attribute instead.

When working with recipient lists, you have flexibility in deciding who does what. One person can be in charge of everything (using one API key) or you can implement separation of duties by having multiple API keys. One person can be responsible for creating recipient lists, someone else can be responsible for creating the templates and yet a third person can be responsible for creating transmissions. Each person simply needs his or her own API key with the appropriate permissions. This way, you have three different people working together but separately, and you can marry those functions together whenever you create a transmission.

You can also use the SparkPost API to retrieve a list of all the available recipient lists in an account. This allows you to see a summary of all recipient lists.

You can update an existing recipient list, but it will completely replace the existing list. If you would like to append to a list, we recommend retrieving the existing list, modifying the recipients, and then performing an update.

You can permanently delete a recipient list, but once it’s deleted, it cannot be recovered, so we advise you to keep a backup copy and double-check that you won’t be using it again. If you do need to send to a list that was deleted, you will need to resubmit the list using the Create API call. This is often not a problem because many people use a marketing platform for list maintenance and then use SparkPost for email transmission through our SMTP servers. (To understand how to use SparkPost as an SMTP relay, see this video tutorial)

The Recipient List API operates on lists as a whole and does not currently support management of individual recipients. I’ve made some training videos that explain, step-by-step, how to create, retrieve and delete recipient lists. We’ve also just added a new feature on how to update recipient lists and the tutorial is below:

If you’re in need of other resources for user engagement, check out these resources in our SparkPost Academy!


Email systems have grown increasingly complex since they first appeared in the early 1970s. The growth of the Internet (as measured by users of internet-enabled services) is largely responsible for this complexity. Spam, phishing, and forgery attacks have plagued email users across the world in recent years.

The fundamental problem with modern email systems is that, although we ascribe identity to individual email addresses, that identity is generally not enforced. To this day, it is common to find poorly configured email servers and web email forms that allow malicious users to forge emails.

To understand how this is possible and why it is a problem, we need to understand how email works in the first place.

How does email work?

The internet protocol describing email (called SMTP: Simple Mail Transfer Protocol) functions very similarly to what we now know as “snail mail”. (It turns out that this similarity is very unfortunate). In snail mail, we have two major components: the envelope, and the letter.

The Envelope

The envelope contains addressing information: Who is this letter to? Who did the letter come from? The postal service uses the “To” address, printed on the front-center of the envelope, to get the letter to the right place. Sometimes, something is wrong with this address, and the “From” address (usually printed on the top-left or rear of the envelope) allows the postal service to return the letter to the sender.

If neither of these addresses make any sense, the letter will eventually be destroyed as it can neither be delivered or returned.


The Letter

A letter from a company to a legal office may not mention names of individuals on the envelope. However, the letter will usually have information embedded in it describing who the letter is individually to, and who individually is responsible for the contents of the letter.


What Could Possibly Go Wrong?

The protocol for delivering letters via a postal service requires a large amount of trust. The example letter above is rather inflammatory, and we might have some doubts as to its validity. Consider the following questions:

  • Who is B. Baz?
  • Does B. Baz exist?
  • Did B. Baz write this letter?
  • Did Mr. Foo receive the mail, or did someone else?
  • Was the letter altered?

We could probably come up with many other questions related to this as well. Fundamentally, these questions boil down to trust. The postal service does not provide us any way to verify that the sender is who they claim to be. It does not provide us with any way to verify that the sender actually wrote the contents of the letter.

For years, people have sought solutions to these problems. We have invented opaque envelopes to prevent people from reading contents. We use better adhesives to prevent tampering (or at least make it obvious if the letter was tampered with).

With hundreds of years of experiencing mail forgery, delivery tampering, and the like, email must have considered these cases, right? Wrong. Email does not solve any of these problems. Why are they problems? Malicious individuals can exploit these issues of trust to send computer viruses or unwanted marketing email (spam). People exploit these issues of trust to send diseases like anthrax, and unwanted marketing mail (coupon books, credit offers, etc.)

Email and snail mail are not so different. But in email, we can do better.

Trusting An Identity Crisis

We have established two problems with email:

  • The identity of the sender and recipient of a mail are unknown.
  • The contents of the message are not known to be correct.

So, if we are the recipient of a letter (or of an email, for that matter), how do we know who sent it? How do we know what we are reading is what the sender actually wrote?

With regular mail, we rely heavily on context and signatures. Humans are generally pretty good at recognizing visual patterns (and discrepancies in those patterns). If we receive a letter from someone we know, we can make an educated guess as to whether they sent it based on factors like writing style, handwriting, signature, and address information.

Imagine receiving a letter from a friend. This letter is asking you for money. You know your friend is on vacation in the Galapagos Islands, and the signature looks funny. You are probably going to request additional information before you send money to your friend.

Email does not enjoy these same protections. There are no signatures — just addresses. And most people are not technologically inclined. So when King Mubotu emails from Nigeria telling you to send him $50 so he can send you $50,000,000, you do it. I mean, it is King Mubotu, right?! Right!!?

So many people are still unaware of this attack, that it is still successful. Again, the fundamental problem is that identity has not been established, and our normal contextual clues for establishing it are gone. So we fall back to trust. If you follow one rule on the Internet, it should be not to trust anyone unless you have any technical knowledge that would make you think otherwise.

Enter DKIM

DKIM (pronounced “DEE-kim”) allows organizations to claim responsibility for messages they send and guarantee the contents of the messages they send. Senders may also guarantee the identity of the individual responsible for sending the message (although this is not yet widely used).

How does the guarantee work?

In a word: math. DKIM relies on what is called “asymmetric cryptography” (also known as “public-key cryptography”). After a message is received, and before that message is delivered to its destination, DKIM uses a “private key” to create a signature for both the contents of the message, as well as some key headers of the message. This signature is attached to the message.

When the message is delivered to the destination, the destination server asks the sender for a public key to verify that the signature is correct. If the public key allows the destination server to decrypt the supplied signature to the same value it computes as the signature, it can assume the sender is indeed who they claim to be.

(Note that we can only assume that the sender is not lying about who originated the email. If the malicious party is the sender in the first place, we have to trust that they are not lying to us!)

As an analogy, consider a message sent between two corporate offices. The message includes a reference number and a phone number. The receiving office can call the sending office, provide the reference number, and read the message. The sending office can verify that this is in fact correct.

What if someone else answers the phone?

In the hypothetical scenario of a letter sent between two offices with a reference number and a phone number to verify, it is logical to assume that a malicious person could attack the security of the system. The attacker would have to:

  1. modify the message,
  2. hijack the phone line,
  3. impersonate the sending office, and
  4. lie about the validity of the message.

This is a difficult attack to pull off. But can we pull off the same attack against a DKIM-signed message? Not really.

When DKIM asks for the public key, it either receives the public key or it receives something that is not the public key. If it receives the wrong key, decryption will fail, and the message will appear invalid. If the message appears invalid, we can assume some aspect of the system has been tampered with, and we can try more strict verification of the message (such as an in-person discussion). This case does not break the guarantee made by the DKIM signature, because it can still be validated with the proper key.

If the attacker responds with the valid public key, all they have done is prove that the message was sent unmodified.

But people have hacked DKIM!

To mount an attack against DKIM, you have to own or reconstruct the private key. This has happened before in, for example, the attack against Google in late 2012. In this case, Google used an insecure key size for their private key and the attacker was able to reconstruct the key. The solution? Use a bigger key! Although this seems like a weak argument, the justification for why this works is outside the scope of this article. I do not wish to attempt to explain the complexity of integer factorization in simple terms. (At least not in this article.)

For the time being, this is a fine solution.

Invalidating Keys

If a key is compromised (either because someone obtains the key by “hacking” the sender or because they were able to reconstruct it by brute force), one can simply change the key. The problem with doing this is that once a key is known to have been compromised, it is impossible to guarantee with certainty that a message has not been tampered with. There are two reasons for this:

  1. Inherently, once the key is compromised, someone can forge messages that would have validated with the key. With some clever tricks, it might be possible for an attacker to even forge dates to make it look like the message was sent when the key was valid.
  2. The public key is generally no longer available. Once the private key has changed, the public key must change as well. If both the public and private keys are subsequently lost or forgotten, it is nearly impossible to reconstruct them.

When doing forensics work with DKIM, if the original key was compromised, it is usually not difficult to prove that messages were not forged. Most people lack the skill to forge keys and emails, and the ability to forge dates requires access to both the sending and receiving machines.


Hopefully this is a useful, lucid, and digestable explanation about the security weaknesses inherent to email (and snail mail, for that matter). If you have additional questions, feel free to contact me either via comments or via email.

If you choose email, I hope you are using DKIM!