1) List clean-up is critically important. I had conversations with an organization which sends a daily new summary to a million subscribers. No ads, no trash content, just news summaries. Spamhaus blacklisted them and their delivery rate fell 10% overnight. The explanation: too many bad addresses in their list. To get off the list, they were required to implement dual-verification opt-in. If your list is not opt-in, you are also at risk of being blacklisted when recipients don't want the message and flag your messages as spam.
2) Non-Delivery Types
You have four types of non-delivery
- Message cannot be delivered because domain name is wrong
- Message rejected during SMTP session
- Message rejected via non-delivery report
- Message rejected and silently discarded.
Your analysis options are affected by whether you use an outgoing gateway, and what brand of gateway is used.
The bad domains can be partially filtered by static analysis of your list. Typos will appear as domains with few subscribers, and can be checked in advance with DNS lookups to see if MX, A, or AAAA queries return data. (A and AAAA can be used as substitutes for a missing MX.) If you don't catch invalid domains in advance, they can take days to return a non-delivery report to the sending account, depending on your retry settings. So your result analysis needs to allow for the delay. The failure message will be from your own infrastructure, so parsing the error message should be a one-time effort. Log analysis may prove more useful than message parsing.
Rejected during SMTP session.
These failures should be relatively easy to parse out of the relevant log file. The rejection event must include an SMTP Response Code and may include an SMTP Extended Status Codes.
If your logs do not contain both types of codes, you will want to consider an outbound gateway that does capture both.
Non-Delivery Report (NDR) validation
One distinguishing feature of NDRs is that the SMTP MailFrom address is (almost always) empty. Some inbound gateways will add a message header to capture the MailFrom address. So parsing the message headers might be an option, but might be a bit difficult. Alternatively, you can use available log data to capture MailFrom addresses and status codes.
One problem with NDRs is knowing whether they are real responses to your messages or fraud trying to confuse your email filter. The most effective tool for this is BATV:
Barracuda uses a proprietary version of this idea in their products.
If you have an outbound gateway that applies the encoding, and an inbound gateway that can validate it, you can have certainty that the allowed bounces are really from you. This typically involves using a commercial product from a single vendor for both roles.
As you have noted, parsing NDR message content is very difficult because the format is inconsistent. Manual processes are likely to be needed for awhile. But the number of filtering products is drastically less than the number of recipient domains, so you will probably be able to move from manual to automated parsing over a period of time.
You will never know about the silent discards.
I hope this helps with your planning,