Where I come from, across my different hats, there's always a mail problem somewhere. Did some third-party service change the DKIM signature being used? Are they now sending from an IP not included in my SPF? Did I add too many SPF records, and now some services reject them? Did...
I'm not aware of any significant issues outside of that realm, but I'm sure there must be some. If I'm occasionally experiencing those issues, likely, my customers are as well. Then how do I offer that as a service to them? I've primarily been an ISP operating other core portions of the Internet, but we're expanding into small-business MSP services. I'll certainly look into the services you mentioned. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Al Iverson" <aiver...@wombatmail.com> To: "Mike Hammett" <mail...@ics-il.net> Cc: "mailop" <mailop@mailop.org> Sent: Monday, July 7, 2025 11:52:09 AM Subject: Re: [mailop] Mail Monitoring Service This is effectively the wrong place to ask, because testing deliverability that way seems to be more a marketer's function than an ops engineer's function. I personally utilize seed list testing, which is just like marketers do. Instead of sending to just one test address, you send to a bunch of them. The testing tool provides the list by creating mailbox accounts wherever they can. They capture all the mail and give you a report back. Services that do this include GLockapps, Inbox Monster, and Validity's Everest. If you look up pricing, you'll see that they're not cheap, and they're quite marketing oriented. But they're the best you can do here. They still have limits; some filtering, like for example at Gmail, is individualistic enough that the copy sent to the Gmail seed addresses may not always be dispositioned the same way mail to real recipients would be handled. But...it's the best you can do, IMHO. And it works as well as either marketing or non-marketing mail, transactional bulk mail, 1:1 mail systems, whatever. If you can manage to send the same email to a bunch of addresses, manually or scripted, you can make it work. At one point I rolled my own one of these testers, a little hacky one that only supports a handful of providers, using fetchmail and shell scripts. It's slightly outdated and slightly broken and I don't really use it much anymore. If I had money to spend, I'd probably Look at using Andris Reinman's Email Engine ( https://emailengine.app/ ) to be the tool that grabs the mail from all the mail accounts, and then just custom build the bit that recognizes the same test message across accounts and generates disposition reporting. Even with any tester, you're not going to get perfect results. Because of that black box factor. In marketing land, historically you bridge that gap with open tracking (high opens = probably went to inbox, low opens = probably went to spam), but that is less and less accurate over time thanks to privacy protection and proxying of image loads. And of course, watch for bounces. I blogged recently about "how to check your sending reputation" because of those misconceptions I touched on earlier in the thread. It is (again) relatively marketer oriented, but I think the principles apply universally: https://www.spamresource.com/2025/06/top-5-ways-to-check-your-email.html Cheers, Al Iverson On Mon, Jul 7, 2025 at 11:33 AM Mike Hammett <mail...@ics-il.net> wrote: > > I'm not seeking a service that guarantees deliverability, nor do I wish to > provide it. It's an impossible service to provide, as I already knew, and you > all were so kind as to point out. > > I'm seeking something that proactively tests deliverability using the top, > publicly available methods from "real" mail actually sent and not simply > typing IPs into a webform. > > > https://mxtoolbox.com/deliverability > > The MX Toolbox Deliverability tool is a great on-demand resource. You send an > email to a live email account, and they test the actual email received. No, > they don't check if it'll get through Google or Yahoo or Hotmail or 365 or... > because, as far as I know, you can't. Well, at least as far as the black-box > portion. Many have some amount (incomplete) of guidelines. It would be great > to have a service that regularly (say daily) triggers an email from your > locally hosted Zimbra, Carbonio, Postfix, etc. implementation, your 365, your > CRM, your whatever else, checks it, and logs the results. It may even alert > you to failures. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > > ----- Original Message ----- > From: "Al Iverson via mailop" <mailop@mailop.org> > To: "mailop" <mailop@mailop.org> > Sent: Monday, July 7, 2025 11:13:23 AM > Subject: Re: [mailop] Mail Monitoring Service > > It is definitely not just marketing. There was a recent Reddit thread > talking about Outlook blocking Yahoo and nobody knew what to do about > it. (Nothing, cuz you're not the email admin. No fun, but it happens.) > For the very important notifications that I send to other unit owners > in our condo building, where I'm the board president, RCN blocks 'em > regularly. I can't figure out how to stop the blocking so I just > manually forward that one every time. (Spoiler alert, the IP's not on > a blocklist and I know how to do all the header things properly.) > Apple was blocking my test emails at one point recently, with a > perceived IP or domain rep issue, but still, not in any externally > queryable blocklist. Was only able to resolve that one through the > contacts I've made through various email industry forums. (I don't > send marketing mails.) > > I still run my own MTA because it's fun and I don't think these > challenges are insurmountable, but I get why hobbyists cry that it's > nigh impossible nowadays. And I die a little inside every time > somebody plugs their IP into a DNSBL checker or MX Toolbox and tries > to use that as a measure of whether or not their mail will be > delivered. It's just not enough of the right data from the right place > to make a determination of deliverability problems. > > Cheers, > Al Iverson > > > > On Mon, Jul 7, 2025 at 10:13 AM Mike Hammett <mail...@ics-il.net> wrote: > > > > In the big picture, I would still call that the long tail, at least in > > terms of non-marketing emails. Marketing email, yeah, you'll have those > > problems. > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > > > ----- Original Message ----- > > From: "Al Iverson via mailop" <mailop@mailop.org> > > To: "mailop" <mailop@mailop.org> > > Sent: Monday, July 7, 2025 9:28:14 AM > > Subject: Re: [mailop] Mail Monitoring Service > > > > You've misidentified where the long tail is. Most people who reach out > > to me because they're having deliverability issues and who want > > advice, especially because of spam folder placement, it's because of > > reputation issues measured by internal black box systems at Microsoft, > > Google, Yahoo and Apple. Not externally queryable, nor determinable by > > reading headers. I literally could roll a die to guess what they're > > going to say, and I'd be right a lot more than half the time. "But I > > enabled DMARC!" "But it's passing DKIM!" "But I'm not on a blocklist!" > > Yeah, true, but.... > > > > Too many people think they have to be on a blocklist to have a > > deliverability issue. (This isn't 1999.) > > Too many people misunderstand the point of email authentication, > > believing that it somehow guarantees inbox placement. (No, it's the > > flip side that is true. Try to get inbox placement WITHOUT it -- it's > > very hard. But with it properly set, it doesn't protect you from > > reputation/engagement/complaint-related issues.) > > Even real IP reputation issues are often confused; the sender thinks > > that because their IP address is on UCE Protect Level 3 AND they're > > facing blocking at Microsoft, that these things must be connected. > > (They're not.) 99% of blocklists are barely used. > > > > In short, it just don't work that way. > > > > Cheers, > > Al Iverson > > > > On Sat, Jul 5, 2025 at 1:50 PM Mike Hammett via mailop > > <mailop@mailop.org> wrote: > > > > > > Well, no, but you can make a fairly educated guess. > > > > > > Did the SPF check out? > > > Did the DKIM check out? > > > Did the DMARC check out? > > > Did it pass through any servers on the way with a questionable IP > > > reputation? > > > etc. > > > Do basic SPAM checks trip on anything? > > > > > > > > > My intent is to focus on the 90 or 95% of issues and not the long tail. > > > > > > > > > > > > > > > This is not for blind mass marketing email, which I think is what > > > everyone seems to care about anymore. > > > > > > > > > > > > > > > ----- > > > Mike Hammett > > > Intelligent Computing Solutions > > > > > > Midwest Internet Exchange > > > > > > The Brothers WISP > > > > > > > > > ----- Original Message ----- > > > From: "Anne P. Mitchell, Esq. via mailop" <mailop@mailop.org> > > > To: "Mail Op" <mailop@mailop.org> > > > Sent: Saturday, July 5, 2025 1:29:10 PM > > > Subject: Re: [mailop] Mail Monitoring Service > > > > > > > > > > > > > On Jul 4, 2025, at 9:33 PM, Mike Hammett via mailop <mailop@mailop.org> > > > > wrote: > > > > > > > > "It also means that no external service can really do the job for you." > > > > > > > > Of course there is. Log in to my mail server and send an email as one > > > > of my users (of course, a dedicated user). Initiate an email send from > > > > the CRM. Initiate an email from... > > > > > > That only tells you that the email was sent and, maybe, depending on the > > > monitoring, that it was accepted at the other end. It does *not* tell > > > you what happened to the email once it was accepted. > > > > > > Anne > > > > > > -- > > > Anne P. Mitchell, Esq. > > > Email Law & Policy Attorney > > > Legislative Advisor > > > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email > > > marketing law) > > > CEO Institute for Social Internet Public Policy > > > Creator of the term 'deliverability'; Co-Founder of the deliverability > > > industry > > > Author: The Email Deliverability Handbook > > > Board of Directors, Denver Internet Exchange > > > Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School > > > Prof. Emeritus, Lincoln Law School > > > Chair Emeritus, Asilomar Microcomputer Workshop > > > Counsel Emeritus, eMail Abuse Prevention System (MAPS) > > > > > > > > > _______________________________________________ > > > mailop mailing list > > > mailop@mailop.org > > > https://list.mailop.org/listinfo/mailop > > > > > > _______________________________________________ > > > mailop mailing list > > > mailop@mailop.org > > > https://list.mailop.org/listinfo/mailop > > > > > > > > -- > > > > Al Iverson // 312-725-0130 // Chicago > > http://www.spamresource.com // Deliverability > > http://www.aliverson.com // All about me > > https://xnnd.com/calendar // Book my calendar > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > > > -- > > Al Iverson // 312-725-0130 // Chicago > http://www.spamresource.com // Deliverability > http://www.aliverson.com // All about me > https://xnnd.com/calendar // Book my calendar > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com // All about me https://xnnd.com/calendar // Book my calendar _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop