Why Setting a Custom Message Expiration is Safe and Courteous

Messages don’t always get through on the first try. It’s unfortunate but that’s just the way the pipes of the internet work. Many times, it has nothing to do with how you’re sending or following best sending practices. We’re all familiar with the famed “421 try again later”. 

But what if you don’t want to try again later? 

As part of a batch of features SparkPost is releasing at the IP Pool level, we’re releasing the ability for our customers to set a Custom Message Expiration that takes precedence over our established retry logic

There are plenty of situations where you may want a message to expire before 72 hours. I’ll jot a couple down that I’ve seen since my time at SparkPost, maybe one of these applies to you or will bring another situation to your mind.

Password Resets – Strictly from a security perspective, aging but live password reset links delivered two days after request can open your team to unnecessary headaches and your customers to unnecessary risks. 

Flash Sales – Burst sending can lead to delays. Nothing screams poor customer experience like inviting your customer to a flash sale… that happened yesterday.

Meeting Invitations -From both a security and user experience perspective,  meeting invites need to arrive in a timely manner. If your system sends a meeting invitation or reminder 1 hour before a meeting begins, take the extra step and expire any messages that have lived longer than this.

Breaking News – Make sure that what you’re sending is still relevant, true, and the most up to date information possible.

Holidays – Nothing like asking someone to be your Valentine on February 15th – oof. Who else remembers #blackholetexts? 

 If you come up with any really fun scenarios for a custom message expiration, tweet them to us @SparkPost

Happy Sending,

Harold