Message Delivery Failure - Anyone else having problems?

[Roger1945]

@licquorice Understood - but the whole point of having a 'private' email address is that it doesn't need to change when you change ISPs. It would be tedious, if not impossible, to advise all users of my 'private' address to discard it and use the BT address instead. These have accumulated over the last 15 years and been invisibly redirected through at least 3 different ISPs in that time.

[licquorice]

@Roger1945  Exactly, you have a 'private' email address, collect it directly, not via your ISP. I'm not suggesting you use BT addresses. You don't need to forward it to anywhere if you use domain host's mail service.

[harveyzone]

---

@licquoricewrote:

@Roger1945  Exactly, you have a 'private' email address, collect it directly, not via your ISP. I'm not suggesting you use BT addresses. You don't need to forward it to anywhere if you use domain host's mail service.

---

As far as I am aware, 123 reg do not host email as part of their domain registration package. They will forward to another address, or you can update MX record to post to your own server, but they will hot host it for you to collect from them. It is an extra service (and cost) to set up EMail hosting with them.

Domain email forwarding is a fairly standard service, so should work as described.

[graywallis]

I have recently received a 'nonsense' answer to my ticket with 123reg saying all was working fine. It obviously isn't. They have recently changed the DNS pointing to my own (pretty pathetic) website, so the problem has been generated by them.

[jingars]

It is the nature of a forum thread to wander all over the place, but with regard to the initial issue with inbound email going awry this one seems to be in a loop;

1. I would like to know what changes were made by BT, as mentioned (but not detailed) earlier in this thread.

2. Can someone clarify what role the presence, absence or status of a SPF record has in the process of receiving email from third parties. I ask as all the search results I have read refer to it only having an influence on the sending of email from a domain, which seems in no way relevant to the original issue. I would like to know whether the observation from BT re SPF records is actually relevant to the original cause, or whether the talk of SPF records has actually muddied the waters.

[licquorice]

SPF, DMARC, and DKIM  credentials are all applied at the sending end to convince the receiving mail box that the mail is kosher. It is the receiving end that can reject mail if the records are missing. They are not required to send mail.

[jingars]

Thanks @licquorice. If I have understood your post correctly then it would appear SPF record configuration is irrelevant to the  original issue that I and others have experienced, specifically failures of inbound email from third parties to a BT account via a domain administered and forwarded by a third party (123 Reg). 

Put differently, "my" SPF record has a role in seeking to prevent any outbound email I might send being flagged as spam, but as these emails are inbound to me and do not purport to be from my domain then my SPF record should not be involved in any assessment by BT as to whether the inbound message is from a legitimate source (as I am the destination and not the source). 

[licquorice]

But they do purport to be from your domain as the mail is being relayed by 123 Reg, the mail is being sent from X received by Y and then sent by Y to Z.  The BT mail servers will be inspecting that the SPF record at Y (123 Reg) is good. It is your SPF record at 123 Reg that will be inspected.

[harveyzone]

---

@licquoricewrote:

SPF, DMARC, and DKIM  credentials are all applied at the sending end to convince the receiving mail box that the mail is kosher. It is the receiving end that can reject mail if the records are missing. They are not required to send mail.

---

But surely this is irrelevant here (apologies - I am not an email guru so could be completely wrong). The message failure message is "It has been in queue too long, and will not attempt delivery again." This does not sound like a rejection from the receiving end, due to suspicion of spam or forgery etc, but a time out from the sending end.

[licquorice]

Yes, having gone back to the start of the thread, it does look like the SPF record is a red herring although it is always good practice to ensure SPF, DMARC and DKIM records are in place.