< ? php //If there is analytic campaign data, attempt to get the campaign_guid from that cookie if ( 1 === preg_match( '/pk10mkto-([0-9]+)/', $_COOKIE[ '__utmz' ], $match ) ) { $campaign_guid = $match[ 1 ]; } ?>

The Download from the CTAC


“If an email fails to send, does it make a sound”?

Good morning class, today’s topic is email monitoring.

To answer the question, if you don’t have proper monitoring setup, then yes, a failed email doesn’t make a sound. Well, for the sake of this discussion we will assume you are not reviewing your NDR (Non-Delivery Reports). When configuring email servers for monitoring, it is a no-brainer that one should watch for certain ports and services, but unfortunately, too many admins stop there. If the server or particular service goes dark, the alarm bells will sound. But what about when the queues get full, or some other wonderfully unpredictable issue occurs that halts the flow of email?

During business hours many of us are sensitive to email delays because we are expecting an email from a co-worker. Or perhaps we are just subconsciously aware that we are used to receiving an email every few minutes;  when it doesn’t happen, we feel lonely. Whatever the reason, when this happens during the day, we lob a call to our favorite IT people (sometimes that is ourselves) and ask them why we haven’t received the latest offer or coupon from our favorite store.

After business hours, things still happen, and without our Pavlovian email sensitivity to rely on, how would we know our emails are stuck? That is where “email round-trip monitoring” comes in. Simply stated, round-trip email monitoring is sending an email to an email server and checking to see if it is returned. The setup is fairly minimal on the server side, equally as easy on our monitoring platform, and can pay huge dividends in avoiding an awkward call from the CEO.

Requirements on customer email servers are as follows:

  1. Setup a server-side (not client side) email account that will receive an email from Peak 10 (specifically from support@peak10.com). For assistance on this check here.
  2. Configure that account to auto-forward all emails it receives to notify@em7g3.peak10.com
  3. Confirm with Peak 10 that the proper “To address” is being used by us and that the proper Run Book Automation and Action (internal terms that mean something to us) are in effect.

When the email fails to return, we will alert whomever you want so that action can be taken.

We recently saw a real-life scenario play out with just this type of event. Peak 10’s CTAC received an alert on a server that was too slow to return a sent email. The emails were flowing, but the company would have had a better shot at using tin cans and string to deliver their messages in a timely fashion as opposed to email. We responded immediately and saw that the email queue was awash in messages awaiting delivery; it would be 2015 before it was done processing what it had to do. A few mouse clicks got things flowing again. A call into the company to verify everything was okay found the IT staff completely unaware that anything had transpired. So an awkward call from their CEO was avoided. That is what we are here for, to help our customers avoid uncomfortable situations.

Fine tune your content search

About Peak 10

"Our values are the foundation for everything we do at Peak 10, and are ultimately what enable us to earn our customers' business and their trust."
David H. Jones,
Board Member, Peak 10 + ViaWest