Acceptable Use Policy

Last updated 25 August 2026. Applies to SimpliDeliver Email, operated by Niyam Vora, sole proprietor, trading as SimpliDeliver ("SimpliDeliver", "we", "us").

This policy governs everything sent through SimpliDeliver Email. It is short on purpose, and we enforce it.

1. Who this applies to

This policy binds every person and organisation that uses the service ("you", "your account"), and it binds you for everything sent using your credentials, including mail triggered by your own customers or by software you operate. You are responsible for the conduct of anyone you allow to send through your account. If you build a product on top of ours, you must impose terms on your own users that are at least as strict as this policy, and you must enforce them.

2. The two streams, and why the difference matters

SimpliDeliver Email carries two kinds of mail, with different rules.

• Transactional — a message sent to one recipient in direct response to an action that recipient took, or an event in an account they hold with you: password resets, email verification, one-time passcodes, receipts and invoices, order and delivery notifications, security and account alerts, service notices to existing users, and notifications generated inside an application the recipient uses.
• Marketing — a message whose purpose is promotional, sent to recipients on a list: announcements, newsletters, campaigns, digests, offers, event invitations and re-engagement mail.

Both are permitted. The difference is consent: a transactional message is justified by the recipient's own action, and a marketing message is justified only by their explicit permission. Section 3 is therefore the most important section of this policy, and the one we suspend accounts over most often.

Do not disguise one as the other. A receipt built around an advertisement, or a "your account is ready" message that is mostly an upsell, is marketing mail and is subject to every rule in sections 3 and 4. We look at the substance of the message, not its subject line or which API endpoint sent it.

3. Consent is required for every marketing message

You may only send marketing mail to a recipient who gave you explicit, informed, affirmative permission to send it, and you must be able to show when, where and how that permission was given. We may ask you for that evidence, and an account that cannot produce it will be suspended.

These are not consent:

• a pre-ticked box, or an opt-out buried in terms nobody reads;
• "they are a customer, so they agreed" — a purchase is consent to be sold to, not consent to be marketed to;
• a business card, a conference badge scan, or a public profile;
• an address published on a website, in a directory, or in a company registry;
• consent given to somebody else, including a company you acquired, unless the recipient was told at the time that their data could transfer and did not object.

Permission is specific to you and to the kind of mail you described when you asked for it. It does not transfer, it cannot be sold, and it goes stale — if a recipient has not heard from you in a long time, treat the permission as expired rather than assuming it holds.

4. Purchased and third-party lists are prohibited

You may only send to an address that was given to you directly by the person who owns it. You may not send to any address that was purchased, rented, leased, swapped, scraped, harvested, guessed, appended, inferred, or obtained from a data broker, a public directory, a website, a social network, or any other third party. You may not upload such a list to the service, and you may not use the service to validate, clean, enrich or test one.

This is the one rule with no exception, no exemption and no enterprise carve-out. It is what makes shared sending infrastructure viable, and we would rather lose an account than an IP reputation. We do not host, sell or supply recipient lists, and we never will.

5. Unsubscribe

We add the unsubscribe mechanism for you. Every marketing message we send carries a List-Unsubscribe header and one-click List-Unsubscribe-Post per RFC 8058, pointing at an endpoint we host. An opt-out is written directly into your account's suppression list and takes effect immediately, whether or not your application ever learns about it.

You must not work around it. Specifically, you may not:

• strip, rewrite, or override the unsubscribe headers we add;
• send to an address that has unsubscribed — from a second account, a second domain, a variant of the address, or by re-uploading the contact;
• require a login, an account, a reason, a survey or a fee in order to unsubscribe;
• treat an unsubscribe as applying only to one campaign when the recipient meant all of your marketing mail;
• ignore a plain-language request to stop that arrives as a reply instead of a click. A reply asking to stop is an instruction to stop.

Where the law that applies to you or your recipient requires more — a visible unsubscribe link in the body, a physical postal address, a specific opt-out deadline — meeting it is your responsibility, not ours. We add the technical mechanism; we do not make you compliant.

6. Sending limits

The two streams are metered differently, because they scale differently. Transactional is metered by emails sent. Marketing is metered by how many contacts you store — broadcasts to your contacts are unlimited and do not count against your transactional quota.

Transactional — emails per month

Sent and received messages both count. A message addressed to several To, Cc or Bcc recipients counts once per recipient, not once per message.

Marketing — contacts stored

Transactional and marketing are independent subscriptions. You can be on a paid marketing plan and the free transactional plan, or the reverse.

API rate

10 requests per second per account, across every API key on the account. Requests over the limit receive a 429 with standard ratelimit-limit, ratelimit-remaining, ratelimit-reset and retry-after headers.

How limits are applied

• Higher tiers are not self-serve. Above the entry plans we review the account before raising a limit, and we look at your sending record, your bounce and complaint rates, and how your lists were built. Volume is earned, not purchased.
• Exceeding a quota returns an error, unless you have enabled pay-as-you-go overage on a paid plan. It is never a silent charge.
• Splitting traffic across accounts to work around a limit is a breach of this policy, and is treated as seriously as sending to a purchased list.
• Every account starts on a probation cap regardless of plan, lifted once it has a clean sending record.

7. Other prohibited use

You may not use the service to send or facilitate:

• Unsolicited mail. Any message to a recipient who did not ask for it, whatever you choose to call it.
• Phishing, spoofing or impersonation. Mail that misrepresents who sent it, forges or falsifies headers or the From, Reply-To or return path, imitates another brand or person, or attempts to collect credentials, payment details or personal data under false pretences.
• Deceptive marketing. Misleading subject lines, false sender names, fake "re:" or "fwd:" prefixes, fabricated urgency or scarcity, or an offer whose real terms are materially different from the ones in the message.
• Malware and harmful content. Viruses, ransomware, spyware, exploit code, or links to any of it.
• Fraud. Advance-fee fraud, fake invoices, counterfeit goods, pyramid or Ponzi schemes, "get rich quick" offers, or deceptive financial, medical or investment claims.
• Illegal content. Anything unlawful under Indian law or under the law applying to you or your recipient, including material that infringes intellectual property, child sexual abuse material, and content that incites violence or hatred.
• Harassment. Mail directed at a person who has asked you to stop, threats, stalking, or doxxing.
• Suppression evasion. Sending to a suppressed address through a second account, a second domain, a variant address, or any other route around the block. Creating a new account after a suspension is itself a breach of this policy.
• Resale or relay. Operating an open relay, reselling raw sending capacity, or letting an unvetted third party send through your account.
• Attacks on the service. Probing, load-testing without written permission, circumventing rate limits or quotas, or interfering with delivery for other accounts.

8. Requirements on every message you send

• Verify the domain. You may only send from a domain you have verified with us by publishing the DKIM, SPF and custom MAIL FROM records we generate for it.
• Identify yourself honestly. The From address must accurately identify you, and a reply to it must reach a person.
• Keep the relationship current. Do not send to an address for an account that has been closed, a relationship that has ended, or a permission that has gone stale.
• Keep your list clean. Remove addresses that hard-bounce, and do not re-import contacts we have suppressed.
• Stay within the rates below.

9. Bounce and complaint limits

Measured over a rolling window, once your account has sent at least 100 messages:

• Bounce rate above 5% — sending is suspended.
• Complaint rate above 0.1% — sending is suspended.

These are the thresholds at which shared sending infrastructure starts to be damaged for everyone on it, so we act on them mechanically rather than case by case. A suspended account gets an immediate error on every send attempt and an email to its administrators explaining why. New accounts also begin with a reduced daily sending cap, lifted once a track record exists.

A high complaint rate is almost always a consent problem, not a content problem. If you cross the complaint threshold, expect us to ask how the list was built before we lift anything.

10. Our right to suspend or terminate

We may suspend or terminate sending on any account, immediately and without prior notice, at our sole discretion, where we believe that this policy has been breached, that a breach is about to occur, or that continued sending puts other customers, recipients, or the reputation of our sending infrastructure at risk. We may do this on the basis of an abuse report, our own monitoring, a notice from a mailbox provider or from our infrastructure provider, or a legal demand.

Depending on what we find, we may also:

• throttle or cap your sending, or reduce your quota;
• block a specific domain, address, list or campaign while leaving the rest of your account running;
• stop a campaign that is part-way through sending;
• add recipients to suppression and refuse to remove them;
• require evidence of consent for a list before sending to it resumes;
• retain evidence of the breach and disclose it to a mailbox provider, our infrastructure provider, or a law enforcement or regulatory authority where we are required or reasonably entitled to;
• terminate the account and refuse to do business with you in future, including under a different name.

We will tell you what we found and give you a route to respond. Where a suspension was precautionary and the explanation resolves it, we will lift it. Where it was not, we will not. We do not owe a warning first, and nothing in this section obliges us to keep sending mail we believe to be abusive.

11. Reporting abuse

Anyone — recipient, mailbox provider or bystander — may report abuse to abuse@simplideliver.com. This mailbox is monitored and read by a person. We aim to acknowledge reports within one business day and to act on substantiated ones promptly.

Please include the full message headers where you can. They identify the sending account, which is what allows us to act rather than merely file the report. Reporting abuse does not require an account with us, and if you simply want the mail to stop, the unsubscribe link in the message works immediately and you do not need to contact us at all.

12. Changes to this policy

We may update this policy as the service changes or as new kinds of abuse appear. The date at the top reflects the current version. Material changes will be notified to account administrators by email before they take effect, and continued use of the service after that constitutes acceptance.

13. Governing law

This policy is governed by the laws of India, and the courts at Mumbai, Maharashtra have exclusive jurisdiction over any dispute arising out of it.

14. Contact

Abuse reports

abuse@simplideliver.com

Questions about this policy

support@simplideliver.com

Operator

Niyam Vora, sole proprietor, trading as SimpliDeliver. India.