Governor limits

System.LimitException: Too many Email Invocations: 11

Apex caps a single transaction at 10 calls to `Messaging.sendEmail`. The cap counts the **number of method calls**, not the number of recipients — one `sendEmail` with 100 messages is fine; ten calls with 1 message each, then an eleventh = boom.

Also seen asToo many Email Invocations: 11·Too many Email Invocations·email invocation limit

The email-invocation governor is one of the more confusing because it sounds like a recipient cap but is really a method-call cap. The platform doesn't care how many emails you send in one go; it cares how often you ask the platform to send.

What counts

Messaging.sendEmail(emailList);   // 1 invocation, regardless of emailList.size()

for (Email e : emailList) Messaging.sendEmail(new List<Email>{e});   // N invocations

The first is 1 invocation, can include up to 5,000 recipients per transaction. The second is N invocations and fails on the 11th.

The fix

Always batch. Build the list, send once at the end:

List<Messaging.SingleEmailMessage> emails = new List<Messaging.SingleEmailMessage>();
for (Contact c : contacts) {
    Messaging.SingleEmailMessage m = new Messaging.SingleEmailMessage();
    m.setToAddresses(new String[]{c.Email});
    m.setSubject('Hello');
    m.setPlainTextBody('Body');
    emails.add(m);
}
if (!emails.isEmpty()) Messaging.sendEmail(emails);

One sendEmail call, all the emails go out, no governor problem.

The other email caps to know

These are independent governors:

Cap	Limit
`Messaging.sendEmail` invocations per transaction	10
Single-email messages per `sendEmail` call	100
Mass-email recipients per day, org-wide	5,000 (varies by edition; up to 1,000 for Developer Edition)
`Messaging.SingleEmailMessage.toAddresses` array size	100
`Messaging.SingleEmailMessage.ccAddresses` size	25
`Messaging.SingleEmailMessage.bccAddresses` size	25

Hit any of these and you get a slightly different error message but a similar shape of bug.

When you really need many invocations

You can't get past 10 per transaction. But each async context resets the governor:

A queueable invocation starts with 10
A batch chunk's execute() starts with 10
A @future method starts with 10

So a background job that sends 1,000 emails should be a queueable that batches 1,000 emails into one sendEmail call (which fits under the 5,000-org-wide-cap on Developer Edition, more on others).

A diagnostic

System.debug('Email invocations: ' +
    Limits.getEmailInvocations() + ' / ' + Limits.getLimitEmailInvocations());

Print before each sendEmail to find which call hits 11.

A gotcha: workflow email alerts count

If your Apex DML triggers a workflow email alert, that counts as an email invocation in your transaction's budget. So your code might invoke sendEmail only 5 times directly, but workflow rules invoke 6 more, for an 11th. Check the workflow rule history if you're under the direct-invocation count but still failing.