The single biggest threat to a shared sending domain is non-OTP content leaking into it. The single biggest defense is making the API refuse anything that isn't an OTP.
Mailbox providers score sender reputation by the consistency of traffic they observe. A domain that sends only OTPs, with low complaint rates and predictable volume, is exactly the kind of traffic they reward with inbox placement. A domain that's also sending marketing, transactional, and replies to support tickets will have a noisier reputation profile — and much harder-to-predict deliverability.
vipvap chooses the narrow path on purpose. We send exactly one template: a verification code email, always sent as vipvap, default expiry, low content. There is no per-account branding to weaken the sender identity.
One reputation to protect — a near-100% delivery target that a general-purpose email tool can't promise across every message type.
The POST /v1/send endpoint accepts only the recipient and a code-shaped string (4–12 characters). It will not accept HTML bodies, attachments, arbitrary subject lines, or reply-to overrides. That means an attacker who has compromised a vipvap API key cannot use vipvap to send phishing emails from the vipvap domain.
Every account has a hard cap. The endpoint refuses sends past the cap — there are no overages by design. That bound is also the bound on abuse: even with a stolen key, the volume of damage is capped.
lax, 14-day lifetime.If we discover an account sending non-OTP content via any side-channel (custom-subject as a phishing pretext, recipient-name fields abused, anything that turns the email into something other than a code delivery): we suspend the account and notify the contact email. Bounced money is not refunded. There's no appeals process for clear violations of the OTP-only contract.
Report abuse: abuse@vipvap.xyz.
Security researchers: security@vipvap.xyz.
One API key, one endpoint, one message type. Get a key and send your first OTP in minutes.