sendrules
Home
Product
  • Overview
    How sendrules fits between your app and every provider.
  • SMTP Proxy
    One endpoint. Every provider you already trust.
  • Grid & Rules
    Six routing strategies. Coverage warnings. Failover.
  • Quality Gate
    Verify recipients before the send, not after the bounce.
  • ISP Routing
    Route by the recipient's live MX record — not domain strings.
  • Ramp-up
    Auto-advancing cap with bounce/complaint safety gates.
  • Limits & Queue
    Four-tier caps. Queue, don't drop. Midnight-UTC release.
  • Webhooks
    Signed and verifiable. Retried on schedule. Replayable.
  • Activity
    Seven filtered inboxes. Sparklines. Share links.
  • Inbound
    Receive + classify replies, bounces, and OOOs.
  • Autoresponder Parser
    Harvest contacts from OOO replies into lists — webhook or CSV.
  • REST API
    Every UI action has an endpoint. Scoped, rotatable keys.
  • Teams and roles
    Fine-grained RBAC across 30 resource types + audit trail.
Deliverability
  • Overview
    The suite most vendors sell separately.
  • DMARC Monitoring
    DMARC aggregate reports ingested with per-source breakdowns.
  • Auth Check
    SPF / DKIM / DMARC, graded A through F.
  • Postmaster Tools
    Google Postmaster data in per-domain views.
  • Blocklists
    Continuous blocklist + seed-list inbox placement.
  • Free Tools
    Email validation, spam check, DMARC generator — free on every plan.
How it Works
Industries
  • All industries
    Every segment sendrules fits — and why.
  • B2B SaaS
    Transactional at scale. Failover across ESPs.
  • E-commerce & Retail
    One rule per ISP — Gmail buyers routed differently to Yahoo.
  • Marketing Agencies
    Per-client rules on your clients' own provider accounts.
  • Sales Development
    Verify every address. Parse every autoresponder for referrals.
  • Recruitment & Staffing
    OOO replies are full of decision-maker names — capture them.
  • Real Estate & Lead Gen
    Inquiry email hygiene + reply-source enrichment.
  • Financial Services
    DMARC compliance, audit log, signed webhooks.
  • Healthcare & Life Sciences
    Reliable patient comms with a full audit trail.
  • EdTech & Education
    Enrollment-week bursts absorbed by queue-don't-drop.
  • Nonprofit & Fundraising
    Donor-appeal deliverability without a deliverability team.
  • Publishers & Media
    Newsletter deliverability + list hygiene at every send.
  • Government & Public Sector
    IP allow-list at AUTH, DMARC-first, tenant isolation.
PricingProduct Demo
Sign inStart free
Webhooks

Delivery signals your billing and CRM can actually rely on.

A single, versioned event contract for every delivery signal that matters. Signed and verifiable on receipt, retried on a schedule you can predict, and replayable from Activity when a downstream system was down.

Start freeSee the pricing
Sound familiar?

The retries pulled the whole table out of sync.

You wired Stripe events to your billing table with confidence. Then you tried to wire your ESP’s delivery events to your CRM, and every retry pulled the whole delivery-status table out of sync. Signed webhooks — the kind you know work — turned out to be a Business-tier feature. So you built a dedupe layer, a signature shim, and a replay tool from scratch, and every one of them is a page in the on-call runbook now.

How sendrules fixes it

One event contract. One signature. One replay button.

Every workspace gets the same event stream, versioned so a schema change never lands without warning, signed with a per-endpoint secret so your receiver can verify the payload without an SDK, and de-duplicated by event id so the retry contract cannot corrupt your database. When a downstream system was down, you replay the missing window from Activity — a checkbox and a button, not a script.

The events

The delivery events you get — every plan.

No feature-gated events. No add-on SKU. If a message moves, an event fires.

delivered
The upstream provider accepted the message for delivery. Fires once per accepted recipient with the provider that carried it.
bounced (hard)
A permanent rejection. The recipient is added to your suppression list with the provider’s stated reason attached to the event.
bounced (soft)
A temporary rejection. The message re-enters the queue on the documented back-off schedule; the event carries the retry-after window so your dashboards can show it.
complained
The recipient marked the message as spam through their mailbox provider. The address is added to your suppression list and the event fires immediately.
opened
A tracked open — with the caveats every operator knows about image-proxied opens. Fires once per recipient per campaign; subsequent opens roll up into Activity.
clicked
A tracked link click. The event carries the destination URL, the campaign id, and the recipient id so your CRM can attribute without a JOIN.
replied
An inbound message classified as a reply to a specific outbound send. The event carries both message ids so you can thread the conversation.
unsubscribed
The recipient used a one-click unsubscribe link or an inbound List-Unsubscribe. Suppression is applied before the event fires.
provider health change
An attached provider moved between healthy, degraded, and offline. Fires once per transition so your status page can reflect what the routing layer already knows.
Retries

How the retry contract actually behaves.

At-least-once
Every event carries an id that is stable across retries. If your receiver returns a non-2xx response, we retry the same event with the same id — dedupe on it and your database stays consistent.
Back-off
Delivery attempts follow a documented curve: seconds, then minutes, then hours, with a ceiling on total elapsed time. The curve is the same for every workspace and published in the app so an on-call engineer can predict the next attempt.
Dead-letter
After the final attempt, the event moves to a dead-letter queue in Activity — not silently dropped. You see the payload, the response body from your endpoint, and a replay button.
Replay from Activity
Pick a window, pick an endpoint, click Replay. Every event in the window is re-delivered with its original id and payload. Use it to backfill after a downstream outage without writing a migration script.
Signatures

Signature verification without an SDK.

Every event is signed with a secret unique to the receiving endpoint, and the signature travels alongside the payload with a timestamp. A compromised secret on one endpoint never compromises the others, and a rotated secret takes effect on the next event with no downtime. The verification recipe is a few lines in any language — hash the payload with your secret, compare in constant time, reject anything older than your accepted window. No client library required.

Ready to wire delivery events into billing and support without paging engineering?

Start freeSee the pricing
sendrules

One SMTP endpoint across 15 providers. Verify recipients before the send, route by real MX, and monitor DMARC in the same product.

Sign inStart free

Product

  • SMTP Proxy
  • Grid & Rules
  • Quality Gate
  • ISP Routing
  • Ramp-up
  • Limits & Queue
  • Webhooks
  • Activity
  • Inbound
  • Autoresponder Parser
  • REST API
  • Teams and roles
  • Integrations

Deliverability

  • DMARC Monitoring
  • Auth Check
  • Postmaster Tools
  • Blocklists
  • Free Tools
  • Providers

Solutions

  • How it Works
  • Industries
  • Customers
  • Pricing
  • Contact

Company

  • About
  • Security
  • Terms
  • Privacy
  • DPA
  • Acceptable Use

© 2026 sendrules.com