Designing Bulk Email for Small Businesses Without Locking Into a Specific Service

· · Email Delivery, Legacy Asset Reuse, Inquiry Flow, Web & SEO, B2B

“We want to send announcement email to dozens or hundreds of recipients using our existing domain and site, without adding yet another dedicated newsletter service.” The realistic answer to this request is not a single Bcc blast but a small delivery foundation with per-recipient individual sending, subscription management, unsubscribes, and SPF / DKIM / DMARC in place.

“Not using a specific service” here does not mean “using nothing.” It means keeping the SMTP standard, the subscriber list, the templates, and the unsubscribe path on your own side, and structuring things so that only the sending mechanism can be swapped out later.

Also, this article assumes email sent to people with whom some relationship or consent exists — existing customers, members, people who requested materials, newsletter subscribers. It is not about harvesting public addresses and sending indiscriminately. Advertising and promotional email carries legal preconditions, and from a deliverability standpoint that approach does not last either.12

What follows is based on public Japanese government information around the Act on Regulation of Transmission of Specified Electronic Mail and the sender guidelines from Google / Yahoo / Outlook, as verifiable as of April 2026.12345

1. The Conclusion First

The realistic shape for a small business sending outward-facing bulk email comes down to roughly these four points.

  1. Send individually, per recipient Rather than piling addresses into Bcc, build the queue on the assumption of sending one message at a time.
  2. Own the subscription state yourself Keep explicit state management such as active, unsubscribed, bounced in your own DB or CSV.
  3. Accept unsubscribes automatically Do not run an operation where “please stop emailing me” is processed by hand. Include a visible link in the body, and where possible List-Unsubscribe.345
  4. Authenticate the sending domain Put SPF / DKIM / DMARC, reverse PTR, and TLS in place. Even if the mail goes out, without these it struggles to arrive.345

In short, this is not a question of mail-client operation; it is a question of delivery infrastructure.

If you interpret the requirement “we want to send to everyone at once” as stacking lots of addresses into To / Cc / Bcc, it falls apart. What you actually need is a mechanism for:

  • Who may be sent to
  • Who must no longer be sent to
  • For what purpose consent was obtained
  • How unsubscribes are received
  • Whether the configuration makes you trustworthy as a sender

2. Why a Single Bcc Blast Is Not Enough

What makes Bcc painful for outward-facing bulk sending is that, despite looking easy, it gives you none of the operational substance.

Problem What happens The later pain
Unsubscribes cannot be tracked “Stop emailing me” arrives by reply or phone Easy to missend on the next run
No bounce management You keep sending to nonexistent addresses Reputation degrades easily
No record of consent You cannot explain when and where consent was given Weak in legal and complaint handling
Message types get mixed Sales mail and notification mail go out from the same box Easy to drag day-to-day order/billing mail into the blast radius
No control over rate Easy to send in one big burst Easy to hit throttles or spam filtering
Dependent on one person Runs on a personal mailer and personal labor Hard to hand over

What is especially dangerous is that “sending” works, so it looks like a functioning system. In reality, with no suppression, no bounce control, no consent records, and no send logs, the manual operation collapses the moment the list grows a little.

Bcc is not entirely bad. For internal communication, very small announcements to a closed membership, or a one-off note to stakeholders, it can be fine. The point is that it is weak as the foundation of a system that continually sends to external customers and prospects.

3. What “Not Using a Specific Service” Realistically Means

The easy misunderstanding here is that “not using a specific service” = “doing everything by hand.”

In practice, if you own these three things yourself, you avoid most vendor lock-in.

3.1 What you should own

  • Subscriber data
    • Email address
    • Consent timestamp
    • Consent source
    • Delivery category
    • Unsubscribe state
  • Delivery rules
    • What gets sent to whom
    • At what rate
    • How bounces and unsubscribes are reflected
  • Sender identity
    • Sending domain
    • SPF / DKIM / DMARC
    • An address that can receive replies
    • The unsubscribe URL

3.2 What may be swapped out

  • The SMTP relay that actually transmits
  • How the admin screen is implemented
  • Where the send queue is implemented
  • Where logs are stored

In other words, the essence of “not using a service” is not surrendering your sending rules and state to the other side.

  • The recipient list lives in your own DB
  • The unsubscribe URL lives under your own domain
  • You own the subject and body templates
  • Only the SMTP egress can be swapped later

In this shape, you can start with your existing mail infrastructure and move to a different sending mechanism later.

4. A Realistic Setup for a Small Business

4.1 The minimum components

At dozens to hundreds of messages per run, you do not need anything grandiose from the start. But it is more stable to keep at least these separated.

  1. Subscriber table
  2. Suppression table
    • Unsubscribes
    • Hard bounces
    • Complaints
  3. Delivery templates
    • Subject
    • Body (HTML / text)
    • Delivery category
  4. Send queue
    • Per-recipient state
    • Send result
    • Retry count
  5. SMTP relay
    • Use the existing mail infrastructure, or
    • run your own server
  6. Logs
    • When and to whom you sent
    • Success / failure
    • Suppression / bounce updates

Sophisticated open-rate and click-rate measurement is not required from day one. What is needed first is the ability to send safely, stop, and explain yourself.

4.2 Fields the recipient table should carry

The minimum set looks like this.

Field Example Reason
email user@example.com The recipient itself
status active / unsubscribed / bounced To judge whether sending is allowed
consent_at 2026-03-20 12:34:56 To record when consent was obtained
consent_source form / trade show / existing contract / manual entry To explain where the address came from
consent_purpose newsletter / seminar announcements / maintenance info To record what delivery was consented to
unsubscribed_at 2026-03-29 09:10:11 Evidence of the unsubscribe
last_bounce_at 2026-03-30 08:00:00 Needed to decide on resend suppression
notes via account rep / existing customer Supplementary information

Even if your initial master list is an Excel sheet or an existing customer ledger, it is worth separating things to this degree. What matters most is that the suppression information always wins.

For example, even if the person’s address remains in the sales ledger, do not send if the suppression table says unsubscribed. Without this rule, addresses re-enter via another route after an unsubscribe and you have an incident.

4.3 Architecture diagram

Website / subscription formSubscriber tableExisting customer ledger / member ledgerDelivery templatessubject / HTML / textSend queueSuppression tableunsubscribes / bounces / complaintsSMTP relayexisting mail infrastructure or own relayRecipientsUnsubscribe URLRepliesBounces / complaintsOperations contactSPF / DKIM / DMARC / PTR / TLS

The point of this diagram is that the sending mechanism is not the center. The center is the subscriber table, the suppression table, and the send queue.

The SMTP relay is merely the egress. With this separation, you can switch sending mechanisms in the future without losing past unsubscribes and consent history.

5. How Much to Build, by Scale

5.1 Once a month, dozens of recipients

At this scale, the minimum setup is often enough.

  • A dedicated mail-merge template for sending
  • Per-recipient individual sending
  • An unsubscribe URL
  • Saved send logs
  • SPF / DKIM / DMARC in place

The point here is not falling back to Bcc just because the list is small. Even under 50 recipients, for continual outward-facing delivery it pays to adopt the individual sending + state management shape now.

5.2 Several times a month, hundreds of recipients

At this stage, a few additions make things more stable.

  • A send queue
  • Send-rate control
  • Bounce processing
  • Immediate application of unsubscribes
  • A dedicated sending subdomain
  • An approval flow
    • Test send
    • Production send
    • Result review

It also matters to separate day-to-day human email from promotional and announcement email. Google describes separating From addresses and IPs by message type, and Yahoo likewise advises not mixing bulk / marketing with transactional / alerts on the same IP or DKIM domain.34

For example, just splitting addresses by purpose tidies operations considerably.345

  • Order confirmations and billing: billing@example.com
  • Outage notices and maintenance info: notice@example.com
  • Newsletter and announcements: news@example.com

5.3 Approaching thousands per day

By this point, “not using a specific service” easily becomes an end in itself.

For Gmail, Google spells out requirements for senders of more than 5,000 messages per day: SPF / DKIM / DMARC, From-domain alignment, one-click unsubscribe, and more. Outlook likewise requires SPF / DKIM / DMARC for domains sending more than 5,000 messages per day and advises that non-compliant messages can be junked or rejected.35

At this scale, the operational topics also change.

  • IP reputation
  • Complaint rate
  • Bounce rate
  • Unsubscribe processing
  • How to ramp up volume
  • Monitoring

At this stage, there are many situations where a dedicated service is actually cheaper.

So the conclusion of this article is not “build everything yourself at any scale” but rather: at the scale of dozens to hundreds per run, a small delivery foundation where you own the state and the rules is just right.

Advertising and promotional email requires prior consent as a rule. The Japanese Anti-Spam Consultation Center’s guidance also states that sending advertising email without prior consent is, in principle, not permitted.2

Google and Yahoo likewise require sending only mail the recipient explicitly asked for, not using purchased lists, and avoiding pre-checked opt-in boxes.34

The minimum you want to retain in practice is:

  • Consent timestamp
  • Consent source
  • What delivery it covers
  • The explanatory copy
  • The screen or text through which consent was obtained

Note that the law does carry an exception for sending to business addresses published on a website. However, building your delivery foundation on that exception is not recommended. By every measure — complaints, deliverability, reputation, actual response rates — it does not hold up for long.2

6.2 Mandatory disclosures and unsubscribes

Even when sending to consenting recipients, senders have disclosure obligations. Per the Anti-Spam Consultation Center’s guidance, at least the following information is required.2

  • The name of the sender (person or entity)
  • An email address or URL for receiving opt-out notices
  • A statement that the recipient can opt out
  • The sender’s postal address
  • A contact point for complaints and inquiries

So the footer needs at minimum something like this.

Sender: Example Corp.
Unsubscribe: https://example.com/unsubscribe/xxxxx
If you wish to stop receiving these emails, please use the URL above.
Address: Tokyo, ...
Contact: support@example.com

In addition, the major receivers care a great deal about how easy unsubscribing is.

  • Google: requires one-click unsubscribe for bulk senders3
  • Yahoo: requires / recommends List-Unsubscribe plus an in-body link, honored within 2 days4
  • Outlook: recommends an easy-to-find, functioning unsubscribe5

So the natural baseline is a visible link in the body, plus, where possible, these headers.34

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 Authentication and deliverability

The major receivers already assume not “that you can send” but “that you are authenticated.”

Google’s public guidelines require the following.3

  • All senders: SPF or DKIM, PTR (matching forward / reverse DNS), TLS
  • Bulk senders: SPF + DKIM + DMARC, From-domain alignment
  • A low spam rate
  • One-click unsubscribe for bulk senders

Yahoo’s requirements:4

  • SPF / DKIM / DMARC
  • DMARC alignment
  • Valid forward / reverse DNS
  • Unsubscribe
  • Spam rate under 0.3%
  • Opt-in
  • Separation of bulk and transactional

Outlook also publishes requirements for high-volume senders.5

  • SPF pass
  • DKIM pass
  • DMARC (at least p=none, aligned with SPF or DKIM)
  • A genuine From / Reply-To
  • Unsubscribe
  • List hygiene

The minimum operational checks, in a table:

Item Minimum action Purpose
Sending domain Configure SPF / DKIM / DMARC Prevent spoofing, improve deliverability
Sending server A stable environment with resolvable PTR; use TLS Avoid losing the receiver’s trust
From / Reply-To A real address that can receive replies Be able to receive complaints and stop requests
Unsubscribe In-body link + List-Unsubscribe Lower the complaint rate
List quality Opt-in only, purge invalid addresses Protect reputation
Send rate Ramp steadily, never in bursts Avoid throttles and spam classification
Monitoring Watch bounces / spam rate / complaints Stop deterioration early

Google recommends ramping volume starting low, to engaged recipients, at a steady pace. Sudden spikes and overnight doublings tend to cause throttling and reputation loss.3

7. How to Proceed with Implementation

For a minimal start, a realistic order looks like this.

  1. Separate the kinds of mail you send
    • Notification mail
    • Newsletter
    • Seminar announcements
    • Announcements to existing customers
  2. Build a subscription form or consent-capture flow Make it possible to capture consent on the website alongside explanatory copy. It matters that the copy makes clear “what arrives, and how often.”4
  3. Separate the subscriber table from the suppression table Separate these first, and operations stay intact no matter what you migrate to later.
  4. Choose a dedicated sending domain / subdomain For example news.example.com or mail.example.com. At minimum, do not mix responsibilities with day-to-day order traffic and personal mailboxes.34
  5. Put SPF / DKIM / DMARC / PTR / TLS in place If you send yourself, this is the top priority. Do not make an environment without reverse DNS your sending foundation.34
  6. Build an admin screen — small is fine What you need is not a fancy UI but these functions:
    • Subject editing
    • Body editing
    • Test send
    • Production send
    • Recipient preview
    • Batch-size setting
    • Result review
  7. Start with small volumes Narrow to existing customers and engaged subscribers, and send at a steady pace. If nothing goes wrong, widen the audience.3
  8. Apply unsubscribes and bounces as the top priority Confirm this works before worrying about open rates.

In this order, you arrive not at “we can technically send” but at “we can keep going without incidents.”

If the review extends to the subscription form, consent copy, and unsubscribe page, it is easiest to organize together with website development. If, on the other hand, the premise is connecting to an existing customer ledger, internal systems, or Windows tools, it is safer to start from responsibility splitting in a technical consultation / design review.

8. Common Failures

The usual suspects are these.

  • Running human day-to-day mail and promotional/announcement mail from the same sender
  • Managing consent only as free-text notes
  • Handling unsubscribes manually via email replies
  • Dumping in an old business-card list wholesale
  • Suddenly sending at the largest volume ever
  • Mixing promotional copy into notification mail
  • Stopping at “the send API returned success” as the send result
  • A suppression table weaker than the existing customer ledger

The last one in particular causes real incidents.

An address remains in the sales side’s Excel sheet. But that person has already unsubscribed from the newsletter. Unless the rule is that the suppression information always wins, they will be re-sent again and again via other routes.

9. Summary

If a small business wants to email a reasonably large audience without a specific service, the question to think about is not “which button to press.”

What is truly needed is these five things.

  • Per-recipient individual sending, not a single Bcc blast
  • A subscriber table and a suppression table
  • A path that accepts unsubscribes automatically
  • SPF / DKIM / DMARC / PTR / TLS
  • An operation that separates notifications from promotions

In the end, owning the sending rules comes before owning the sending mechanism.

At dozens to hundreds per run, you can run perfectly well without a dedicated service. But even then, the shortcut is to design it as a small delivery foundation — not to “send in bulk from a mail client.”

References

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

These topic pages place the article in a broader service and decision context.

This article connects naturally to the following service pages.

Website Development

Entry-point design such as subscription forms, consent copy, unsubscribe pages, and the inquiry flow pairs well with organizing things as part of website development.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.

Back to the Blog