SMTP INFRA · GMAIL-FOCUSED · MANAGED
A dedicated MTA fleet backed by 50,000 to 100,000 Gmail-routed warmup messages per slot, per day at steady state, plus capacity for up to 100,000 production sends per slot per day after managed ramp. Content-matched, continuously managed, built for operators mainstream ESPs won't take.
We optimize for reliable acceptance and pipeline stability. Inbox placement itself is never guaranteed — it depends on your content, list, and recipient behavior. What we control is measured, managed, and reported.
Most warmup products move tens or hundreds of generic messages a day. Postmaster Ops moves 50,000 to 100,000 content-matched warmup messages through Google-operated Gmail receiving infrastructure for every active sending domain, every day. That is the same order of magnitude as your production sending volume — which is why the phrase "we warm your domains" means something different here than everywhere else.
Warmup does not end when production begins. It remains active alongside customer traffic, continuously managed against SMTP responses, deferrals, user feedback, and Google Postmaster signals.
At steady state, a single domain carries 50,000 to 100,000 managed warmup messages plus up to 100,000 production sends each day. Your domain is already sustaining Gmail-directed traffic at production-order volume before your campaign depends on it.
This does not guarantee inbox placement. It does mean you are not taking a domain that has been sending 50 messages a day and suddenly asking it to carry 100,000.
Per-domain daily traffic composition
| Layer | Capability | Details |
|---|---|---|
| Warmup | Production-scale warmup | Each active sending domain receives 50,000 to 100,000 content-matched warmup messages per day after ramp. Every warmup endpoint is Gmail-hosted and routes through Google-operated receiving infrastructure. Warmup continues alongside production traffic and is adjusted using SMTP responses, deferrals, complaint trends, and Postmaster data — no fabricated content, no third-party payloads, no engagement-faking. |
| Transport | Dedicated MTA fleet | Purpose-built fleet distributed across multiple upstream carriers. Traffic is distributed to reduce single-provider failure risk and limit the blast radius of carrier-level abuse events. |
| Isolation | Dedicated IP + domain per slot | Each slot pairs one sending domain with one dedicated IPv4 address; that pair is provisioned to your account and not shared. Plans include 1, 3, 5, or 10 slots. Transport orchestration and monitoring are shared across the fleet; sending-domain and IP-level reputation is measured and reported per slot. |
| Deliverability | Gmail-focused routing discipline |
All customer traffic is routed exclusively to @gmail.com. The signals
that most directly affect Gmail delivery — SMTP responses, authentication,
recipient feedback, sending consistency, Postmaster telemetry — are the ones we
monitor and remediate on your behalf.
|
| Observability | Scheduled Postmaster synchronization | Every registered sending domain is synced daily to Google Postmaster Tools (Google's own data cadence, ~24h). Compliance trend, user-reported spam rate, delivery-error breakdowns — the signals Google actually publishes, surfaced as a dashboard you can read at a glance instead of ten separate Postmaster tabs. |
| Diagnostics | End-to-end delivery diagnostics |
Transport outcomes are classified as accepted, deferred,
or rejected from the remote SMTP response. Controlled seed tests to
real Gmail accounts we monitor separately report inbox,
spam, or missing placement — transport and mailbox
placement are distinct signals, not conflated.
|
| Compliance | List-Unsubscribe & one-click opt-out | RFC 8058 one-click unsubscribe wired into every send by default. Bounces and unsubscribes propagate to a per-customer suppression list; the aggregate user-reported spam rate is tracked via Google Postmaster and surfaced with weekly trend reporting. |
| Data handling | No full-list ingestion | No uploaded subscriber files accepted or stored. Recipient addresses and message content live in the active sending queue only, until final acceptance, final rejection, or 72h queue age — whichever comes first. Delivery-event metadata (no recipient local part) retained 30 days. Per-slot aggregate rollups (anonymized) retained 90 days. Suppression identifiers stored as customer-scoped HMAC hashes for the account lifetime plus 30 days. Full retention matrix in §03 Data. |
We store what the relay needs to prove delivery, protect the fleet, and keep your suppression list honest. Message bodies are removed from the active queue once the remote MTA accepts the send and are not persisted in downstream records; see the transient-copy note below.
@)Raw recipient addresses and production content exist in primary storage only within the active sending queue — until final acceptance, final rejection, or the queue's maximum retention age (72 hours), whichever comes first. After final disposition, standard delivery records are limited to the fields shown on the left. Restricted transient operational copies follow the separate maximum retention periods below.
Primary-storage retention is enforced at write time. Raw addresses cannot be recovered from hashes, so bulk export of raw suppressions is not offered. Financial and sanctions-screening records are retained as legally required (§4 & §6 of the Terms).
Transient operational copies. Standard operating infrastructure — MTA logs, backup snapshots, exception traces — may transiently capture identifiable data beyond the primary-storage windows above. Current maximums: MTA / journald logs 30 days, encrypted backups 30 days, exception traces 7 days. Access is restricted to authorized operators. Full detail in the privacy policy.
Every AUP handwaves. Ours won't. Below is the concrete list of what we take and what we don't. Vetting call resolves edge cases before either of us wires money.
Priced per slot — one dedicated IP paired with one dedicated
sending domain. Each slot handles managed warmup plus up to
100,000 production sends per day to @gmail.com,
capped server-side. No free tier. No trial. No self-serve signup — every account is
on-boarded personally. Full production capacity reached after 2–4 weeks of managed ramp.
| Plan | Slots | Monthly | Per-slot | Combined production cap | Support |
|---|---|---|---|---|---|
| Starter | 1 | $ 2,500/mo | $2,500 |
100K / day | Email support · Postmaster sync |
| Growth most operators | 3 | $ 7,200/mo | $2,400 (−4%) |
300K / day | Direct operator line · monthly review |
| Scale | 5 | $11,500/mo | $2,300 (−8%) |
500K / day | Direct operator line · bi-weekly review |
| Fleet | 10 | $22,000/mo | $2,200 (−12%) |
1M / day | Priority attention · weekly review |
$3,500 ·
Growth $8,200 ·
Scale $12,500 ·
Fleet $23,000.
Onboarding is a one-time charge billed with month 1; from month 2 onward you pay the plan price alone.
Vetting first, invoice second, provisioning third — so nobody wires before both sides know the account is going to happen. Full ramp is roughly two to four weeks depending on domain count. Every stage has a concrete milestone you can point at; you always know what "on track" looks like.
Business identity, verticals, offer, list source, jurisdictional exposure, existing Postmaster history. A short async questionnaire on top of the intro call. Either side can walk here at no charge — no invoice has been issued yet.
Once both sides approve the account, we issue a written service order with your assigned address space, sending domains, DNS-record blueprint, and expected throughput ceiling — and the first-month invoice. Provisioning begins when payment clears.
Authentication verified end-to-end, SMTP integration proved out against your submission client, event feedback wired in, seed monitoring active. A limited first production segment goes out — small enough that any misconfigure surfaces cheaply.
Daily volume increases governed by SMTP responses, Postmaster trends, and recipient behavior — not by a fixed calendar. Once at target throughput, monitoring, automatic throttling, incident handling, and scheduled reviews take over.
What we control — availability, authentication, routing, SMTP-response classification, infrastructure monitoring, ramp discipline. What you control — list source & permission, offer & claim legality, message content, engagement quality, audience targeting. Inbox placement depends on both sides.
Payment
Bank wire (USD) or crypto (USDC, USDT, BTC). Invoiced by
Oliver DeNune INC dba Postmaster Ops, a Pennsylvania corporation.
NET-0 on the first cycle; other terms only where stated in the Service Order.
Vetting
Every account is preceded by a call — brand, offer, volume, target market, technical setup. Not a sales pitch; a filter. We defend your traffic to our upstream, and you agree in advance to what we'll boot you for.
Suspension & termination
Reputation-related issues get a written notice and a defined remediation window (7 days) before any action. Prepaid unused funds are pro-rated and refunded in that case — we win when you stay, not when you overpay. Immediate suspension is reserved for fraud, phishing, illegal activity, or urgent upstream-abuse events; termination for those causes forfeits prepaid funds.
Data handling
Uploaded subscriber files are neither accepted nor stored. Recipient addresses and message content live in the active sending queue only; nothing past SMTP DATA persists after acceptance or rejection. Delivery-event metadata (without recipient local part) is retained 30 days. Suppression identifiers are stored as customer-scoped HMAC hashes. Full per-signal retention in §03 Data.
$./apply --intro "one paragraph, no NDA needed"
// sender identity · verticals · current provider · target monthly volume
Slot availability is capped at a manageable customer count per operator. Tell us who you are and what you send; we'll book a call within 48 hours.