Is there a limit to number of recipients on an email?

[#1]

Q1 Is there a limit to number of recipients on an email?

I have searched for answers to this and found two answers; either 200 or 250.

I'm using Outlook as a client and the usual plus net relay server.

I have a distribution list with 210 recipients and some of the recipients are claiming not to receive the emails.  Though this appears to be random, i.e. not always the same people.  Of course there could be other reasons such as spam filtering at the receiving end, accidental deletion etc.

I am not receiving any messages back to indicate that a maximum has been reached.

Q2. If a limit was reached should I be informed?

Thanks . . Paul

P.S. the email is non-profit making regarding a community choir and has a click to unsubscribe section in the footer and all the recipients are in the bcc field.

[#2]

Hi Paul,

There is an addresses limit both in terms of the number of addresses per message and total addressees per hour. Falling foul if that usually happens at the point of sending and gives a clear error message.

Too many addressees error message can be given for other exception event as well (I’ve just raised one such to support).

There are also conditions where some email service providers have refused to accept delivery attempts (see the Gmail issue - now fixed, BT Internet service issues and a passing one fr Outlook.com). In such circumstances nondelivery or delayed delivery messages might not be generated.

It would be helpful to identify the email service providers of those who report not having received the email (is there a common ISP theme?). You should try sending an email to just those reporting issues and use delivery & read confirmation notifications.

[#3]

Is there a common factor like this - I sent about 30 club members an email, all listed alphabetically in a Bcc: and because replies were invited but not compulsory I don't know exactly how many were or were not delivered, but I do know eight were bounced back to me and every one had all been addressed to @BTinternet.com except one member's that had a different BT domain.

The undeliverable notices bringing them back to me mostly had a common code, 550, then

    Message rejected for policy reasons (1.1.1.2)

Then there was advice obviously meant to be helpful -

     Please refine your SPF record for source address using best practice.

Below that there was a reference to jargon-full 'Guide for Bulk Senders' that I found was aimed at reducing/eliminating spam but obviously meant for savvy security or comms professionals.  Since they use acronymns without apology they were no help to me. 

I am hoping this contribution today will encourage somebody to tell me what an SPF record is, and maybe help other victims too!

[#4]

@cooltona 

A Sender Policy Framework (SPF) record is a DNS record that identifies specific mail servers that are allowed to send email on behalf of your domain.

When you send an email out, the recipients's server will ask the following questions:

Who sent this email?

Does the sender have permission to send on behalf of this domain?

Say for example, the "who" is support@domain.com and the "sender" is a PlusNet mail server. Without an SPF record specifying PlusNet as an approved sender, it's likely your email will be marked as spam. If there is an SPF record that includes PlusNet as an approved sender, then it's virtually guaranteed to skip the spam filter. That's why this is so important!

Is the email address you are sending from a <username>.plus.com address or do you have your own domain ?

and, just to confirm,  you are sending mail via the Plusnet server (relay.plus.net) ?

[#5]

Many Thanks, MisterW.

Very clear.  I wonder where I should have come across such vital information. After all, spam has been a problem for decades.

At first reading, I was surprised that relay.plus.net has handled emails from a variety of originating domains for me for years without getting into trouble with the emails hosted outside PlusNet !  Then I realised that none of those domains had ever handled significant numbers of addresses per message.

The explanation for the problem with the club's messages is probably that its host doesn't insist on SSL for our site and I chose the host's simpler option to save a fee thinking, "Who would need secure messaging for a gardening club's communications?"

My own fault!