No, in my extremely limited experience with email deliverability, this happens. I'd imagine a person that actually does this stuff day-to-day sees it a lot more

No, in my extremely limited experience with email deliverability, this happens. I'd imagine a person that actually does this stuff day-to-day sees it a lot more than I do. You can do "everything right" rolling your own email, but you are still relying on the receiving parties to do their job and implement sane spam prevention policies. This is far from what actually happens. I lead development on a project that sends a lot of (legitimate, user-requested, transactional) email to many mailboxes belonging to a certain government department. I used Amazon SES as they have a pretty good track record. The receiving mail servers were configured to use a few overzealous blacklists that were causing my email to be silently swallowed (and reported as delivered). This was based on an IP black-level ban. Simply Googling the names of these blacklists showed report after report after report of them being completely useless, with many seasoned sysadmins saying that nobody worth their salt should pay any attention to them. This was extremely hard to troubleshoot as this department was not a direct client and was of limited helpfulness. It became apparent that using SES's newly-launched dedicated IP functionality wouldn't have helped. I made full use of my AWS Business Support, the multiple people I talked to made it clear that SES put a great deal of effort into ensuring their IP ranges are "clean" - but there are some spam lists that do not play ball. The most important takeaway was that I was doing everything right. I was using a reputable mail provider who have very stringent spam prevention controls. I utilised SPF and DKIM. The content of my mail shouldn't have (and didn't) trigger a content-based spam detector. It was because the people on the other side weren't doing their job to an acceptable standard. When I was eventually able to open a channel of contact with the receiving department, they confirmed it was an IP range-based ban. The fact that I was doing everything in my power to do the right thing had no effect on the situation. I still wasn't getting mail to customers. Saying "darm, these sysadmins really aren't doing their job properly!" had no effect on the situation at all. We still live in the age of almost-but-not-quite-plug-and-play email solutions like Exchange that can be configured by people that probably shouldn't be configuring mail servers. For all I know, there was a list of blacklists on some Hosted Outlook control panel and the person in charge ticked all of them because more is better. As long as this is the reality I live in, I'm going to do all I can to play ball and succumb to the black magic. I can imagine my experience would've been a lot worse if I had been operating a mail server out of a dirtier IP range (generic cloud hosting provider, retail ISP customer IP range.etc). If I recall correctly, AWS severely limits sending mail from EC2 instances because they don't want their IP addresses / IP ranges to end up on mail blacklists.