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

“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.¹²

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.¹²³⁴⁵

Who this article is for, and what it assumes

Abbreviations used in this article

Here are the terms that appear from section 2 onward without further explanation.

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.³⁴⁵
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.³⁴⁵

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

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

Knowledge map for this article

For a small or midsize company to send bulk email without depending on one particular newsletter service, the realistic approach is not Bcc mass sending but keeping a delivery platform made up of a subscriber table, a suppression table, and a delivery queue in house, in a configuration where only the outbound path, the SMTP relay, can be swapped out. The suppression table gives unsubscribes and bounces priority over the subscriber table, and the delivery queue hands the send off from there to the SMTP relay. Authenticating the sending domain with SPF, DKIM, and DMARC and providing a reverse DNS PTR record and List-Unsubscribe makes it possible to meet the spam rate thresholds that Google and Yahoo require. Japan’s Act on Regulation of Transmission of Specified Electronic Mail imposes prior opt-in consent and an obligation to disclose the sender, and open source software such as listmonk implements exactly this structure in a self-hosted form.

flowchart LR
    accTitle: Bulk email delivery infrastructure
    accDescr: Diagram showing how the limits of Bcc mass sending, an in-house delivery platform built from a subscriber table, a suppression table, and a delivery queue, the choice of an SMTP relay as the outbound path, sending domain authentication with SPF, DKIM, and DMARC, and legal requirements such as opt-in consent and sender disclosure all relate to one another
    bulk_email_infrastructure["In-House Bulk Email Platform"]
    individual_send["One Email per Recipient"]
    subscriber_table["Subscriber Table"]
    suppression_table["Suppression Table"]
    delivery_queue["Delivery Queue"]
    bcc_mass_send["Bcc Mass Mailing"]
    smtp_relay["SMTP Relay"]
    m365_smtp_methods["Microsoft 365 SMTP Sending Methods"]
    spf["SPF (Sender Policy Framework)"]
    dmarc["DMARC"]
    dkim["DKIM (DomainKeys Identified Mail)"]
    reverse_dns_ptr["Reverse DNS for the Sending IP"]
    list_unsubscribe_header["List-Unsubscribe / One-Click Unsubscribe"]
    tokutei_email_law["Japan Specified Electronic Mail Act"]
    opt_in_consent["Opt-In Consent"]
    sender_display_obligation["Sender Disclosure Requirements"]
    spam_rate["Spam Complaint Rate"]
    listmonk_oss["listmonk"]
    bulk_email_infrastructure -->|"uses"| subscriber_table
    bulk_email_infrastructure -->|"uses"| suppression_table
    bulk_email_infrastructure -->|"uses"| delivery_queue
    bcc_mass_send -->|"not recommended for"| bulk_email_infrastructure
    individual_send -->|"recommended for"| bulk_email_infrastructure
    delivery_queue -->|"requires"| subscriber_table
    delivery_queue -->|"requires"| suppression_table
    delivery_queue -->|"uses"| smtp_relay
    smtp_relay -.->|"configured by"| m365_smtp_methods
    smtp_relay -.->|"requires"| spf
    dmarc -.->|"requires"| spf
    dmarc -.->|"requires"| dkim
    smtp_relay -.->|"requires"| reverse_dns_ptr
    list_unsubscribe_header -->|"recommended for"| bulk_email_infrastructure
    tokutei_email_law -.->|"requires"| opt_in_consent
    tokutei_email_law -->|"requires"| sender_display_obligation
    suppression_table -.->|"mitigates"| spam_rate
    list_unsubscribe_header -.->|"mitigates"| spam_rate
    listmonk_oss -->|"implements"| bulk_email_infrastructure
    individual_send -->|"requires"| subscriber_table
    bcc_mass_send -.->|"incompatible with"| suppression_table
    opt_in_consent -->|"recommended for"| bulk_email_infrastructure

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (22 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

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.

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 applied
• 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.

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, an address re-enters through another route after an unsubscribe and you send to someone who already opted out.

4.3 Architecture diagram

flowchart LR
    A[Website / subscription form] --> B[Subscriber table]
    A2[Existing customer ledger / member ledger] --> B

    C[Delivery templates<br/>subject / HTML / text] --> D[Send queue]
    B --> D
    E[Suppression table<br/>unsubscribes / bounces / complaints] --> D

    D --> F[SMTP relay<br/>existing mail infrastructure or own relay]
    F --> G[Recipients]

    G --> H[Unsubscribe URL]
    G --> I[Replies]
    G --> J[Bounces / complaints]

    H --> E
    J --> E
    I --> K[Operations contact]

    L[SPF / DKIM / DMARC / PTR / TLS] --> F

For environments where the diagram does not render, here is the same content in prose.

• Entry points: the subscription form on the website, and the existing customer ledger or member ledger. Both feed into the subscriber table.
• Center: the send queue takes three inputs - the subscriber table (who to send to), the suppression table (who must not be sent to), and the delivery template (subject, HTML, text).
• Egress: the send queue hands off to the SMTP relay (existing mail infrastructure or your own relay), and from there the mail reaches recipients. The SPF / DKIM / DMARC / PTR / TLS settings hang off the SMTP relay.
• Return path: three kinds of response come back from recipients. Unsubscribe URL hits and bounces or complaints go back into the suppression table, while replies are picked up by a person at the operations contact.

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.

4.4 Choosing the egress and the delivery engine

Once you have separated what you own from what you may swap out, two questions come up as soon as you start actually building.

1. Which egress (SMTP relay) to use

In many cases the mail infrastructure you already run can serve as the egress. For Microsoft 365, for instance, the ways to send from devices and applications that have no mailbox are documented officially, and four options are compared side by side along with their sending limits and the TLS settings and ports each needs: authenticated Client SMTP submission, SMTP relay through a connector, unauthenticated Direct Send, and High Volume Email for large internal sends.¹⁰ If you have an on-premises mail server such as Exchange Server, the same documentation notes that taking the relay there is often the easier setup.¹⁰

There are roughly four things to look at when choosing.

2. Build the delivery engine, or run on existing OSS

Building the subscriber table, suppression table, send queue, and unsubscribe page entirely yourself is more work than it looks. Self-hosted open source with the same structure exists, so the fast path is to check whether one of those already covers what you need. listmonk, for example, is AGPLv3 self-hosted newsletter and mailing list software with single and double opt-in subscriber list management, per-campaign delivery and bounce statistics, and a queue that can drive multiple SMTP servers.¹¹

A rough guide to the decision looks like this.

In every case the principle is the same: keep the subscriber data, the suppression data, and the unsubscribe URL on your own side. Hold that line and both the egress and the delivery engine can be replaced later.

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.³⁴

For example, just splitting addresses by purpose tidies operations considerably.³⁴⁵

• 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.³⁵

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.

6. The Legal and Deliverability Essentials You Cannot Skip

6.1 Consent

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.²

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

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.²

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.²

• 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 senders³
• Yahoo: requires / recommends List-Unsubscribe plus an in-body link, honored within 2 days⁴
• Outlook: recommends an easy-to-find, functioning unsubscribe⁵

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

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.³

• 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:⁴

• 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.⁵

• 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:

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.³

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.”⁴
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.³⁴
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.³⁴
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.³
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 this running without breaking things.”

7.1 Keywords to research next

Here are terms you can use directly as search queries when researching internally or talking to a vendor, grouped by stage.

Start with the authentication setup. Until that is done, however carefully you do everything that follows, the mail will not arrive.

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 or 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 is the one that really bites you.

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 to 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.”

Related Articles

• The Three Places to Fix First on a Site That Gets No Inquiries
• How to Connect Articles and Service Pages - Internal Link Design Basics

References

Related Articles

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

Related Topics

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

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is it a problem to send an announcement to everyone at once by putting them all in Bcc?

As the foundation of a system that keeps sending to external customers and prospects, it is weak. Bcc can put the mail out, but it gives you none of the operational substance: unsubscribes cannot be tracked, there is no bounce management, there is no record of consent, the send rate cannot be controlled, and the whole thing depends on one person. The moment the list grows a little, the manual operation collapses. For internal notices or a one-off message to a few stakeholders it can be fine, but for continual outward-facing delivery it should take the shape of per-recipient individual sending with state management.

Is consent required to send advertising or announcement email?

Advertising and promotional email requires prior consent as a rule. The guidance from Japan's Anti-Spam Consultation Center also states that sending advertising email without prior consent is in principle not permitted. Google and Yahoo both require sending only mail the recipient explicitly asked for, and not using purchased lists. In practice you should keep a record of the consent timestamp, the consent source, what delivery it covers, and the explanatory copy. The law does carry an exception for business addresses published on a website, but a delivery foundation that leans on that exception is not something we recommend.

What is the minimum needed to keep mail out of the spam folder?

Authentication of the sending domain. Concretely: SPF / DKIM / DMARC configured, a sending environment with a resolvable reverse PTR, TLS, a real From / Reply-To that can receive replies, an unsubscribe link in the body plus a List-Unsubscribe header, and list quality that is opt-in only. For Gmail, Google requires SPF + DKIM + DMARC and one-click unsubscribe from senders of more than 5,000 messages per day, and Yahoo asks for a spam rate under 0.3%, among other things. When you increase volume, start low and ramp at a steady pace.

Can we build a delivery foundation in-house without using a newsletter service?

At the scale of dozens to hundreds per run, yes. The key is to own the subscriber data, the delivery rules, and the sender identity (domain, authentication, unsubscribe URL) on your own side, and to structure things so that only the SMTP relay egress can be swapped later. The center is not SMTP but the subscriber table, the suppression table, and the send queue. That said, as you approach thousands per day, IP reputation and complaint-rate management become the main topic, and a dedicated service is often the cheaper option.

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.