I have an email delivery problem. Can you help?

I see a lot of requests for help with some sort of delivery problem, sent to me as an individual, sent to Laura as part of a consulting relationship, sent to ISPs, sent to organizations running blacklists or sent to industry mailing lists, both public and private.
Some of them could be done better. OK, most of them could be done better, some of them could be done a lot better. Here’s some things to do to get the best response from your delivery consultant, your fellow mailing list members or your ISP contact.
Be specific about what delivery problem you’re seeing
Are you seeing SMTP hard rejections? Are you seeing slow delivery (due to soft rejections, or connection level timeouts)? Or is the mail being delivered, but ending up in the bulk folder?
Bad question and answer: “Is anyone seeing delivery problems with Yahoo?” leads to “There’s a ‘y’ in the month, of course we’re seeing delivery problems at Yahoo.”
Better question for a useful answer: “I started to see a lot more soft bounces from Yahoo last Thursday, and our probe accounts there are seeing mail ending up in the bulk folder – is anyone else seeing this?”
Describe the symptoms
One of the most important things is to describe the symptoms you’re seeing, rather than just your guess at what the underlying problem is.
Bad question: “Our client, the Breast Cancer Foundation, is seeing delivery problems because of the word ‘breast’ – how do we get them whitelisted?”
Better question: “Our client, the Breast Cancer Foundation, is getting filed in the junk folder at AOL – what should we look at to work out why?”
Mention where you’re getting your information
Are you seeing detailed rejections in your mail logs, or just seeing your outbound mail queues growing? Are you seeing bulk folder delivery on your own email accounts at the receiver, or are you relying on data from a commercial mailbox monitoring company?
Provide the basic information about delivery that’s usually going to be needed

What IP address are you sending email from? What domain are you sending to? Or, if you’re contacting the ISP, what email address? What sort of mail are you sending? (If you’re contacting a blacklist or ISP, include the IP address in the subject line).
Are you the only person sending email from that IP address, or is it shared by other users?
If you’re getting rejections, bounces or deferrals, include the rejection message or bounce message.
How much mail are you sending to the domain where you’re seeing a problem? How much is being rejected or delayed?
What, if anything, have you changed recently? If you’re mailing for yourself, did you just start mailing a new bunch of contacts you’ve acquired (or discovered, in an old database)? If you’re an ESP, is this a new customer, or have they been mailing successfully for a while?
What are your typical complaint / feedback loop rates? What are your typical user unknown or rejection rates? If you’re monitoring inbox delivery, what are your inbox rates at this receiving domain?
Do you have a feedback loop or whitelist set up with this receiving domain? Are you using any sort of authentication (SPF, DKIM)?
Bad question: “I’m seeing a lot of bounces from AOL. Any idea why?”
Better question: “I’ve been sending mail without any problems for a while, but most of my AOL recipients have been rejected today, with the message 554 HVU:B1 http://postmaster.info.aol.com/errors/554hvub1.html. We don’t have a feedback loop or whitelist with AOL. What happened?”
Say what you’ve already done
If there’s a URL in the rejection message, did you click on it? Did the page it led to help?
Did you contact the receiving ISP already? What did they say?
Timeliness – there’s no such thing as a delivery emergency
Email delivery problems are never a life-or-death issue. Don’t demand immediate responses to email. Don’t follow up with a phone call five minutes after sending the email.
Conversely, if you saw a delivery problem three weeks ago which has since fixed itself then not only does nobody care, it’s likely that some of the information that would have helped diagnose the problem may no longer exist.
Appropriate communication channel

It’s very difficult to resolve a delivery issue by ‘phone. Partly that’s because you need to communicate some detailed information (like IP addresses) where even a single typo can make any analysis worthless, so cutting and pasting is the only way to avoid problems. But it’s also partly because it’s often something that can require significant work to analyse (checking databases, delivery logs, reputation sources, email structure, checking with other people working in the field), all of which is difficult to do while also dealing with someone on the ‘phone.
Avoid using IM for this too, unless you’ve been asked to do so. And if you’re using IM, offer to send the bulkier data (logs, IP addresses, sample messages) by email.
If you’re communicating with someone where answering your questions is part of their job description it’s even more important to use email, so that all the information is stored in their ticketing system – both for future reference by them or their colleagues, and also to make sure that their work is visible to their employer.
Respond appropriately to questions
It’s likely that whoever you’re asking may need additional information, such as a sample message. If they ask you for more information, respond with it as soon as possible, while they still have the issue in their mind.
Don’t argue that the information is irrelevant, or they don’t need to know it. Really, they wouldn’t ask if they didn’t think it might be relevant. If you can’t provide it (because you don’t have it, or for privacy or contract reasons) explain that, and see if there’s something else that might provide the same useful information.
Respond appropriately to answers
You asked the question because you didn’t know the answer, and you thought the person or group you asked might. So rejecting an answer you get just because it seems wrong to you or you don’t fully understand it is probably a bad idea.
I regularly see clients who are paying good money for extremely competent deliverabilty advice refuse to accept the answer they’re given – insisting that the problems can’t possibly be due to the content of the email, or the reputation of the sending IP address, or the types of links included in the email. Then, after wasting several (billable) hours arguing with their consultant they actually try the change suggested, and it helps with the problem.
If you’re asking a mailing list, rather than an individual, then it’s possible you will get some completely useless suggestions. It’s still better to politely explain why you think they don’t apply (and listen to any replies you get to that) than to reject or ignore them out of hand.
Courtesy
You’re asking for help. Even if you’re paying the person you’re asking for advice you’re still more likely to get service above and beyond if you’re pleasant to deal with. Wrap a little social lubricant around your question – a “Hi!”, “When you get a moment, could you take a look at…”, “Thanks!” goes a long way.
Be respectful of their time. If it’s not an urgent issue, let them know that. Try not to ramble.
When the problem is resolved, write and thank them for their effort. If you identified the problem and it wasn’t what they thought, explain briefly what the issue was. You never stop learning, and it’s possible that knowing that will help them elsewhere.
Be nice. Be brief. If you’re easy to deal with, you’ll get more helpful responses.