The 60-second version
We screen accounts before they send. We block bad lists at upload time. We scan every campaign before it goes out. We cap new senders and unlock volume only after clean reputation. Bounces and complaints feed back into automatic suppression and account pauses — within seconds, not days.
- Account screening: identity + domain verification required before any meaningful send volume.
- List validation: uploads containing disposable domains, role accounts above 30%, sequential patterns, or known spam-trap addresses are rejected at the door.
- Content scanning: every campaign passes a spam-pattern and CAN-SPAM compliance check before it can be sent.
- Graduated limits: unverified accounts cap at 200 emails/day; six-month-clean paid accounts unlock 2,000,000/day.
- Auto-pause thresholds: bounce rate above 3% or complaint rate above 0.08% pauses sending automatically — well below AWS / Gmail / Yahoo account-level limits.
- Global suppression: every bounce and complaint adds the address to a platform-wide suppression list that cannot be undone by the customer.
Who we let send
Bad senders cost everyone. We make it expensive to be one — and easy to be a good one.
- Email verification is required before an account can send to any address other than the verified owner.
- Domain verification (SPF + DKIM + DMARC alignment) is required before sending volume rises above the email-verified cap.
- Payment verification (a real card, address-matched) is required before the per-day cap rises above the domain-verified tier.
- Identity friction for high-risk signals: accounts created from disposable email, anonymising VPNs, or jurisdictions on our high-risk list go through manual review before any send.
- Right to refuse service: we will not onboard customers operating in categories that are uniformly bad senders (purchased-lead vendors, "lead-gen" affiliates, cold-outreach SaaS, gambling without a license, "wealth" / get-rich-quick).
List quality controls
The single biggest predictor of a sender's future complaint rate is the quality of the list they upload. We enforce hard blocks at upload time so bad lists never reach the send queue.
Every contact-list upload is validated against a set of programmatic rules. Lists failing these rules are rejected — the customer sees the specific reasons and must clean and re-upload. There is no override.
The rules above are the public-facing summary. The actual disposable-domain list and spam-trap registry are maintained continuously from public sources and our own incident history. Customers may not see the full lists for obvious reasons.
Content moderation
Every campaign is scanned before it can be sent. Some content is blocked outright; some adds to a spam score that can pause the send for review.
- Banned keywords (hard block — the campaign cannot be sent): Nigerian-prince / lottery / get-rich / pharmacy spam phrasing and similar high-confidence spam patterns.
- Suspicious phrase scoring: common spam phrases add to a score; over a threshold the send is paused for compliance review.
- Required CAN-SPAM elements: every commercial campaign must contain a working unsubscribe link AND a physical postal address. If either is missing, the send is blocked before it reaches Amazon SES.
- One-click unsubscribe headers: Mailapp automatically adds
List-Unsubscribe(mailto + https) andList-Unsubscribe-Postheaders per RFC 8058 — the 2024 Yahoo/Google bulk-sender requirement. - Subject-line patterns: excessive capitalisation, excessive punctuation, and known spam-subject patterns increase the score.
- Link density: campaigns with more than 30 unique outbound links are flagged for review.
Graduated trust limits
New accounts cannot suddenly send a million emails. Volume unlocks gradually as the account proves it can maintain clean reputation.
Sends crossing one-time-only thresholds (first send over 10,000; any single campaign over 100,000; first send from a newly verified domain) are paused for one-business-day compliance review even within a tier's normal cap. This catches list-acquisition incidents before they ship.
Bounce and complaint feedback loops
Every bounce, every complaint flows back into Mailapp within seconds — and is acted on automatically.
Mailapp's outbound transport is Amazon SES (see Sub-processors § 2). SES publishes bounce, complaint, and delivery events to AWS SNS topics. Mailapp's webhook handler ingests every event and performs the following actions, in order, atomically:
- Record the event with the SES message ID, the recipient address, the event type, the sub-type (transient / permanent, abuse / fraud), and the timestamp.
- Suppress the recipient address on the global suppression list (see § 7). The address cannot be re-added by the customer.
- Update the customer's rolling 30-day bounce and complaint rate metrics.
- Pause the customer's sending automatically if either rate crosses our internal threshold (see § 6).
- Notify the customer via email + in-app banner with the metric, the trigger reason, and remediation steps.
Mailapp also participates in feedback loops (FBLs) with major receivers (Gmail, Yahoo, Microsoft, AOL) where available, so we receive complaint signals even when they arrive via FBL rather than SES's native complaint event.
Auto-pause thresholds
We pause customers BEFORE their metrics reach AWS / Gmail / Yahoo account-level suspension thresholds. Acting early is what keeps the shared reputation healthy.
A paused account cannot resume sending until: (a) a Mailapp compliance reviewer accepts a written remediation plan from the customer, and (b) the customer's metrics have decayed below the warning threshold over a clean test send. Repeat offenders are not given a second chance.
Global suppression list
Once an address has bounced hard or complained anywhere on the platform, no Mailapp customer can email it again. The suppression list is platform-wide and one-way.
- Every hard bounce, every spam complaint, every unsubscribe is written to a global, platform-wide suppression list.
- Customers cannot remove an address from suppression. They cannot bypass it by re-uploading. They cannot export raw addresses for re-use outside Mailapp.
- Customers can see the suppression count and an aggregate breakdown of their own contributions for transparency, but not the raw address-level data of other customers.
- Suppression is honoured before every send, in the send queue, with a final pre-flight check after rendering.
Sender authentication
Mailapp refuses to send from a domain that doesn't pass SPF, DKIM, and DMARC alignment. Authentication isn't optional — it's a precondition for using the platform.
- SPF record required on every sending domain before send-from is enabled.
- DKIM signing with RSA 2048-bit keys, rotated annually. Mailapp publishes the public key in DNS and signs every outbound message.
- DMARC at policy
p=quarantineor stricter for accounts in the Paid · 3+ months tier and above (matching Yahoo/Google's February 2024 bulk-sender requirement). - BIMI supported for senders with a Verified Mark Certificate.
- Mailapp will not send from a domain whose authentication check fails at send time, even if the same domain previously passed — DNS changes are re-validated continuously.
Sending infrastructure
Transparency about what actually moves your email. We use Amazon SES as our primary transport because it gives us the lowest-friction path to compliant, high-reputation delivery — and the feedback loops we need to enforce the controls above.
- Primary transport: Amazon Simple Email Service (Amazon SES), in AWS US-East-1 and EU-West-1 (Ireland) for region-matched residency.
- Bounce / complaint pipeline: AWS SNS → Mailapp webhook → suppression + metrics + auto-pause (see § 5).
- IP strategy: shared SES IPs for most customers (with reputation we earn through the controls on this page); dedicated IPs available on Enterprise with a managed warm-up plan.
- Region selection: EU customers can be pinned to EU-West-1 for data residency. US customers default to US-East-1.
- Backup transport: we maintain a secondary transport for failover. We do not rotate transports to evade reputation issues — that would be sender abuse.
Sub-processor details (including the AWS DPA, region commitments, and certifications) are on the Sub-processors page.
Transparency
We publish enforcement statistics so our practices can be audited from outside.
- Annual transparency report covering: number of accounts paused, terminated, and reinstated; number of abuse reports received and acted on; complaint and bounce rate distributions across the platform; number of law-enforcement requests received and what we did about them.
- Public status page at status.mailapp.app for delivery delays, ingestion incidents, and SES upstream issues.
- Sub-processor change log on the Sub-processors page.
- Bug bounty for security-affecting issues, run via our coordinated-disclosure process.
Report a problem
If you received a Mailapp-routed email you didn't ask for, or you've found a Mailapp-side abuse / security issue, here's how to reach us.
- Recipient abuse reports (spam / phishing routed through Mailapp): use the Report abuse form or email hello@mailapp.app with full headers. Triaged within 24 hours.
- Postmaster / ISP / abuse desk communications: see the Postmaster page.
- Security vulnerabilities: email hello@mailapp.app with the word "Security" in the subject; triaged within one hour during business days, twenty-four hours otherwise.
- Law enforcement and legal process: contact hello@mailapp.app. We follow the procedure documented in our Privacy Policy § Law Enforcement.