One-paragraph version
Mailapp is a multi-tenant email sending platform built on Amazon SES. All outbound mail is DKIM-signed (RSA 2048-bit), aligned with SPF and DMARC, and includes List-Unsubscribe / List-Unsubscribe-Post headers (RFC 8058). Every bounce and complaint we receive is acted on automatically: the address is added to a platform-wide suppression list and the customer is metric-tracked toward an auto-pause threshold well below industry suspension limits.
If you are responsible for blocking, throttling, or feedback-loop arrangements with Mailapp, please use the contact at hello@mailapp.app. Include the sending IP, the sending domain, and a representative message ID or sample headers in your message — we will route to Trust & Safety within one business day.
Postmaster contact
One inbox, monitored by Trust & Safety. All postmaster / abuse-desk / FBL-administration correspondence goes here.
Mailapp operates one external-facing inbox to keep response paths short. Subject-line prefixes route the message internally; please include them where listed above so the appropriate team receives the message within minutes rather than hours.
Sending infrastructure
Mailapp's primary outbound transport is Amazon SES.
- Primary transport: Amazon Simple Email Service (Amazon SES).
- Regions in use: AWS US-East-1 (N. Virginia) and AWS EU-West-1 (Ireland). EU-residency customers are pinned to EU-West-1.
- IP strategy: the majority of customers send from Amazon SES shared IP pools, with reputation built and maintained through the controls on the Trust & Safety page. Enterprise customers may operate dedicated IPs with managed warm-up.
- Bounce / complaint pipeline: AWS SNS → Mailapp webhook → atomic suppression + per-customer metric update + auto-pause decision. Latency from SES event to suppression is typically under one second.
- Reverse DNS: reverse DNS for all sending IPs is managed by AWS and aligned with the SES public sending pools (
amazonses.com).
Authentication standards
Mailapp will not relay mail from a domain that doesn't authenticate. All three checks below must pass continuously, not just at onboarding.
If you observe a Mailapp-routed message failing any of these, please send the headers to hello@mailapp.app with subject prefix "Delivery". We treat authentication-failure reports as platform-affecting and route them to the on-call engineer.
Feedback loops
Mailapp participates in feedback loops with major mailbox providers. New FBL onboarding requests are welcomed.
- Mailapp consumes complaint feedback from Amazon SES's native complaint events and from independent FBL channels where available.
- Every complaint, regardless of source, adds the address to the global suppression list within seconds and increments the responsible customer's complaint-rate metric.
- To onboard a new FBL or change FBL routing, email hello@mailapp.app with subject prefix "FBL" and include the ARF endpoint or other technical detail. We'll respond within one business day.
Abuse handling
Mailapp acts on abuse signals automatically and quickly. There is no human-in-the-loop delay between a complaint being received and the affected address being suppressed.
- A complaint or hard bounce event arrives on the AWS SNS topic.
- Mailapp's webhook ingests it and writes the recipient address to the global suppression list, atomically.
- The originating customer's rolling 30-day bounce or complaint metric is updated.
- If either metric crosses Mailapp's internal threshold (3% bounce / 0.08% complaint — both well below AWS and major-receiver suspension limits), the customer's sending is paused immediately.
- The customer is notified by email and in-app banner with the metric, the trigger reason, and the remediation steps.
- A Trust & Safety reviewer determines whether the pause becomes a suspension or termination based on severity, history, and remediation evidence.
See the Trust & Safety page for the full enforcement schedule and the Anti-Spam Policy for the rules customers must follow.
Block / throttle / unblock requests
If you need Mailapp to be blocked, throttled, or unblocked at a specific receiver, email us with the operational detail and we'll respond within one business day.
- To request that Mailapp pause traffic to a specific receiver: email hello@mailapp.app with subject prefix "Delivery", the affected sending IPs / domains, the affected receiver domain, and the reason. We respect operational requests immediately and follow up on a permanent remediation plan.
- To report a Mailapp customer who is on your block list: include the message ID, the sending IP, and a representative bad message if possible. We'll suspend the customer pending review and confirm back to you when complete.
- To request unblock by a receiver that has blocked Mailapp: Mailapp does not request unblocks until the originating customer is suspended and the remediation is documented. The customer cannot resume sending while their reputation incident is open.
Rate-limit and back-off behaviour
Mailapp respects SMTP 4xx soft-failures and back-off signals from receivers. Repeated 4xx responses cause the queue to back off; repeated 5xx responses cause the address to be classified as a hard bounce and suppressed.
- Mailapp queues mail per-customer and per-destination, with per-receiver pacing that backs off in response to 4xx soft-failures.
- A receiver returning "try again later" (4.7.x family) causes Mailapp to slow the per-domain throughput for at least 30 minutes before retry.
- Repeated 5xx responses for an address (typically 3 within 24 hours) classify the address as a hard bounce, suppress it, and prevent any further Mailapp customer from sending to it.
- If your domain needs Mailapp to use a different pacing profile (e.g., a known slow inbound), email hello@mailapp.app with subject prefix "Delivery" and the operational detail.
Operating entity
Mailapp is operated by a single legal entity. This section is the canonical reference for legal process, postal correspondence, and identity verification.