I use graylisting on my mail server. For those unaware, this involves soft bouncing all incoming mail from new senders, requiring them to retry later. The idea is that most spammers will not retry, and this has seemed to work well for me over the years.
Recently, I have run into problems receiving 2FA messages, because the sender's mail server retry interval is longer than the expiration of the 2FA token. Unless I get really lucky with my timing, this basically locks me out of that account. In this case, it's my 401k, so this is not a situation where I can simply smile and ignore the absurdity of our modern age.
I tried contacting the company's support, but unsurprisingly they have been completely useless in resolving this issue. They will not extend the 2FA tokens' lifetime, and they will not decrease their mail server retry period.
While I can directly whitelist their addresses on my server, this situation seems to signal that graylisting no longer can be used without risking untimely delivery of 2FA or other time-critical mail, since the other users of my system do not have the ability to whitelist other addresses that cause problems. If you have run email servers that use graylisting, does this track with your experience?
More speculatively, have some servers stopped retrying delivering (contrary to RFC requirements) in the event of soft failures? That would be hard to believe, but I keep reading that various FAANG mail services are increasingly hostile when interacting with independent mail servers. It would not surprise me to learn that these services have found a way to detect and ban servers that use graylisting, though I cannot fathom a good reason beyond their insatiable desire to consolidate more users onto their platforms.
For example if my MTA receives an email that has a valid hostname, spf is good, isn't on xbl, then it will accept it even if the sender is unknown. Soft bounce happens only when something is blatantly incorrect.
I used to also check DKIM before accepting a mail but that forced my MTA to accept the SMTP DATA and I worry that some clients would not retry if the mail was rejected after DATA (even though they should, because "storage full" isn't uncommon for example).
It ends up working well for me because most legitimate mail have all those things right, and most illegitimate mail have at least one thing wrong.