How SMEs Can Design Bulk Email Without Locking Themselves into One Vendor

If an SME wants to send announcement emails to tens or hundreds of people without adding another newsletter vendor, the practical answer is not a giant Bcc blast.
The practical answer is a small delivery system built around per-recipient sends, subscription state, unsubscribe handling, and SPF / DKIM / DMARC.

In this article, “without relying on one specific service” does not mean “without using any services at all.”
It means keeping the mailing rules, subscriber state, templates, and unsubscribe flow on your side so that only the sending path can be swapped later.

This article assumes mail to people who already have some relationship or consent, such as existing customers, members, newsletter subscribers, or people who requested information.
It is not about scraping public addresses and sending cold promotional mail at scale. That approach is weak both legally and operationally.¹²

The guidance below reflects public Japanese legal guidance and sender requirements published by Google, Yahoo, and Outlook as checked in April 2026.¹²³⁴⁵

Contents

1. 1. The short answer first
2. 2. Why Bcc is not enough
3. 3. What “not relying on one specific service” really means
   • 3.1 What you should own
   • 3.2 What can be swapped later
4. 4. A realistic architecture for SMEs
   • 4.1 The minimum parts
   • 4.2 Fields worth storing
   • 4.3 Architecture diagram
5. 5. How far to build, depending on volume
   • 5.1 Once a month, a few dozen recipients
   • 5.2 A few times per month, a few hundred recipients
   • 5.3 Approaching thousands per day
6. 6. Minimum legal and deliverability requirements
   • 6.1 Consent
   • 6.2 Sender disclosure and unsubscribe handling
   • 6.3 Authentication and delivery quality
7. 7. A practical implementation order
8. 8. Common mistakes
9. 9. Wrap-up
10. Related articles
11. References

1. The short answer first

For SMEs, a realistic bulk-email setup usually comes down to four points:

1. Send one message per recipient
   Do not treat the mailing job as one big Bcc action. Treat it as a queue of individual sends.
2. Own the subscription state
   Keep states such as active, unsubscribed, and bounced in your own DB or file-based system.
3. Accept unsubscribe requests automatically
   Do not make “please stop sending me mail” a manual mailbox workflow. Put a visible unsubscribe link in the message body and, where practical, support List-Unsubscribe.³⁴⁵
4. Authenticate the sending domain
   SPF / DKIM / DMARC, PTR, and TLS are table stakes now. Without them, mail may technically send but still struggle to land.³⁴⁵

That is why this is not mainly an email-client problem.
It is a delivery-system problem.

Once “we need to send to many people” gets translated into “put many addresses into To / Cc / Bcc,” the design already starts to fail.
The real system has to answer:

• who is eligible to receive this category of mail
• who must never receive it again
• what kind of consent was recorded
• how unsubscribe requests get applied
• whether the sending identity looks trustworthy to receiving systems

2. Why Bcc is not enough

Bcc feels simple because it hides the real work instead of solving it.

The dangerous part is that it appears to work.
Mail goes out, so people assume the process is valid. In reality there is no suppression logic, no consent trail, no delivery log, and no durable unsubscribe state. The moment the audience grows, manual handling starts to break.

Bcc is not always wrong.
It can be acceptable for internal mail, tiny one-off member notices, or limited closed-group communication.
It is just a weak foundation for a continuing external mailing process.

3. What “not relying on one specific service” really means

The common misunderstanding is to read that phrase as “do everything by hand.”
That is not the goal.

In practice, vendor-neutral control comes from owning three things on your side.

3.1 What you should own

• Subscriber data
  • email address
  • consent timestamp
  • consent source
  • mailing category
  • unsubscribe / bounce state
• Delivery rules
  • what gets sent to whom
  • how quickly it gets sent
  • how bounces and unsubscribes update state
• Sender identity
  • sending domain
  • SPF / DKIM / DMARC
  • reply-capable mailbox
  • unsubscribe URL

3.2 What can be swapped later

• the SMTP relay
• the admin UI implementation
• where the send queue runs
• where logs are stored

That is the real meaning of vendor neutrality: do not hand away the state and rules that define your mailing operation.

• keep recipient lists in your own DB
• keep unsubscribe URLs under your own domain
• keep your subject/body templates on your side
• allow only the outbound transport to be replaceable

With that structure, you can start with an existing mail path and switch the transport later without losing consent history or suppression data.

4. A realistic architecture for SMEs

4.1 The minimum parts

For batches in the tens or hundreds, you do not need an oversized platform.
But you should still separate the basics.

1. subscriber table
2. suppression table
   • unsubscribes
   • hard bounces
   • complaints
3. message templates
   • subject
   • body (HTML / text)
   • category
4. send queue
   • per-recipient status
   • result
   • retry count
5. SMTP relay
   • existing mail infrastructure or self-managed relay
6. logs
   • who was sent what and when
   • success / failure
   • unsubscribe / bounce application

Advanced open-rate or click-rate analytics are not the first priority.
The first priority is much simpler: send safely, stop safely, and explain what happened.

4.2 Fields worth storing

At minimum, something like this is useful.

Even if the original source is Excel or a legacy customer ledger, it is worth separating this much.
The most important rule is that suppression state always wins.

If the sales spreadsheet still contains the address but the suppression table says unsubscribed, the send must not happen.
Without that rule, the same recipient can be reintroduced from another path and mailed again by mistake.

4.3 Architecture diagram

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

    C[Message templates<br/>subject / HTML / text] --> D[Send queue]
    B --> D
    E[Suppression table<br/>unsubscribe / bounce / complaint] --> D

    D --> F[SMTP relay<br/>existing mail path or self-managed relay]
    F --> G[Recipients]

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

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

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

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

The SMTP relay is just the exit.
If the transport changes later, the mailing history and suppression state should still survive.

5. How far to build, depending on volume

5.1 Once a month, a few dozen recipients

At this scale, a small setup is usually enough:

• merge-capable template
• one-message-per-recipient sending
• unsubscribe URL
• saved send log
• SPF / DKIM / DMARC in place

The main point is to avoid sliding back into Bcc, even when the audience is small.
If the mail is external and recurring, it is usually better to start with individual sends plus state management from the beginning.

5.2 A few times per month, a few hundred recipients

At this stage, the system gets more stable if you add:

• a send queue
• rate control
• bounce reflection
• immediate unsubscribe reflection
• a dedicated sending subdomain
• an approval flow
  • test send
  • production send
  • result review

It also becomes important to separate ordinary human mail from promotional or announcement mail.
Google recommends separating traffic by type, and Yahoo explicitly advises keeping bulk / marketing mail separate from transactional / alert traffic rather than mixing them through the same IP or DKIM identity.³⁴

Even a simple split like this makes operations cleaner:³⁴⁵

• order / billing: [email protected]
• incidents / maintenance notices: [email protected]
• newsletter / announcements: [email protected]

5.3 Approaching thousands per day

At this point, “not using a specific service” can become the wrong optimization target.

Google publishes explicit requirements for Gmail senders over 5,000 messages per day, including SPF / DKIM / DMARC, alignment of the From domain, and one-click unsubscribe.
Outlook also sets SPF / DKIM / DMARC expectations for domains sending over 5,000 messages per day and warns that non-compliant mail may be filtered or rejected.³⁵

At this scale, the operating focus shifts to:

• IP reputation
• complaint rate
• bounce rate
• unsubscribe processing
• volume ramp-up
• monitoring

There are many cases where a dedicated sending service becomes cheaper than carrying all of this yourself.

So the point of this article is not “self-manage everything forever.”
The point is that for tens to hundreds of messages per batch, a small in-house delivery foundation with your own rules and state is often the right balance.

6. Minimum legal and deliverability requirements

6.1 Consent

Promotional mail generally requires prior consent.
The Japanese anti-spam guidance referenced here also treats unsolicited promotional mail as prohibited in principle.²

Google and Yahoo likewise expect senders to mail only recipients who explicitly want the messages, avoid purchased lists, and avoid deceptive or pre-checked opt-in flows.³⁴

In practical terms, at least keep:

• consent timestamp
• consent source
• mail category / purpose
• explanatory wording
• the screen or wording used when consent was obtained

There are legal exceptions around publicly disclosed business addresses in some cases.
But building a recurring mailing system around that exception is a weak idea. Complaint risk, deliverability, and actual response quality all tend to suffer.²

6.2 Sender disclosure and unsubscribe handling

Even when consent exists, the sender still has disclosure obligations.
The referenced Japanese guidance expects at least the following information.²

• sender name or entity name
• mailbox or URL that receives refusal / unsubscribe requests
• a clear statement that the recipient can opt out
• sender address
• complaint / inquiry contact

In practice, that means your footer needs something like:

Sender: Example Co., Ltd.
Unsubscribe: https://example.com/unsubscribe/xxxxx
To stop receiving these messages, please use the URL above.
Address: Tokyo, Japan ...
Contact: [email protected]

Receiving platforms also care strongly about how easy unsubscribe is.

• Google: requires one-click unsubscribe for high-volume senders³
• Yahoo: requires or recommends List-Unsubscribe, a visible body link, and prompt processing⁴
• Outlook: recommends a clear, functional unsubscribe path⁵

So the practical minimum is a visible link in the body and, where possible, headers such as the following:³⁴

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

6.3 Authentication and delivery quality

Major inbox providers now assume authenticated sending rather than treating it as an optional enhancement.

Google’s public sender guidance expects the following.³

• all senders: SPF or DKIM
• high-volume senders: SPF + DKIM + DMARC
• PTR consistency
• TLS
• low spam rate
• one-click unsubscribe for high-volume senders

Yahoo publishes expectations including:⁴

• SPF / DKIM / DMARC
• DMARC alignment
• valid forward / reverse DNS
• unsubscribe
• spam rate below 0.3%
• opt-in mailing
• separation of bulk and transactional traffic

Outlook’s published high-volume-sender expectations include:⁵

• SPF pass
• DKIM pass
• DMARC with at least p=none and alignment via SPF or DKIM
• real From / Reply-To addresses
• unsubscribe support
• list hygiene

This is a good minimum operating checklist:

Google also recommends ramping volume gradually with engaged recipients instead of sending sudden spikes.³

7. A practical implementation order

If you want the smallest realistic starting point, this order works well:

1. Separate the mail categories
   • operational notifications
   • newsletters
   • seminar or event notices
   • existing-customer announcements
2. Create the signup or consent flow
   Make the explanation visible on the website. The recipient should understand what will arrive and how often.⁴
3. Separate subscriber data from suppression data
   If you get this boundary right early, you can switch tools later without breaking operations.
4. Choose a sending domain or subdomain
   For example, news.example.com or mail.example.com. Do not mix this responsibility with personal or ordinary business mailboxes.³⁴
5. Set up SPF / DKIM / DMARC / PTR / TLS
   For self-managed sending, this is the first technical priority. Do not build the sending base on an environment that cannot provide reverse DNS properly.³⁴
6. Build a small admin UI
   The point is not a flashy interface. The point is to have:
   • subject editing
   • body editing
   • test send
   • production send
   • audience preview
   • batch-size control
   • result review
7. Start with a small, engaged audience
   Send first to existing customers or readers with good prior engagement, then expand if the results stay healthy.³
8. Prioritize unsubscribe and bounce reflection before analytics
   Confirm these work before worrying about open rate.

This order shifts the goal from “we can send mail now” to “we can keep sending without operational accidents.”

If the main challenge is the website side of the system, such as the signup form, consent wording, unsubscribe page, and inquiry flow, it naturally connects to Website Development.
If the harder part is connecting existing customer ledgers, internal systems, or Windows-based tools into one delivery flow, it fits Technical Consulting & Design Review better.

8. Common mistakes

The common mistakes are usually these:

• using the same sender identity for ordinary human mail and promotional / announcement mail
• tracking consent only as free-text notes
• handling unsubscribe requests manually through replies
• dumping old business-card lists into the system
• suddenly sending the largest volume ever
• mixing promotional wording into operational notices
• stopping at “the send API returned success”
• letting the customer ledger outrank the suppression table

The last one is especially dangerous.

The address still exists in the sales spreadsheet.
But that recipient already unsubscribed from the newsletter.
If suppression state does not always win, the address can re-enter the audience from another path and get mailed again.

9. Wrap-up

If an SME wants to send moderate-volume email without locking itself into one vendor, the real question is not which button to press.

The real requirements are:

• per-recipient sending instead of Bcc
• a subscriber table and suppression table
• an unsubscribe flow that works automatically
• SPF / DKIM / DMARC / PTR / TLS
• operational separation between notification mail and promotional mail

In short, own the sending rules before you optimize the sending tool.

For tens to hundreds of messages per batch, it is often completely practical to run without a dedicated newsletter vendor.
But even then, the fastest path is not “send from a mail client.” It is to treat the whole thing as a small delivery system.

Related articles

• The First Three Places to Fix When a Website Does Not Bring Inquiries
• How to Connect Articles and Service Pages with Internal Links

References