# Acceptable use (/security/acceptable-use)



This policy applies to everything sent through Sendly: transactional mail, campaigns,
workflows and API sends alike. It is short on purpose. Every rule here is one we actually
enforce, and each says how.

## Consent [#consent]

Send only to people who asked to hear from you.

That means a real signup, a purchase, or another relationship where the recipient could
reasonably expect your mail. It does not mean a purchased list, a scraped list, a rented
list, a list from an acquired company that did not include consent, or addresses appended
by a third-party service.

**How this is enforced.** Mostly by its consequences: bought and scraped lists bounce and
draw complaints, and the [sending standards](/security) stop projects that do. Imports are
also screened for the shape a purchased list has, and one that scores badly is held rather
than imported.

## Content [#content]

Do not send:

* Phishing, credential harvesting, or mail impersonating another company, service or person.
* Malware, or links to it.
* Fraud: fake invoices, fake delivery notices, fake account alerts, advance-fee schemes.
* Content that is illegal where you or your recipients are.
* Harassment, or content targeting a private individual.

**How this is enforced.** Outbound mail is sampled and scanned. A phishing verdict stops
the project immediately, with no warning stage, and applies to every project you own. The
[sending standards](/security) page describes that path in full, including what you are and
are not told.

## Unsubscribes and suppression [#unsubscribes-and-suppression]

Honour every unsubscribe, and honour it promptly.

Sendly maintains a suppression list per project. Addresses that hard-bounce or file a spam
complaint are added automatically and stay there.

**How this is enforced.** The suppression list is applied at send time, and re-importing a
list does not undo it — a contact import cross-checks suppressions and drops the addresses
on them rather than resurrecting them. This is not a limitation to work around; it is the
single mechanism that keeps a bounced address from being mailed again.

## Identity [#identity]

Send as yourself. Use a From address on a domain you control and have verified, do not
forge headers, and make it obvious who the mail is from.

**How this is enforced.** Sending from a domain requires DNS verification. Unverified
sending is limited to a sandbox address with tight caps.

## Volume [#volume]

Ramp gradually. A new project has a low daily cap; verifying a domain and subscribing to a
paid plan raise it. This protects you as much as us — a sudden first-day blast to a large
list is the pattern most likely to land you in spam folders and the pattern abuse looks
like.

**How this is enforced.** Daily caps are applied per project and per account, so creating
more projects does not raise your ceiling.

## Security research [#security-research]

If you find a vulnerability in Sendly, tell us at [security@sendly.now](mailto:security@sendly.now). We will not pursue
you for good-faith research: staying within your own account, not accessing other
customers' data, not degrading the service, and giving us reasonable time to fix it.

## Changes to this policy [#changes-to-this-policy]

If we change what is allowed in a way that affects what you are already doing, we will
tell you before it takes effect. See the [portability and pricing
commitments](/trust/portability) for the notice we commit to, and for how to take your data
elsewhere if a change does not work for you.

## Reporting abuse [#reporting-abuse]

Mail you believe was sent through Sendly in violation of this policy: [support@sendly.now](mailto:support@sendly.now).
Include full headers if you have them — they are what lets us identify the sender.