▲ ▼ Check email service status before sending emails
When an email bounces, it gets auto-unsubscribed in many mailing lists to protect the reputation of the sender or the mailer service but a working email id can still bounce if the email service provider is having a technical issue and in this case all email ids belonging to that particular email service provider in the mailing list could potentially be unsubscribed automatically.
This can lead to mass unsubscribes if a major email service provider goes down, resulting in unrecoverable cost to the current Newsletter Economy.
To prevent this the mailer service should check the service status of the email provider before mailing to the list.
I think there is a need gap for a service which keeps track of the service status of all email providers in realtime (i.e. not dependent upon user reports like downdetector) which can be used by the mailer services.
Here's a super (I mean super) quick mvp of something similar to this idea that I just whipped up: https://isitgettingthrough.herokuapp.com/ . You can send/forward an email to three of the listed email providers with a special code in your email/newsletter and the website will check the inbox of each of those emails and let you know if the email came through. If it goes into spam or any other folders it won't show up on the page.
The issue however is that during some email outages only certain user(s) are affected, so this app cannot work 100% of the time if its account is not affected. If there's some more interest I can add some more email providers.
That was fast!
Unfortunately it didn't receive my code - 92b930c6-b2ff-419a-ba1d-a8efcd05f100 , I tried mailing without signature and tried all three email ids.
This approach has its advantages and disadvantages,
Thank you for the feedback. I just sent your code, isitgettingthrough:token:92b930c6-b2ff-419a-ba1d-a8efcd05f100, to the gmail address and it went through--I saw an email from you at the gmail account which went to the inbox but there wasn't a "isitgettingthrough:token:" at the beginning so it didn't detect it. I could make it more visible that the prefix for the token is required. I haven't checked what happened to the outlook email though.
The stuck-in-spam-or-outage can be addressed by me by also checking the spam folder and reporting which box the token got sent to. I could also report on the website that the inbox was last checked without errors at date x (i.e. valid pop3 connection.)
The reputation loss would be very difficult to control; I could whitelist everything that contains that token prefix (i.e. "isitgettingthrough:token:") but then it'd be hard to tell if the provider though it was spam as it would be whitelisted.
The waiting period is dependent upon how many emails I receive from my other accounts (gmail automatically checks them based on a moving average from when the last message was received.) I might be able to change it to email forwarding which could reduce this delay.
Oh! that was a user error, I thought for a moment about the prefix but didn't pay enough attention.
Since, the customers for a service like this would likely be bulk emailing services and those who host their own mailing lists with thousands of users I think encapsulating the entire sending/receiving email part of this and offering a simple API would be the way to go.
As there's no barrier to entry from technical perspective, the size of email id pools(from different email service provider), ability to detect outage accurately and in realtime would be the only differentiator; So encapsulation of those can help monetisation.
You have some really good points that I wasn't able to comment on my original post as I hit the character limit; I think the service-status-api-thing that you are suggesting is a good idea. I could send myself emails which are on the safe-sender list as you are saying so that it is guaranteed not to be marked as spam, and then check the most recently received email's date and then use that.
To check regional availability, I could make multiple email accounts in different regions as there are data residency requirements and so the email accounts would be forced to be in those regions. The issue is that gmail/outlook/hotmail/other providers might get suspicious as I have to use my phone number for verification each time, especially since I'd be creating 20+ accounts.