Bounces from valid email addresses. How do you handle?

[Dory_Viscoglio]

There are email addresses in our database that we know are valid emails because our teams are communicating with them regularly, but emails to them from Marketo bounce regularly and repeatedly, causing them to be suspended  by our bounce policy. How is everyone else dealing with these? Or is this a problem that most other people don't have? Also, for reference, we have a Marketo Dedicated IP so that (in theory) shouldn't be related to our issues.

[Dan_Stevens_]

Some of these happen within our ABM accounts - which are our most strategic accounts.  What we've found is these companies are blocking ALL emails sent from Marketo - so having them whitelist emails sent from us isn't a solution.  We then tried another approach (as suggested by Marketo's deliverability team) - by having the account whitelist a regex version of the Return Path header (e.g., "xxx-xxx-xxx.(\d+.)*\d+@em-sj-77.mktomail.com" - where "xxx-xxx-xxx" is our Munchkin account ID).  We had one account that agreed to work with their IT department to implement - but that didn't even work.  I wish there was a simple answer here - especially as we're finding more and more of our key accounts block our (Marketo) emails.

[Kiersti_Esparz1]

Dory,

I manage the Email Deliverability Team.  I would be curious to know why the addresses our bouncing in our system.  Does the bounce we receive indicate an invalid address or some other kind of delivery issue?  I would look to see if there was a delivery issue that could be resolved like blocking related to spam filtering. 

I would recommend reaching out to Marketo Support with the list of addresses you are concerned about.  A review of the bounce reasons would give us direction on how to troubleshoot this concern.

I have seen a few Community Blog posts on Troubleshooting high bounces and I found this one very helpful.  Monitoring Email Deliverability: Troubleshooting High Bounce Rates – Part III

The author links to other blogs in this series that you might find interesting as well.

Monitoring Email Deliverability: Bounces - Part I

Monitoring Email Deliverability: Unengaged Users – Part II

Monitoring Email Deliverability: Troubleshooting Spam Blocks – Part IV

Thank you,

Kiersti

Kiersti Esparza

Manager, Privacy & Deliverability Team, Marketo, Inc.

[Dory_Viscoglio]

Hi Kiersti, thanks for the response. I will have to take another look, but we get a lot of soft bounces. Some of the reasons include:

• 550 [internal] [oob] The recipient is invalid.
• 550 5.1.1 User unknown

But these are people who we are regularly in contact with through our corporate email.

I've even seen people who are marked as delivered, soft bounced, and then opened (of the same email). 

Our bounce policy is set up as the following:

1. 2 hard or 4 soft bounces in the past 30 days, suspend for a week then unsuspend
2. 4 hard or 8 soft bounces in the past 30 days, suspend for a week then unsuspend
3. 6 hard or 12 soft bounces in the past 30 days, permanently suspend

Our teams are especially concerned because we have several newsletters and many people subscribe to multiple newsletters, so it's possible for a person to hit 4 soft bounces in a single day if their emails start bouncing.

I will have to start watching these much more closely, and I will open a support ticket regarding the bounces to see if there are any recommendations that Marketo has.

[Dan_Stevens_]

We see this one quite often: 550 [internal] [oob] The recipient is invalid.  I often chalked it up to mean the email server initially accepted delivery – probably into some sort of spam catcher (marking the email as “delivered”); and then bounced back the specific code (“550 [internal] [oob] The recipient is invalid”), letting Marketo know that this is an invalid email address.

We're finding more and more false positives in our email sends - especially from a delivered, open and click perspective, where one or all of this activity includes some sort of bounce notification at about the same time the positive activity takes place.

Our bounce policy is much less forgiving than this - especially on the hard bounce side.

[Dory_Viscoglio]

I wish our bounce policy was more unforgiving, but all of these false positives would destroy us! It's really troublesome that we can't rely on the bounce information, but we're supposed to be maintaining database health/cleanliness.

[Kiersti_Esparz1]

Dory, I would want my team to look into your concern a little more deeply.  I am surprised to see that Marketo is capturing what look like invalid address bounces

• 550 [internal] [oob] The recipient is invalid.
• 550 5.1.1 User unknown

for addresses you are actively communicating with.

The behavior you describe of mail bouncing and also showing activity is also unexpected behavior:

We would only track a bounce if the recipient's mail server returned a bounce.   In this case Marketo's mail servers received a message indicating the mail was delivered and another that it bounced.  I would need to look at the specific delivered & bounce responses to understand why we are seeing both activities. 

Speaking specifically to the 550 [internal] [oob] The recipient is invalid bounce. Any time there is a [oob] this means the email bounce was returned through an Out Of Band process.  In this case the receiving email servers accept all messages and return a delivered response to our servers.  THEN they process the mail.  In the case of invalid addresses or spam filtering the receiving email network will return a bounce response after processing.  In these cases we will receive both a delivered and a bounce in the case of undelivered email. 

[Dan_Stevens_]

Please keep us posted, Kiersti, (via this thread) as you find out more.  It will be beneficial for everyone that's in a similar situation.

[Dory_Viscoglio]

Support ticket filed... I will keep everyone updated as well!

[Josh_Hill13]

Dory, there's an old post on this from Steven Moody. Basically, pull the bounced list, look at the reason codes and then decide to set it free again if it is really valid.

Are you sending from the same domain as corporate, sub domain? Another one? Is your IP getting flagged vs. the corporate server?

You could also exclude known good leads from the suspension.