When Asking a Question

A lot of beginner questions about email delivery aren’t about broad strategies for success, or technical details about authentication, or concerns about address acquisition. They’re something like:

My mail to $ISP is being blocked. How do I contact someone there?

Asking a question to your peers about how to deal with a concrete problem you’re having is a great thing to do – you might get immediate help, and hopefully you’ll pick up some technical or industry information and level up some skills along the way.

But there are good questions and good ways to ask them, and bad questions and bad ways to ask them. You really want to get the most value out of the answers you get, and you don’t want to waste your peers valuable time.

Lets talk about the “My mail is blocked, who do I ask to fix it?” sort of question on an interactive forum such as Slack, but most of the advice is applicable to other questions in other sorts of places.

Before you ask

1. Is your mail accepted successfully by the recipient mailbox provider, but then delivered to the spam folder / promo tab / somewhere you can’t find it? Or is it being delivered but you’re not seeing opens / clicks / massive purchases?
   
   These are good questions, but are likely to have much squishier answers and much of the rest of this list doesn’t apply (though some of it does).
   
2. Do you have the full rejection message from the mailbox provider? If all you have is a summary or categorized report from your ESP, go find the actual rejection or deferral message. It’ll look something like “554 5.7.9 Rhubarb hatstand - [PH01] Cantaloupe aardvark https://postmaster.yahooinc.com/error-codes“.
   
   If you can’t easily get that, or have to reach out to your ESP customer support desk to get it then you’re not going to have a good time diagnosing delivery issues yourself.
   
3. Is this a deferral, where your mail system will automatically retry delivery of the mail, or is it a rejection, where you shouldn’t try and deliver again? Rejection messages begin with a 5, deferrals with a 4. Deferrals happen, and a low rate of them isn’t necessarily a problem.
   
4. Did you read the rejection message? They’ll often have, in fairly plain english, some details about why mail was deferred. That might answer your question or point you in the right direction.
   
5. Do you know what IP address you’re sending mail from? Make a note of it, you’ll need it.
   
6. Is there a link in the rejection message? If there is, click on it and see what it says. Sometimes they’ll lead to a form that lets you see whether an IP address is blocked or not – enter the IP address you’re sending from and see what it says.
   
   Sometimes it’ll give you a list of SMTP response codes (e.g. 421 or 553). They’ll tell you what the recipients mailbox provider means by that rejection code.
   
   Sometimes it’ll list phrases or ISP-specific codes that are used in the rejection messages (e.g. “Authentication failure”or “TS04”) which can give you a fairly specific reason for the rejection.
   
7. Have you asked your ESP about it? They have access to a lot more data than you do about delivery issues across their entire customer base, and may well have already seen a similar issue with another customer. And it’s what you’re paying them for.
   
8. Search the forum where you’re about to ask for any obvious codes in the rejection message (e.g. “PH01”). Maybe you’ll get an explanation of what can cause it. Maybe you’ll see other folks are seeing the same issue. Sometimes you’ll find an announcement from the mailbox provider, or from someone who’s talked with them that it’s a known issue, a false positive that’s being worked on.
   
9. Search the forum for the name of the mailbox provider. Maybe other people are seeing the same issue. Or maybe someone has posted something useful about that providers behaviour.

Asking the question

1. IP addresses and domains and authentication details are not company secrets, and trying to hide them will hurt your chances of getting a useful answer. DNS is public, and email is largely public. A lot of delivery issues depend on those details, and if someone asks for more details they’re probably trying to help.
   
   Also, there’s a history of bad actors trying to get information to evade spam filters. They tend to be very coy about who they work for, where their mail is being sent from and who it’s being sent to. If you look like a spammer you’ll probably be treated like one.
   
2. Ask in public, not in private.
   
   Questions to a well-chosen public forum are more likely to get useful answers than to a private one. It gets more eyeballs on the issue, and problem solving as a group is often more effective and more interesting to do.
   
   Many of the folks do this professionally and answering a question in private is just asking them to do hundreds of dollars of work for free. Answering in public is something they do when they feel like it, or if it’s interesting – and it demonstrates their expertise, so it’s a somewhat justifiable use of their business hours.
   
3. Ask in one place, don’t blast it out to multiple channels. If you ask in the wrong place and someone suggests a better place it’s fine to re-ask in the better place, and add a pointer to that in your original thread.
   
4. Block out some time to be involved. Asking a question then just vanishing, and not being around to answer requests for clarification wastes everyone’s time.
   
5. Ask about your problem, not about what you think the solution should be. (This is known as the XY problem). “What can I do to fix this delivery issue to $ISP” is the problem you have, “I need to ask someone at $ISP to remove this block” is what you think the solution should be.
   
6. Be respectful of people’s time. Include the critical information as you understand it in your initial question, rather than needing to have basic details teased out of you over rounds of clarifications. Actually ask the question, don’t link to where you asked the question somewhere else (a link to StackOverflow or LinkedIn or … is never a good question).
   
   There’s seldom any need to include large amounts of data (log files, screenshots, entire messages, dozens of rejection messages). If there is you can share it later.
   
7. Be respectful of people’s screen space. If your question and it’s associated data is more than a couple of lines, hide most of it in a thread. Just make sure there’s enough context in your first post to let people know whether it’s worth their opening the thread to see the rest of it. “Hey, I’m seeing odd deferrals to Yahoo and Google apps customers over the past 36 hours, with ‘418, I’m a teapot’. Anyone else? More details in thread.” is good, followed by a thread, with more details.
   
   For any chunk of text that’s more than a few lines consider using a Slack text snippet rather than just pasting it into a channel. For bigger things linking out to a pastebin or a github gist or similar might be worthwhile.
   
8. Don’t flag your question as urgent. It’s not an emergency. There’s no such thing as a deliverability emergency, and if there were you’d be paying someone to help with it rather than relying on the generosity of the internet to fix it for you. Chill.
   
9. Never include the recipients email address, unless it’s a mailbox you control and are sending test mailings to. Ideally remove the left hand side from the email address and leave the right-hand side. I don’t need to know that you’re sending mail to steve@blighty.com, but it’d be very useful to know that you’re trying to send to someone at that domain.
   
   ❌ “steve.smith@gmail.com”
   ✅ “<deleted>@gmail.com”
   
10. Include the full rejection or deferral message, other than removing PII such as the recipients email address. Your IP address is not PII, your domain is not PII, the recipient mailbox providers domain is not PII.
    
11. Include the most important information about how the mail is being sent. What IP address is it being sent from? What domain is it being sent to? If that’s not obvious from the rejection message, include it explicitly.
    
    If you know who the mailbox provider is (e.g. Google workspace) and it’s not obvious from the recipient domain mention that.
    
    Is it being sent from an ESP pool shared amongst multiple customers, or a dedicated ESP owned IP, or an IP owned by the sender?
    
    Is it B2C mail or B2B? They often have very different filters and delivery issues.
    
    Is it cold email? (If so, any delivery issues are spam filters working as intended and it’s really not worth asking the question).
    
12. Include anything that seems important about what’s in the mail being sent and who it’s being sent to. Is it transactional? Marketing? Password resets?
    
    Is it being sent to active users or new signups?
    
13. What’s changed? Did delivery suddenly fall off a cliff a week ago? Did you change ESP? Did you start sending to an older group of addresses?
    
14. What have you tried so far? This helps narrow down what the issue may be, and hopefully reduces the amount of clarification / have you tried? questions. It also demonstrates that you have tried to get somewhere before asking for help.
    
15. Don’t use screenshots of text, use the text itself. Screenshots of things like charts of delivery rates over time? Sure. Screenshots of web reports or other all-text content? If you can share it as readable text, do that instead.
    
16. Don’t start off by bitching about how terrible Gmail’s filters or Yahoo’s staff or .. are. It’s unprofessional. It’s rude. We know folks who work there. They may be represented in this very forum. And it also demonstrates that you have a childish understanding of how spam filters work.
    
    “Yahoo are blocking your mail because you’re sending spam, Gary.”

And then

1. Wait. It’s an asynchronous medium. People are busy. People are all around the world in different timezones. Don’t “bump” the issue to try and get an immediate response.
   
2. People will ask for clarification. Try and answer that helpfully.
   
3. People will often ask about an aspect of your issue you don’t feel is relevant. Just go with it. They’re trying to help you fix your problem, and they may see an underlying issue you’ve not considered. (Also it’s far quicker and more productive to answer a few clarification questions than expend any effort on defending why that’s not the issue).
   
4. Quoting from Eric Raymond:
   “Much of what looks like rudeness in hacker circles is not intended to give offense. Rather, it’s the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy.”
   
5. People will ask you to try and share additional data (“What selector are you using to sign DKIM with?”, “Have you seen click activity from these recipients in the past month?”).
   
   If it’s easy to get, give ’em the info even if it doesn’t seem relevant. They may see something you don’t, and it helps to look cooperative with folks.
   
   If it’s going to be more time consuming, but seems like it might be relevant then confirming you’ve seen the suggestion isn’t a bad idea. “Yeah, that might be a bit more work to get but if we’ve not fixed it by then I’ll pull that data tomorrow.”

And afterwards

1. If you fixed the problem, share what the problem was and how you fixed it. It’s only polite.
   
2. If you didn’t fix the problem, but it just went away that might be worth sharing in the original thread too. Negative results can be as useful as positive ones.
   
3. Learn from it. When someone asks near identical questions repeatedly and they’re clearly not levelling up their skills or are just lazily asking a forum to help them do their job they’ll often start being ignored by folks who are generally skilled and helpful.
   
4. Help other folks out. Stick around, answer other’s questions.
   
   Be nice.