email to icloud

[#1]

Having previously had problems sending to gmail addresses, which I managed to fix following good advice from this forum, I now find I can't send email to icloud.com email addresses.

I have tried sending from both Outlook and Apple mail clients.

Messages are bounced with the message:

This is an automatically generated Delivery Status Notification.     

Delivery to the following recipients failed permanently:

   * somebody@icloud.com

Reason: A message that you sent to the following recipient could not be delivered due to a permanent error. ** The remote server ?? responded with: ** somebody@icloud.com ??:?? This message was created automatically by mail delivery software on the server .

Included with the bounce email is a text file reading in part:

Diagnostic-Code: smtp; 554 5.7.1 [HM08] Message rejected due to local policy. Please visit https://support.apple.com/en-us/HT204137

The Apple webpage referenced is about bulk mail policies.

I deduce from this that something in the Plusnet email world is violating Apple policies in some way.

Can anyone throw light on what is going on, and what I can do to cure the problem?

Many thanks,

David

[#2]

Exact same problem since Saturday 9 June 2024

[#3]

@bathplug 

You have provided very little information to enable anyone to assist you.  The key considerations are...

• What sending address are you using @*.plus.com or @yourowndomain.co.uk
• Are you connecting over Plusnet broadband or some other provider
• Are you on a static IP address
• Is the SMTP connection authenticated

"Bulk email" can refer to the total sum of all email coming from the primary domain so @you.plus.com and @me.plus.com might all be considered to be from @plus.com

Reading the link you provided points to a multitude of considerations:

• for sending from @*.plus.com DKIM is implemented by default
• if you are sending from your own domain, SPF will be required (this can be fixed for the Plusnet email brand but not the others)
• if you are sending from your own domain name, the rDNS could be a consideration

After all of that there remains the possibility that iCloud has simply screwed up - from that link...

"We do our best to ensure that all legitimate and wanted emails get to our users, but occasionally those emails might be filtered as junk."

[#4]

Thanks Townman, not least for reminding me to update my post.

This problem went away of its own accord after a couple of days, so its cause will remain a mystery.

For the record, I was sending from @mydomain.com over Plusnet broadband using a dynamic IP address and with SMTP authenticated.  SPF is enabled.

[#5]

That being the case, I would suspect that the dynamic IP address had been deemed compromised and black-balled for a while.

Is @mydomain.com hosted (registered) by Plusnet or is it a third-party domain name pointed at Plusnet's mail servers?

[#6]

It's a Fasthosts registered domain, pointing at Plusnet mail servers.

[#7]

So the SPF record in FastHosts needs to reference Plusnet’s SMTP servers.

You can probably set up a DKIM and DMARC record there too.

… or you could send your email via their SMTP servers.

[#8]

You can probably set up a DKIM and DMARC record there too.

DKIM is not going to work, the Plusnet servers won't have the private key to sign outgoing mail.

[#9]

Thanks.

I'm getting to the outer edge of my knowledge of email here!

Do you mean that if I use Plusnet as my SMTP server I cannot make use of DKIM at all?  If so, what is the implication of that?

Thanks again,

David

[#10]

Do you mean that if I use Plusnet as my SMTP server I cannot make use of DKIM at all?

@bathplug for your own domain, yes!.  DKIM requires that the sending server holds the private key for signing outgoing mail and your domain DNS publishes the public key to allow receiving servers to check the signature. There's no way you can provide the private key to the PN servers.

If so, what is the implication of that?

Provided you have a valid SPF record covering the Plusnet servers, then there should be little implication to not using DKIM.