Email Deliverability Issue - Soft Bounces

[Anonymous]

Hi,

We have been working on a global rollout since past few months for a major product of ours. We did the IP warming in phase 1 in May for our North America launch and we use a Marketo issued dedicated IP. We have the following records in place

1) A record - xyz.abc.com and bounce.xyz.abc.com

2) SPF - Includes our dedicated IP

3) DKIM

4) DMARC

5) PTR - currenty only points to bounce.xyz.abc.com.

The email is sent from xyz.abc.com and we are seeing a high soft bounce rate in Europe with our recent launch, almost 50%. We are looking at possibilities of the higher soft bounces. I felt we should have PTR pointing to both bounce.xyz.abc.com and xyz.abc.com. However, we never had such higher bounces in past campaigns.

We found our IP and domain are in SORBS Blacklist, per mxtoolbox. There is no other blacklist for the IP. I was told by Marketo to ignore SORBS as it isn't recognized anymore by mail clients anymore. Does the IP warming we did for our north america launch help with Europe launch or do we need to do the IP warming again? I was wondering how ISP's treat IP launches based on target regional launches.

Any ideas on what could be the issue?

Thanks

Uday

[Dan_Stevens_]

This just happened to us.  We sent out an email this morning to a targeted list of clients in Germany.  Everyone soft-bounced - with an "Empy address" as the reason:

I just opened a P2 ticket with Support.  I'll come back with an update as soon as I hear more.

[Anonymous]

Dan - We believe that most of our soft bounces are with hotmail and live emails. We are seeing 554 error codes.

[Dan_Stevens_]

After further analysis, we found a bug with the velocity token that is being used for the FROM address.  That's what "Empty Address []" means.  It's now fixed.

[Anonymous]

Glad to hear!

[Dan_Stevens_]

We too notified Marketo of the blacklist issues we've been seeing in MXToolbox.  They told us to not worry about this since their deliverability team is in constant contact with the spam/blacklist vendors to re-whitelist Marketo IP addresses.

[SanfordWhiteman]

You should supply your actual domain and IP address info if you want someone to check your setup... these aren't secrets!  (example.com is the standard domain to use as a placeholder, btw.)

Assuming from the hostname that bounce.xyz.example.com is your branded sender domain, then your SPF record needs to be set for that domain, not for its parent xyz.example.com -- although frustratingly, Marketo's UI insists on verifying non-envelope domains' SPF as well.

SPF, DMARC and DKIM can of course hurt deliverability (that's the idea) if you've set policies but not obeyed them. For example, if you have a catch-all, deny-all SPF record for *.xyz.example.com IN TXT "v=spf1 -all" and then start sending from the envelope domain bounce.xyz.example.com, all your emails will hard fail SPF.

[Anonymous]

Thanks Sanford! Please see attached. Appreciate you looking into this.

[SanfordWhiteman]

Thanks for filling that in.

Your SPF record for the envelope domain looks good:

bounce.marketingemail.visa.com. 300 IN  TXT     "v=spf1 ip4:192.28.150.222 -all"

PTR for the IP also passes the "round trip":

222.150.28.192.in-addr.arpa. 85760 IN   PTR     bounce.marketingemail.visa.com.

Don't know what you mean about having two PTRs. You should only have one PTR for this IP (the one you have) or else you risk failing all PTR checks (DNS allows multiple RRs but client apps won't check them all).

DKIM record and sig looks good.

DMARC policy seems enforceable.

What are the kinds of SMTP-level errors you're seeing for the bounces/rejections?

[Anonymous]

Thank you! I was wondering if we need PTR for even the marketingemail.visa.com. However, based on your response it looks like since bounce.marketingemail.visa.com is our branding domain, we do not need one for marketingemail.visa.com. I didn't follow your comment on the DMARC when you mentioned it can be enforced. Can you let me know what it means? The bounce error codes we are getting for Europe is

554 5.4.5 [internal] Delivery not attempted (message expired)