Sending limits and anti-abuse

Three separate things decide how much mail leaves your domain, and they behave differently when you reach them:

Your plan's limits

Every plan sets a messages per hour and a messages per month figure. Both are checked when you submit, and both count messages accepted rather than messages delivered. The current usage against each one is on the domain page in the dashboard.

Over the hourly figure, the API answers HTTP 400:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "non_field_errors": ["Hourly limit exceeded"]
}

Over the monthly figure the wording is Monthly limit exceeded. On the SMTP relay the same two limits are checked when the message body is sent, and the transaction is answered 550 hourly limit exceeded or 550 monthly limit exceeded. These are the limits to retry against with a backoff — they clear on their own.

The warm-up ramp

A receiving provider meters the sending domain, not the IP address it arrived from. A domain that has never sent anything and starts pushing tens of thousands of messages looks the same to Gmail whether it is a real product launch or a breach, so every domain here is paced by how much it has already been seen to send:

• A domain starts at 200 messages a day. This floor is the same on every plan, free or paid — a paid plan buys volume, not a shortcut past the pacing, and nothing about an invoice is visible to a receiving provider.
• After that the cap is twice your busiest single day of actually delivered mail over the last 30 days. It is recomputed once a day, automatically.
• The day's allowance is also spread across the day, so a day's worth of mail is not handed to a receiver in one burst just after midnight.
• The cap is never higher than what your plan allows in a month.

Doubling every day takes a domain from 200 to 100,000 a day in about nine days of real sending. A domain that goes quiet for the whole 30-day window falls back to the floor, because a dormant domain waking up at full volume is exactly the pattern this exists to slow down.

If you have a launch that cannot wait for the ramp, write to support@help.postwing.app before it — the cap can be raised by hand on a named domain, and that is a much better conversation to have in advance than after a receiver has started rate-limiting you.

Content and volume checks

Every message is scored for spam signals when we accept it. Nothing is refused on that score: one message is never evidence of anything, and a single unusual email is far more likely to be a customer writing about a payment than a campaign.

What is watched is the pattern over a domain's recent traffic. A sweep runs continuously and looks at two things:

• Content — a large share of a domain's recent mail scoring as spam, over a meaningful number of messages.
• Velocity — a new domain submitting a volume far above anything it has ever sent, within an hour.

Bounce rates and spam rejections from receiving providers are measured too, and reviewed by a person rather than acted on automatically.

What the content scoring looks for

The rules that weigh heavily are the ones with no innocent reading — not subject lines or sales language:

• Mixed alphabets inside one word (Latin and Cyrillic letters combined) or digits standing in for letters — the classic filter-evasion spellings.
• Links pointing straight at an executable, or at a bare IP address.
• A link whose visible text is one domain and whose target is another.
• Impersonating a well-known brand from a domain that is not theirs.
• Hidden text — display:none, zero font sizes, white on white.

Ordinary marketing copy is not one of these. "Summer sale, 30% off, click here" is a product we sell, and the lighter signals — shouty subject lines, link shorteners, sales vocabulary — cannot add up to a suspicious score on their own.

If sending is stopped

A block is deliberately loud, and it is not the same thing as a bad reputation score:

• Every user on the domain is emailed, with the reason.
• The reason is shown on the domain page in the dashboard, next to a Banned badge.
• New submissions are refused — HTTP 403 on the API, and on SMTP the refusal happens at authentication with Sending from this domain has been stopped.
• Queued mail is held, not deleted. Nothing is failed and nothing is lost; it is released and delivered if the block is lifted.

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
    "detail": "Sending from this domain has been stopped: Sending spam",
    "code": "domain_banned",
    "reason": "spam"
}

detail is written for a person and is translated; code and reason stay in English and are what your integration should branch on. reason is one of spam, phishing, malware, purchased_list, spam_content, spam_velocity, terms, fraud, requested or other.

Getting it lifted

Reply to the email, or write to support@help.postwing.app with the domain name and what has changed. Automatic blocks exist because being wrong quickly and cheaply is better than letting a list run — if one caught you by mistake, say so and it is reviewed.

Staying clear of all of this

1. Send only to people who asked. Purchased, scraped and rented lists are the single most common cause of a block, and they bounce and complain at rates no amount of technical setup can hide.
2. Grow into your volume. Start with your most engaged recipients and increase over days — which is also what makes the ramp rise underneath you.
3. Split transactional and marketing mail onto different domains (or subdomains). Their reputations are then separate, and a campaign that goes badly does not stop your password resets.
4. Clean your list. Remove hard bounces immediately and stop mailing addresses that have not engaged in months.
5. Mark campaigns with mass_mail so the one-click unsubscribe headers are attached — see the send API documentation.
6. Write mail that reads as itself. No obfuscated spellings, no hidden text, links pointing where their text says they do.

See also domain reputation, which is scored separately and can refuse sending on its own.