on 31-08-2021 03:54 PM
We represent a company that has many customers who use TalkTalk and Tiscali email addresses and we are now having problems sending to them. The emails are often being deferred with the error of TT991.
We are sending constant updates about their accounts and have been doing so for many years without a problem. These emails are being requested by our clients on an opt-in basis and we actually get complaints when they don't get the emails quickly.
However, we have recently changed Internet provider and as such we've been allocated a new block of IPs and I believe this is the problem because our new IP block has no reputation. We've had similar problems with Microsoft and Verizon Media and I was able to get both of those to copy our reputation history from our old IPs which has fixed the problem. We need to do the same here with TalkTalk please.
We have correctly setup SPF records and reverse DNS. We are also DKIM signing all messages and have DMARC reporting setup and as mentioned above we are only emailing customers who have specifically requested that we do so.
We tried contacting TalkTalk last week (incident 210825-000560), but only received a generic reply and no follow up since then.
Can you please advise who we need to talk with to resolve this?
Many thanks in advance for your assistance.
on 02-09-2021 05:25 PM
Ady's not here right now so I'll just add that the slow start up to build the reputation is exactly what is required. When CloudMark sees that there's no issue it'll cease deferring for scanning.
I'd check the IP addressing with the blacklist tool at MXtoolbox and request delisting as necessary. Probably best to concentrate on getting a few IP addresses with a good reputation rather than aiming for the entire block.
Let us know how you get on.
on 02-09-2021 04:32 PM
Thanks for your reply, but with all due respect you've just said that you've no influence over the mail system so it doesn't really make any sense to get the customers to have to register here and then report the problem when you can't actually help them?
We still have our old Internet connection/old IPs for another week and I'm trying to drive more and more of our emails through the new connection/new IPs in the hope that TalkTalk will increase our reputation/relax the TT991 filtering as you see more and more genuine emails.
But after that date, if we're still having problems/customer complaints about delayed emails, we unfortunately won't have much choice except to advise them to create an incident report with yourselves about an email problem.
I appreciate that there is only so much you can personally do and I also understand that TalkTalk wants to try and keep their customer mailboxes as spam free as possible, but changing Internet provider/new IPs is not that unusual. We are still sending from the same domain names and continue to have correctly setup SPF records, reverse DNS, DKIM signing and DMARC reporting and as such I'm disappointed that there doesn't seem to be any way to work with TalkTalk to resolve these problem before it affects our mutual customers.
on 02-09-2021 06:22 AM
Hi neilkemp, I'm only the messenger. If you need to let your customers know that they need to register here and report that they're not receiving I'll be here to help them. I'm afraid I have little or no influence over the team who run the mail system.
on 01-09-2021 06:29 PM
IP details are in incident: 210825-000560
Thank you for your reply, but the IPs mentioned in the incident report are not dynamic. The block of 64 IPs is allocated to us for the duration of our Internet contract (at least 5 years).
I do understand what you're saying about building up reputation, but we cannot be the first company that has ever changed Internet provider (and therefore received new IP addresses). Although our Internet connection has only recently become live, we've been assigned this IP block for 6 months now so I know that you've not received any spam emails for at least that amount of time and therefore asking for a reputation reset doesn't seem unreasonable.
We already have the SPF records updated to show the new IPs, but TalkTalk is essentially choosing to ignore this. The emails continue to be DKIM signed and are from IPs where the reverse DNS is setup. The address in the emails are also the same domain names we've previously sent from, so surely that must give us some reputation, especially as the sending IPs continues to match the SPF records?
I'm not really sure how to proceed then, because you are basically saying "wait for an unknown period of time", but in the meantime our customers (which are also your customers) are complaining to us about why they're no longer receiving their emails in a timely manner.
We have literally thousands of customers using TalkTalk/Timico addresses and we're trying to resolve this with you, but indirectly you're not leaving us any option but to refer those same customers to yourselves ("Sorry we're sending the emails you asked for, but TalkTalk is rejecting them and you'll need to talk to them as they won't talk to us").
We don't want our customers to have to jump through extra hoops and I'm sure TalkTalk doesn't want the extra work either, hence we're trying to work with you to resolve it before it becomes a bigger issue. To be honest I'm kind of shocked we even have to discuss this on a public forum when you have a ticket system which apparently you're also saying can't be used for this (and not offering any other option?).
I understand that we're not your customer, but we're trying to work with you on behalf of your customers, so please... there must be a way we can work together?
on 01-09-2021 10:43 AM
Hi neilkemp, I've spoken to a senior member of the team who manage email.
Here's what I've been told:
We can't copy over reputation from one IP to another, your ISP has given you a low reputation dynamic IP address and you'll have to build reputation with that until our systems will trust the mail coming from that.
Normally, users on an ISP network would send through their confirmed mail IP and have SPF records set up on the sending domain to indicate that the mail coming from thier IP is legit. Obviously this won't help you.
Sorry I can't be of more help.
on 01-09-2021 09:35 AM
Hi neilkemp, none of our teams are equipped for dealing with non customers raising issues. Even if the ticket is open they've got no way to get this to the right people.
I've asked the email admins if we've got a process for this that will help you.
on 31-08-2021 05:25 PM
Heads up that I'm just one of the SuperUser team for Community member to member support and have no access to the TalkTalk internal systems.
We do obscure any personally identifiable data and it's your choice of what other details you show. Sender host names, SPF records and IP addresses are public for recipients and obviously key to assessment of deliverability but you can leave these to the official TalkTalk Support team if you wish. Their names are in Red and suffixed by -TalkTalk.
on 31-08-2021 04:58 PM
Hi Gondola, thanks for your reply.
The IP blocks (old and new) are in our incident ticket (210825-000560). I'm reluctant to put too much information here being as it's public forums.
But can you just confirm that the incident report is still open please? I do appreciate that we've just had a bank holiday weekend, but the ticket was created last Wednesday evening and I'm not familiar with what the average TalkTalk response time is. I was also unsure if the ticket was still open as the wording suggested to come and talk here instead.
on 31-08-2021 04:30 PM
Good to know that SPF records are in place, DKIM signing is active and DMARC reporting is set up. Normally, this would be sufficient to authenticate the incoming mail but the bounce back error does suggest that the CloudMark system thinks there's something suspect about the IP address or content that requires deferral for inspection.
As you say, could be that the IP address is flagged as previously sending spam and there hasn't been time to build your reputation for the IP address block. It's good to have a slow run-in period for new addresses to allow historic records to expire and a good reputation built.
Without any details to look at there's no more to add. This topic is in the TalkTalk workflow although I see you have already been allocated an incident number. TalkTalk Support will respond to this topic during weekday core hours 7-8am to 3-4pm.