Can you send an email course from Gmail?

What Google publishes as a sending limit

Start with the figures, because most of the advice on this subject is written as though they were secret. A personal gmail.com account may send to no more than 500 recipients in a single message and no more than 500 messages in a day. A Google Workspace account is allowed 2,000 messages a day, reduced to 500 while the subscription is still on a trial, and Gmail’s own mail merge feature is capped lower again at 1,500.

Two details matter more than the headline numbers. For a Workspace account Google states outright that the daily limits are applied over a rolling 24-hour period rather than at a set time of day, so there is no morning on which your allowance comes back all at once; for a personal account it publishes no such sentence, and the only figure it gives is how long you are blocked for. And reaching a limit produces no warning: it produces an error and a block on sending that lasts up to a day. Mail keeps arriving, the account is otherwise untouched, and nothing you try to send leaves. That is an inconvenience on a Tuesday and something else entirely in the middle of a launch.

For a course, those allowances are less generous than they look, because a course multiplies. Four hundred subscribers on a five-day course is not four hundred messages — it is four hundred a day for five days, arriving on top of everything else you send from the same account, and it grows every time somebody new signs up.

Why the cap is the least of the problem

A mailbox sends messages. A course sends a schedule, and the schedule is different for every reader, because day one starts on the day that person confirmed rather than on a date in your calendar. On any given morning you are therefore sending day one to the people who joined yesterday, day three to the people who joined on Monday, and day five to somebody who joined last week — three different messages to three different groups, computed fresh every day, for as long as the sign-up form stays up.

Done by hand, that is a spreadsheet of who is on which day, five decisions every morning, and no margin for the morning you are ill or travelling or simply forget. The failure modes are not dramatic and they are all silent: somebody gets day three twice, somebody else never gets day four, somebody who signed up on the day you were away starts two days late and every subsequent message refers to a lesson they have not seen.

A mail merge does not fix this, because a merge is a broadcast with the names filled in. It sends one message to many people at once, which is the shape a course specifically is not. The merge would have to be run five times a day against five different lists that you maintain by hand, and the maintenance is the entire job.

The six mechanisms a mailbox does not have

Underneath the scheduling there is a set of machinery that nobody thinks about until it is missing, because in a sending tool it is simply there. A mailbox has none of it, and each piece is the kind of thing that costs nothing until the day it costs a great deal.

What a course needs and a mailbox does not provide:

• A confirmation step. An address typed into a form is unverified until somebody clicks a link sent to it, and a mailbox will happily send five days of mail to a typo, to a misdirected address, or to somebody who was signed up by a third party.
• A suppression list. Unsubscribes and complaints have to be recorded somewhere that is checked before the next send, automatically. In a mailbox that record is your memory, and your memory is what sends day four to somebody who left after day three.
• One-click unsubscribe in the headers. Google’s sender guidelines ask for it on marketing and subscription mail, alongside a visible unsubscribe link in the body, and Yahoo’s sender best practices ask for unsubscribes to be honoured within two days. A mail client composing an ordinary message sets no such header.
• Bounce handling. A permanent refusal has to take that address out of every future send. Handled by hand, the bounces pile up in a folder you stop reading, and repeated mail to dead addresses is one of the clearest signals of a sender who does not clean a list.
• A consent record: what the person was shown, when they submitted the form, and when they clicked to confirm. A sent-mail folder is not that record, and reconstructing one two years later from a mailbox is not a thing that can be done.
• A footer that carries an unsubscribe link and a postal address. The CAN-SPAM rules require the address in commercial mail and there is nothing in a mail client that will put it there for you, on every message, without being remembered each time.

Whose reputation you are spending

Mail sent from your mailbox goes out under the identity you use for everything else. That is the address clients reply to, the domain your invoices are sent from, and the domain your password resets arrive on, and a mailbox provider does not hold one reputation for your correspondence and a separate one for your course. Complaints from a course land on the same identity, and so does any consequence of them.

This is the real argument for sending a list from a subdomain reserved for it. A subdomain that gets into trouble can be retired in an afternoon and the trouble stays with it; a root domain that gets into trouble takes the rest of your mail with it, and there is no way to retire the domain your business is named after. The same logic applies to the sending account: a 24-hour block for hitting a limit does not stop only the course, it stops every message you were going to send that day.

Authentication is where the two halves meet. Google, Yahoo and Microsoft now all expect SPF, DKIM and a published DMARC policy from anyone sending in volume to their users, and Microsoft’s requirements for high-volume senders refuse non-compliant mail outright rather than filing it. A mailbox on a well-run provider is authenticated for that provider’s domain, which is exactly the thing that stops being true the moment you start sending on behalf of a list from your own.

What a mail merge add-on changes, and what it does not

There are many add-ons that will send a merged message from your Gmail account and record who opened it, and some of them are good at that job. What none of them can change is the account they are sending through. Your limits are still your limits, the identity is still yours, and the 24-hour block for exceeding an allowance is still a block on your own mail. The automation is of the typing rather than of the obligations.

Rather than name products, which change between versions and would be out of date here without anybody noticing, it is more useful to ask five questions of whichever one you are considering. Does it count days from each subscriber’s own confirmation, or does it send to a list on a date? Does it require a confirmation click before the first message? Does it keep a suppression list and check it before every send? Does it set the one-click unsubscribe headers, or only insert a link? And can it send from a domain you control rather than from your mailbox, so that the reputation is somewhere you can retire?

An add-on that answers all five is not really an add-on any more: it is a sending platform that happens to have a button inside a mail client. That is a perfectly good thing to use. The point is to know which of the two you have bought, because the difference only becomes visible on the day something goes wrong.

What sending by hand is genuinely good for

None of this means a mailbox is the wrong tool for the first ten readers, and there is a real argument that it is the right one. Writing five lessons for people whose names you know, sending each one yourself on the morning it is due, and reading every reply is the fastest way to discover that day three is boring, that day two asks for something nobody has time to do, and that the promise you made on the sign-up form was not the promise people thought they were accepting.

That is a research exercise rather than a distribution one, and its whole value is that it does not scale: you are doing it precisely because you are small enough to read everything that comes back. A cohort you invited personally, a workshop group, a handful of clients — for those, a mailbox, a calendar reminder and a short list is a defensible way to run the first round, and it costs nothing.

It stops being defensible the moment there is a form on a website. At that point you are accepting addresses from strangers, which means you owe them a confirmation step, a working unsubscribe, a record of what they agreed to, and a schedule that does not depend on you being at a desk. That is the line, and it is about obligations rather than about volume.

The three signs it is time to move, and what to take

The signs are specific. You are keeping a list of who is on which day somewhere outside the mail client. You have sent somebody the wrong lesson, or nothing at all, and found out from them rather than from a report. Or you have put a sign-up form on a page, which means addresses now arrive while you are asleep. Any one of those is the point at which the work of doing it by hand has passed the cost of not doing it by hand.

What to take with you is more than the addresses. Export the dates: when each person signed up, where they signed up, and when they confirmed, because that is the consent record and it is the part that cannot be reconstructed afterwards. Take the suppression list — everyone who asked to stop and everyone who complained — and load it before you load a single subscriber. And take the bounces, so that a new tool does not spend its first send rediscovering which addresses are dead.

Then judge whatever you move to on the five questions above rather than on a feature list. The ones that matter are whether the timing is counted from the reader rather than from a date, whether confirmation is enforced on every route in rather than offered as a setting, whether the unsubscribe is in the headers and not only in the footer, and whether you can send from a domain of your own. Everything else on a comparison page is a preference.