Own your email infrastructure. Reach inbox at scale.

CloudJet is both. You can send through SMTP and APIs like a relay, but the product is built as a broader email infrastructure and deliverability platform: routing control, workload isolation, warmup workflows, pre-send protection, monitoring, and data-quality tooling—designed so teams do not have to stitch together four vendors for one mail program.

Teams that send real commercial email at scale: B2B sales organizations, SaaS products sending on behalf of customers, agencies managing multiple clients, developers integrating transactional mail, and operators who need governance-friendly workflows. CloudJet is not for unsolicited bulk mail or purchased lists.

Yes. Many teams start with governed shared pools and expand into dedicated lanes as volume and risk profile grow. The point is not “IP type,” but whether your routing model keeps reputation explainable and isolated from strangers.

Yes, for compliant B2B outreach with permission, relevance, and list hygiene. Outbound works best when paired with warmup discipline, pre-send checks, lead-quality workflows, and monitoring—not when mail is blasted to cold purchased lists.

Yes. Transactional mail is often business-critical, so it should be routed and monitored separately from experimental outbound. CloudJet’s model encourages isolation between use cases so one campaign does not destabilize password resets and receipts.

Warmup is a controlled ramp that builds stable sending patterns while authentication and list quality stay healthy. CloudJet supports warmup workflows aligned to your domains and lanes—but warmup is not magic: if DNS is wrong or lists are bad, ramping slowly still fails.

Pre-send protection is CloudJet’s guardrail layer: checks and policy enforcement meant to stop preventable failures before mail is accepted for delivery—misconfiguration drift, hygiene issues, and abusive patterns that damage reputation quickly.

Isolation means separating mail streams (by domain, client, or use case) so reputation signals, incidents, and policies do not silently cross-contaminate. It is how operational teams debug faster and how compliance-minded teams keep boundaries explicit.

Yes. Many teams send transactional traffic via SMTP while using APIs for provisioning, verification, operational queries, and automation—or the reverse. The goal is one platform with consistent auth, routing, and visibility.

Yes. Multi-domain architecture is central to CloudJet: verify domains, route intentionally, monitor per domain, and keep outbound and transactional mail from colliding.

Through a combination of authentication enforcement, routing isolation, monitoring, bounce/complaint handling, abuse prevention, and pre-send guardrails. Reputation is protected by operational discipline—not by promises of inbox placement.

Yes as part of a broader data-quality strategy. Verification and lead checking are meant to support permission-based sending and reduce self-inflicted deliverability damage—not to legitimize spam.

We monitor complaint and bounce signals, enforce acceptable use, and may pause or restrict sending when risk thresholds are exceeded. Purchased/scraped lists and unsolicited mail are prohibited. Serious violations can lead to suspension.

You will verify sending domains (SPF/DKIM/DMARC alignment), configure routing for your use cases, and provision mailboxes where applicable. Enterprise programs may require additional review for volume and compliance expectations.

Yes. Agencies benefit from multi-domain operations, routing control, monitoring, and clear separation between client programs—so one customer’s mistake does not become another customer’s deliverability incident.

Yes. Event visibility is part of the platform story: webhooks and operational signals help engineering teams automate retries, CRM updates, billing, and incident response instead of polling opaque dashboards.

Shared SMTP pools can hide deliverability risk because your signals mix with strangers. CloudJet emphasizes ownership, routing control, isolation, and monitoring so your mail program is explainable—what sent, from which domain, through which lane, and what changed when metrics move.

Yes. Migration is usually a staged DNS and routing cutover: verify domains, parallel-run signals, ramp thoughtfully, and monitor complaints and bounces. See our migration narrative on /switch-to-cloudjet.

No. Purchased, scraped, or rented lists are prohibited. We require permission-based sending and reserve the right to request opt-in evidence, pause sending, or suspend accounts that violate our Acceptable Use Policy.

Hard bounces should be suppressed quickly; repeated bad sending drives negative provider signals. CloudJet aligns bounce handling with monitoring so operators can correct list sourcing and configuration issues early.