Cold email is spam. Don’t send it through PostShiba.
If you’re building a prospecting tool that scrapes addresses and sends automated sales sequences to people who never asked for them, PostShiba is not the infrastructure for it. Personalizing the opening line doesn’t change that. Neither does sending from a verified domain.
Our use-case policy prohibits cold outreach. This is a boundary on what we carry, not a problem to solve with a different sending setup.
Personalization isn’t permission
A work email address on a website is not an invitation to add someone to a sales sequence. Buying an address from a data vendor doesn’t create that invitation either.
The distinction we care about is whether the recipient asked to hear from you. A message can mention their job title, reference their latest post and offer a relevant product while still being unsolicited.
We don’t make an exception because the recipient is a business. Calling a campaign “B2B outreach” tells us who you’re targeting, not whether they wanted the email.
This is not just a deliverability problem
In Cold email, one year on, Spamhaus describes cold email as spam and calls on providers to prohibit it and enforce their acceptable-use policies. It also describes the cycle of disposable domains, filtering and infrastructure rotation that supports this traffic.
We agree with the underlying point: providers have a responsibility to decide what they enable.
Our job is to deliver mail that recipients have a reason to expect. It isn’t to help unsolicited sales sequences survive the next filter. Treating every block as an engineering obstacle skips the more important question of whether the message should have been sent.
This matters to the other senders using the service, too. PostShiba’s policy identifies prohibited traffic as a risk to the network, not just to the account sending it.
What we don’t allow
Our published policy rules out:
- Cold outreach to people who never signed up.
- Bought, rented or scraped mailing lists.
- Contacts added through enrichment or appending rather than collected from the people themselves.
- Rotating domains or senders to get past spam filters.
- Routing through PostShiba to get around another provider’s rules.
Slowing down a prohibited campaign doesn’t make it acceptable. Adding an unsubscribe link doesn’t replace the permission that was missing at the start.
Separating traffic is useful for legitimate sending. Our IP pools let platforms group dedicated sending IPs by customer or mail stream. They aren’t an exception to the rules about what can be sent.
Build for email people expect
There’s a clear difference between a sign-in link someone requested and a pitch sent because their address appeared in a prospecting database. The same distinction applies to a booking confirmation, a reply to a support request or a newsletter someone chose to receive.
For platform builders, that distinction belongs in the product before a message reaches the sending API:
- Ask customers what they plan to send and how they collected the recipients.
- Keep a record of newsletter signups and what subscribers agreed to receive.
- Don’t let a customer label a sales campaign “transactional” to bypass marketing rules.
- Make it possible to stop a customer’s sending when their use breaks your policy.
PostShiba uses tenants to separate customers’ domains, credentials and suppressions. As explained in our beta announcement, you can suspend one tenant while the others keep sending. That gives you a way to act on abuse; it doesn’t remove your responsibility to act.
Legality isn’t the whole decision
The strongest objection is that a sender believes their outreach is lawful. This article isn’t a legal assessment of every jurisdiction or every message.
It is a statement of what PostShiba allows. We require permission for marketing, and we don’t carry cold outreach. A claim that a campaign is legally permissible doesn’t override that policy.
Check the use case before you build
PostShiba is for transactional messages, permission-based marketing and email products built around conversations people expect. It is not a route around another provider’s rejection of cold email.
Check our allowed and prohibited use cases before building your sending flow. If your plan depends on emailing people who never asked to hear from you, don’t build it on PostShiba.