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, the team can see rejections and your mailbox isn't showing any. I don't what to tell you I've 3 people reporting this issue and the business isn't seeing any others. I'm happy to relay the information and continue trying to assist. The team have checked the DMARC and DKIM settings and many other Pipex customers are not experiencing issues. 

Ady

[Angela91]

Ady, not trying to be unhelpful here but it is affecting the dsl.pipex.com domain not single addresses.  The DMARC messages from Google were not seen until about October 10, suggesting that if the engineers review the change logs for that time they will find the cause of the disruption.  The same change has also caused messages to regular, existing correspondents going into their Spam folder.  They had previously been delivered without a problem.

So, as well as telling you that it is DMARC and DKIM settings, I have suggested another way for you and the TT team to research what changed on or around October 10.  Am I too naïve to think that change logs are still kept?!!

Actually, this is PIPEX Dial's 30th anniversary month - the original launch of PIPEX Solo was so that companies could view the Budget online for the first time (hosted at the time on the PIPEX Worldserver).  I look back fondly to be part of the development and implementation of what was then a cutting edge technology and has now become a utility.  Cutting edge or not, it worked then and how I long for that reliable service now.

[pbar100]

Hi Ady, that isn't the case any more than when you were told mails aren't being sent from talk talk servers. It's a DMARC issue, will be nice to be fixed one day but don't worry about it, I'm content to continue using alternatives. All the best.

[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.