Spam Content Block

[Darren_Braze]

Hello,

I hope you're doing well.

I'm from the Deliverability team here at Braze. We've noticed that our client Holland and Barrett is seeing blocks at talk talk and tiscali.net domains with the following bounce message.

552 5.2.0 Content rejected (TT992)

The impacted IP is:

137.22.230.194

We were wondering if someone from the support team could provide some insight as to why we’re seeing seeing this and could provide any recommendations we can put in place to improve things?

Thank you! 

[Ady-TalkTalk]

I sent this over to the mail team a while back. I've had nothing yet. I've sent a chaser today. No doubt my colleagues will then send a chaser to someone at Cloudmark for a response. 

Ady

[Gondola]

Nothing coming my way. I've pushed yet another reminder into the TalkTalk workflow that you're waiting on a response.

[Darren_Braze]

Hi Gondola, 

Just following up on this. 

Do you know if there has been any updates? 

Thanks, 

[Gondola]

From TalkTalk Support next week.

[Darren_Braze]

Thank you. 

I'll wait to hear back from you next week. 

[Gondola]

This topic was escalated to TalkTalk Support by Email Message on 22-03-2023 11:30 AM by Gondola. No response from TalkTalk Support as yet. I feel that it's unlikely for there to be a response before next week.

[Darren_Braze]

Hi,

Just following up on this. 

Has there been any update or response from Cloudmark?

Thanks, 

Darren

[Darren_Braze]

Good morning, 

I was wondering if there has been any update on this case.

Thanks

[Darren_Braze]

Thank you. 

Look forward to hearing back from you.

[Gondola]

I'm well aware that the SPF file for the parent domain isn't being referenced so I only pointed that out because nobody has got that updated. It might be important if that SPF file were to be referenced by sub-domains.

You told us the sending IP address is 137.22.230.194 which resolves to the sparkpost mail server domain miwasduz.mailer.hollandandbarrett.com for which there is no SPF file.  So that's all we had from you.

But if you're now telling us that the email header going out to customers has the Return-Path as bounce-mailer.hollandandbarrett.com then the SPF file is using the macro %{i} that defines the source IP address 137.22.230.194 as an arbitrary domain name prefix that does exist as an A record on the DNS.

So, now that's cleared up a check can be made of the sending IP address 137.22.230.194 to see why CloudMark thinks that it's spam.

[Darren_Braze]

Good morning, 

Maybe I'm reading this wrong, but I'm not sure that this tone is needed. 

In any case, what I think you're looking at is the SPF record for the parent domain. Which is not relevant in this case. 

Would it be possible to take another look? 

Thanks, 

[Gondola]

You did say you represented the email deliverability team at Braze?

And you're getting an inbound email report from bounce.mailer.hollandandbarrett.com sent to you by eu.sparkpostmail.com and you see the SPF file associated with bounce.mailer.hollandandbarrett.com

v=spf1 exists:%{i}._spf.sparkpostmail.com ~all

So, now tell me what is the SPF file associated with miwasduz.mailer.hollandandbarrett.com for the sending IP address you quoted as 137.22.230.194 because I don't see any associated SPF file.

And as I mentioned, I did look at hollandandbarrett.com for an SPF file and the only one there on the DNS is a deprecated record type 99 file that should have been replaced with an SPF TXT file in 2014 at the latest. 

[Darren_Braze]

Hey, 

This is what we get back, please see attached screenshot. 

So it looks like SPF is valid. 

Thanks, 

[Gondola]

The sender IP address 137.22.230.194 resolves to the sparkpost mail server domain miwasduz.mailer.hollandandbarrett.com for which there is no SPF file.

Furthermore the SPF file for hollandbarrett.com is showing as 'The DNS record type 99 (SPF) has been deprecated'

So, without a valid SPF file that actually lists the sender IP address 137.22.230.194 I feel it's not surprising that the TalkTalk inbound mail server deals with the mail as unauthenticated spam which is what the TT992 bounceback indicates.

What are your thoughts at the Deliverability team at Braze?