DMARC and DKIM settings

[Angela91]

Once again, email from a dsl.pipex.com account (of nearly 30 years of use and bill payments) does not reach the recipient on a gmail.com address due to the receiving domain's DMARC policy.

TalkTalk don't seem to have grasped the importance of DMARC and DKIM records, or at least they don't seem to have bothered with them for the "smaller" unsupported domains. This means that a lot of email leaving TalkTalk, particularly from the domains which it bought and promised to maintain in perpetuity, doesn't always make it to its destination untouched by spam filters. Google, for instance, recently upped their checks and will often sideline emails into their  Spam folder from servers that don't have DMARC and DKIM records .

TalkTalk, please, please will you get this fixed.  It should be a one off fix but bring enduring benefit to your poor customers.

[Ady-TalkTalk]

Hi Angela91, please send me a personal message including your affected email address. The email address you registered on here with is showing no failures. 

Ady

[Ady-TalkTalk]

Hi pbar100, I'm told the only rejects against your dsl.pipex address are the forwarded ones. 

Ady

[pbar100]

Okie doke, thanks Ady. Take care.

[Ady-TalkTalk]

Hi all, I've passed on your comments and will let you know what comes back.

Ady

[pbar100]

Hi Angela, I can understand it must be very frustrating and disruptive for you, in the capacities you mention. I recall some years ago Ady proclaiming that once migration is done there will be no more pipex issues as everyone will be on equal systems. And here we are with another pipex issue 🙂

I usually work around talk talk problems and failed mails using alternative methods, in all the years I've been with them I've never been able to use them 100%, always had to have other methods at hand for situations like this. It would be nice to have this issue fixed though but I think we all know it's unlikely.

Just to clarify, the DMARC thread I started, is also using talk talk settings completely, and their recommended settings at that.

We live in hope. Thanks.

[Angela91]

Thanks for replying and showing TT that I am not on my own here.  However I do not have my own domain.  I use a domain owned and administered by TT.  I use their recommended settings at every point.  The main point is that, yet again, changes have been made which have not been fully tested for their impact on all domains run by TT.  And we spend weeks, often months, not receiving email or not getting email to its intended destination.  I have recently had cases where people with whom I have been corresponding for at least 4 years are no longer getting my emails, even when I reply to one of theirs.  At best it goes into their Junk folder because Google or BT have tightened their policy on absent DMARC records, at worst it goes into the ether and they think I have not replied.  Since I volunteer for a couple of charities, correspond regularly with the Home Office and other organisations, this is hugely inconvenient and occasionally embarrassing.  

[pbar100]

Hi, to some degree your issue mirrors mine. I too have my own domain and on my phone have always used my domain email as the sent address using talk talk SMTP settings. This has worked fine for years but a few days ago it stopped working unless I set up another account using the dsl.pipex.com address as the sender, just as you're describing actually. So yes they have been messing with something.

However this doesn't explain the issue in the DMARC thread I've started when sending from my desktop PC.

[fmob22]

I'm sorry, that's probably my fault 😮 The error I included in my post mentioned mail147c50.megamailservers.eu. There's a reason for this...

I have a domain, lets say mydomain.com. I use the email address me@mydomain.com which is mapped to a dsl.pipex.com address via an alias at my hosting company. So the email leaves Thunderbird using the TT smtp server but gets passed around a bit.

I think someone has been messing with settings somewhere though. As of today, I can't send emails from Thunderbird with my email address set to me@mydomain.com - I get this warning: "Sender address rejected: not owned by user 3@10880114.". So now I have set the sending email address to me@dsl.pipex.com to be able to send emails! I wish I'd never said anything now....

[pbar100]

I know, I'm as stunned as you are. You just know that when tech support staff say something like that it won't get fixed.

Anyway yes I'm also sending from talk talk servers using the recommended settings.

Thanks.

[Angela91]

Surely an increase of messages in a thread shows that multiple people have the same concern and should therefore be pushing the thread UP the priority list.  Failing to understand the process criteria here and know that it is nothing like when I ran a Helpdesk.  (Apart from the fact that we were customer-centric, sought to understand the issue, diagnose and resolve it.  Except that for TT the customer has more understanding and has done the diagnosis so that leaves the matter of resolving to the customers' satisfaction.)  Over to you TT.  Please don't tell me I am not using your settings when my outbound mail is using smtp.talktalk.net.

[Angela91]

Ady, unbelievable response!!
If smtp.talktalk.net is not a TT server, I am not sure what is.

[Ady-TalkTalk]

Hi all, the email team have said you need to be sending from the TalkTalk email servers. Currently it seems you aren't. 

Email Settings can be found in the Email Settings Help Article. 

Ady

[Ady-TalkTalk]

Hi all, each post on the thread pushes the thread back down the queue so I can only apologise for the delay in getting back to you. I've sent another chase to the email team to ask them to investigate. I'll let you know what I hear back.

Ady

[pbar100]

On Angela's suggestion, I too have started a thread with my DMARC issue. Would be nice to have this problem sorted for sure. Thanks.

[fmob22]

Well that stirred things up a bit... It's a shame issues happen 24 hours a day,  7 days a week and not just when support are in the office 🤣

Recent error message (email address redacted):-

Reporting-MTA: dns; mail147c50.megamailservers.eu

Received-From-MTA: DNS; localhost

Arrival-Date: Fri, 1 Nov 2024 16:27:00 +0000

Final-Recipient: RFC822; XXXXX@dsl.pipex.com

Action: failed

Status: 5.2.0

Remote-MTA: DNS; mx.talktalk.net

Diagnostic-Code: @dsl.pipex.com; 552 5.2.0 6uUGtmNPqOh4A6uUGtq2QJ DMARC Verification Failed (TT602)

Last-Attempt-Date: Fri, 1 Nov 2024 16:27:02 +0000

[Angela91]

That Monday did not have a date on it!  Perhaps we can agree that Monday 4 November will be the date that this gets fixed if it has to be a Monday.

[Angela91]

So Ady, the customer suffers, flags the problem, diagnoses the problem, advises TT of the remedy.  All TT has to do is implement the fix.  What is taking so long?  OTP were reaching me until approx. 10 October.  TT changes have again broken more than any much-needed improvements they might have been trying to deliver.  Please get this fixed.

[Angela91]

Great question?  Please keep posting and try and get TT's attention and the problem fixed

[Angela91]

The thread has been open for a long enough that it is quite reasonable to ask at any time, what TT might be doing about it.  This is a long standing issue and emails are not reaching their intended recipients whether inbound to a TT customer or from a PIPEX address to long-standing correspondents.  It was the last straw when TT managed to stop one time passcodes from reaching their destination last weekend.  This had been working up until 10 October so unnecessary, un-thought through, undoubtedly untested changes have been made to mail servers.  Why is left to the long-suffering customers to not only flag the incident, but also diagnose it and point out the remedy?

[Divsec]

Hi @Angela91  great suggestion. Let's hope the others take the advice!