Permission to send is earned.

A small start, with a clear path forward.

New human and agent accounts start on probation: up to 10 outbound recipients per day and 3 per minute, including each message. Lower plan limits still apply, so free human accounts remain at 3 recipients per day. Standard senders have a 20-recipient minute allowance; operator-reviewed senders have 60. The API accepts at most 50 recipients in any message, subject to these lower allowances. To, Cc and Bcc all count.

Existing accounts at rollout retain their plan allowances and start at the standard level. They are not automatically treated as operator-reviewed. Buying a subscription, a domain-hosting period or sending credits does not remove probation, a pause or another sending limit.

After at least seven days, a probation account can graduate to standard on its next send when at least ten distinct recipients were accepted by external mail servers across three days within the last 30 days, with no invalid-address bounces in the current monitoring window. Server acceptance does not prove inbox placement or consent. Operators can review legitimate sending sooner.

One allowance cannot become a hundred.

Separate mailboxes under an owner share a ceiling of 100 recipients per day, or the owner’s larger existing plan allowance, and 60 per minute. Aliases use their destination mailbox’s allowance. Creating another mailbox or rotating an API key does not create fresh sending permission.

Across the service, probation traffic shares a 200-recipient daily ceiling; all accounts awaiting operator review share a 500-recipient daily ceiling. Reviewed traffic still has account and related-mailbox limits. These conservative shared ceilings protect the current delivery infrastructure while we grow; they can temporarily limit an otherwise legitimate sender. Request a review for ongoing usage.

Reservations count before delivery, so concurrent API, MCP and authenticated SMTP requests cannot overspend the allowance. A definite failure before submission releases its reservation. An uncertain submission keeps it reserved; later bounces do not refund accepted submissions. Daily allowances reset at midnight in the service database’s time zone.

Pause harmful sending. Keep the inbox available.

Five distinct invalid-address bounces in 24 hours, making up at least 20% of resolved recipient outcomes, automatically pause new outgoing submissions. We use trusted Postfix delivery evidence: explicit 5.1.1 “mailbox does not exist” responses without forwarding. Temporary errors, forwarding failures and Gmail’s 5.7.x authentication or reputation rejections do not trigger this rule.

A confirmed abuse complaint can also cause a pause. Our dedicated receiver verifies Yahoo-signed complaint reports and matches their original sender, Message-ID and recipient to retained submissions. A matching complaint blocks that recipient and pauses the sender. Each sending domain needs Yahoo enrollment before reports arrive. Redacted, unsigned or unmatched reports require review; ordinary incoming bounce messages cannot change sending permissions. Administrators can also independently verify and record complaints.

A sending pause applies at authenticated SMTP submission too, including API reservations not yet submitted. Mail already accepted into the queue cannot be recalled by this control. An owner pause also blocks its child mailboxes. Receiving and reading remain available, and the account retains its mail.

Invalid addresses are suppressed for that sender. Confirmed complaint suppressions require an administrator to verify renewed recipient consent before release. Resuming an account does not remove recipient blocks or erase its delivery history.

Agents can inspect and request a review.

curl --fail-with-body https://keykeeper.world/api/v1/agent/sending \
  -H "Authorization: Bearer $KEYKEEPER_API_KEY"

The response includes state, tier, dailyLimit, recipientsPerMinute, reason and reviewRequested. Full and limited agent keys can read their own status. check_balance also includes it. Use a full account key to POST a review request to the same URL with {"purpose":"Explain your sending purpose, expected volume and how recipients consented."}. The purpose must be 40–1,000 characters. Omit private messages and credentials.

MCP offers check_sending_status and request_sender_review. A request goes to the designated owner administrator; it does not grant permissions automatically. Repeating a pending request preserves its original purpose. The request endpoint allows three calls per day. People can request a review from Usage & plan.

HTTP 403 with sending_paused requires review; do not retry automatically. HTTP 429 uses sending_burst_limit, sending_daily_limit, sending_shared_limit or sending_pool_limit. Back off using Retry-After, and do not create more accounts to evade a limit. Shared limits may make the available capacity lower than the per-account maximum returned by status.

Privacy stays part of the design.

These safeguards use account ownership, recipient counts, delivery codes and verified complaint decisions. They do not classify message bodies or upload them to an AI service. They also work with OpenPGP-encrypted bodies. Delivery evidence is retained for up to 90 days; review decisions are retained for up to one year. Pending review text is cleared when an administrator makes a decision. Active recipient blocks remain until released.

We do not offer self-service bulk sending on this shared pool. Bulk delivery needs a separate operator review and infrastructure plan; separate bulk IP infrastructure is not live yet. DNS authentication and payment alone cannot guarantee delivery or eliminate spam. These controls limit exposure and give us a way to intervene.