Research memo · Verified findings
Two questions: can a self-hosted mail stack relay through SES, and is running your own outbound SMTP viable in 2026? Both are answerable. Only one is comfortable.
The research brief asked specifically for practitioner and first-hand experience from r/selfhosted, r/sysadmin, r/devops, r/aws, r/email, Hacker News, Twitter/X, and self-hosting blogs. Essentially none of it survived adversarial verification. All 22 confirmed claims resolve to vendor primary documentation — the AWS SES Developer Guide, AWS re:Post, Oracle Cloud docs, Microsoft techcommunity — plus a handful of pricing secondaries.
This memo therefore describes the documented rules of the game accurately, and says almost nothing verified about lived operator experience. Treat every "practitioner consensus" question as unanswered. Likely cause: a first-hand forum report is structurally hard to confirm against a primary document, so the verification pass killed exactly the evidence class that was wanted.
Specifically uncovered: IP warm-up practice and timelines; Gmail's actual treatment of small self-hosted senders; anything specific to Mailcow, Mail-in-a-Box, Listmonk, Postal, Keila, Mailu, or docker-mailserver beyond the generic relay pattern; how often self-hosters actually get blocked by Microsoft/Outlook; and the operator-time cost that dominates any real cost comparison. The Google/Yahoo bulk sender requirements of February 2024 produced no surviving claim at all — they were not checked and dismissed, they were simply not covered. Microsoft's 2025 requirements are covered; Google and Yahoo's are not.
Both paths work in 2026, but they fail in different places.
Relaying a self-hosted stack through SES is the pragmatic default. It costs $0.10 per 1,000 emails, sidesteps the near-universal cloud block on outbound port 25, and inherits SES's warmed shared-IP reputation. What you give up is control: AWS holds a unilateral kill switch, and it is account-wide rather than per-domain.
Fully self-hosted outbound SMTP is structurally harder than it used to be. Port 25 egress is blocked by default on AWS EC2/Lambda and on every Oracle Cloud tenancy created after 23 June 2021. Exemptions exist but are manual and discretionary. Microsoft has required SPF, DKIM and DMARC from high-volume senders to consumer Outlook mailboxes since May 2025.
One economic note that cuts against the usual assumption: SES got less free, not more. The old perpetual 62,000-emails-per-month-from-EC2 tier is gone, replaced by 3,000 message charges per month for 12 months only. SES is no longer "effectively free" at hobby scale — though at $0.10/1,000 it still costs less than the operator time a self-run IP demands.
SES gates all new accounts behind a sandbox — 200 emails/24h, 1 email/sec, verified recipients only, per AWS Region — liftable only by a manually reviewed production-access request.
AWS states verbatim: "We place all new accounts in the Amazon SES sandbox. The sandbox status for your account is unique per each AWS Region… You can only send mail to verified email addresses and domains, or to the Amazon SES mailbox simulator… a maximum of 200 messages per 24-hour period… a maximum of 1 message per second." Post-sandbox limits are set case-by-case and are not published; the commonly cited 50,000/day and ~14/sec are observed norms, not documented defaults. Two restrictions often missed: delegate senders are equally restricted, and account-level suppression bulk actions are disabled in sandbox.
docs.aws.amazon.com/ses/latest/dg/ — request-production-access.html, quotas.html, manage-sending-quotas.html
Production access is granted on an explicit attestation that you send only to people who requested it and have bounce/complaint handling in place.
Console step 8: "In Acknowledgement, check the box that you agree to only send email to individuals who've explicitly requested it and confirm that you have a process in place for handling bounce and complaint notifications." The CLI path (aws sesv2 put-account-details) has no acknowledgement parameter at all, so this is an attestation rather than a technical gate — but the obligation binds via the AWS AUP and SES Service Terms either way, and approval is manually reviewed and not guaranteed. Nothing in the verified evidence prohibits using SES as a smarthost for self-hosted software as such; the constraint is on the mail's consent basis and content, not the sending architecture.
docs.aws.amazon.com/ses/latest/dg/request-production-access.html · faqs-enforcement.html · aws.amazon.com/aup/
SES enforces bounce and complaint thresholds account-wide and can pause sending entirely — sometimes with no review period. This is the single point of failure, and its blast radius spans every domain and app on the account.
Published thresholds: bounce rate under 2% recommended, ≥5% places the account under review, ≥10% may pause sending; complaint rate under 0.1% recommended, ≥0.1% under review, ≥0.5% may pause. The status ladder runs "Under review" → "Pending sending pause" → "Sending paused" ("While your account's ability to send email is paused, you won't be able to send email using Amazon SES"). Both metrics are percentages of email "sent from your account" — so relaying a newsletter and transactional mail through one account means one bad list can cost you transactional delivery. AWS can also pause immediately without review for AUP violations, apparently unsolicited mail, or phishing content, explicitly including simulated phishing. It documents pausing an account because a related AWS account misbehaved.
Precision required: rates are computed over a variable "representative volume", not a fixed window, and are not reproducible from GetSendStatistics. Only hard bounces to unverified domains count. Per-configuration-set reputation metrics help with attribution but do not insulate other streams. AWS hedges with "might pause" throughout — nothing here is deterministic.
docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html · faqs-enforcement.html · reputationdashboardmessages.html · repost.aws/knowledge-center/ses-high-bounce-rate
Relaying through SES does not give SPF-based DMARC alignment by default. SES uses an amazonses.com subdomain as the envelope MAIL FROM, so SPF authenticates SES's domain, not yours.
AWS: "Messages that you send through Amazon SES automatically use a subdomain of amazonses.com as the default MAIL FROM domain. SPF authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email—in this case, SES." More bluntly, AWS notes SPF alignment is "rarely possible… when sending mail through third-party bulk email providers because the Return-Path (MAIL FROM) is used for bounces and complaints that the provider (SES) tracks using an address they own."
The fix, and its footguns: configure a custom MAIL FROM subdomain — "you must publish exactly one MX record… If the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup with Amazon SES will fail," plus an SPF TXT record. The subdomain must not be used for anything else, notably not for receiving mail. SES polls DNS for 72 hours; on MX failure it can silently fall back to the amazonses.com default — so mail keeps flowing while SPF alignment quietly breaks. SES defaults to strict DKIM alignment. Treat Easy DKIM as the reliable alignment route and custom MAIL FROM as the SPF addition.
docs.aws.amazon.com/ses/latest/dg/mail-from.html · send-email-authentication-dmarc.html
SES quotas and billing count recipients, not messages — so a newsletter consumes quota proportional to list size, and batching or BCC tricks evade nothing.
"Quotas are based on the number of recipients, rather than on the number of messages." Worked example: "an email that has 10 recipients counts as 10 against your quota." A recipient is any To, CC or BCC address, with a hard ceiling of 50 recipients per message (50 destinations per templated email), so large lists must be fanned out regardless. AWS actively recommends one SendEmail call per recipient, since a multi-recipient call fails atomically. Both the daily quota and the per-second rate use this accounting. Billing is likewise per recipient-message.
docs.aws.amazon.com/ses/latest/dg/quotas.html · manage-sending-quotas.html
Outbound port 25 is blocked by default across the major clouds. This is the structural obstacle, and it bites before deliverability is even in play.
AWS: "By default, AWS blocks outbound traffic on port 25 for all EC2 instances and Lambda functions on elastic network interfaces. This block prevents spam and applies to AWS accounts that aren't on an allowlist." The EC2 User Guide scopes it precisely — port 25 works to private IPv4 only, and is blocked to all public IPv4 and IPv6, i.e. blocked for exactly the case that matters. Removal needs a root-account "Request to Remove Email Sending Limitations", up to 48h, per Region.
Oracle: "Tenancies made after June 23, 2021 are by default not allowed to send e-mail via outbound TCP port 25 to the internet… open a service limits request to request an exemption." Practitioner reports indicate the OCI exemption is commonly refused on Always Free tenancies, since a service-limits increase effectively requires a paid account. Approval is nowhere guaranteed.
Important scoping correction: ports 587/2587 and 465/2465 are not throttled. That is precisely the mechanism by which a self-hosted stack on EC2 relays through SES without ever filing a port-25 request.
repost.aws/knowledge-center/ec2-port-25-throttle · docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html · docs.aws.amazon.com/ses/latest/dg/smtp-connect.html · docs.oracle.com (release notes f7e95770) · docs.oracle.com/Content/Network/Troubleshoot/vcn_troubleshooting.htm
Microsoft's May 2025 rules set a hard authentication floor: domains sending over 5,000/day to outlook.com, hotmail.com or live.com must pass SPF, DKIM and DMARC (minimum p=none, aligned via SPF or DKIM).
Announced 2 April 2025, enforced from 5 May 2025, still in force as of mid-2026: "new requirements and best practices designed to strengthen email authentication for domains sending more than 5,000 emails per day." The DMARC bar is "At least p=none and align with either SPF or DKIM (preferably both)", with FAQ guidance to progress none → quarantine → reject. Two scoping points: the 5,000/day counts mail sent to Microsoft consumer mailboxes, not total outbound, and the scope explicitly excludes Microsoft 365 business tenants.
This materially favours the SES-relay path — SES supplies managed DKIM signing and a documented SPF-alignment route, whereas a bare Postfix operator builds and maintains all three. Confidence is medium on method grounds: the Microsoft primary URL would not render via WebFetch (title only), so verification rests on search-index snippets plus multiple independent secondaries quoting identical language.
techcommunity.microsoft.com — "Strengthening email ecosystem: Outlook's new requirements for high-volume senders" · dmarcian.com · mailgun.com
AWS's own guidance steers users away from self-hosted SMTP on the stated grounds that email providers block cloud IP ranges — a real signal, but read it carefully.
AWS Knowledge Center: "Your email provider might block cloud IP ranges. This could stop or delay the delivery of the email that you send from your instances or Lambda functions. To prevent blocked outbound email, use Amazon Simple Email Service (Amazon SES)." Three qualifications the evidence forces: AWS hedges with "might"; the same article is a how-to for getting port 25 unblocked so you can self-host, and recommends rDNS/PTR best practice for self-hosters, presenting SES as recommended rather than mandatory; and AWS is recommending its own paid product, so this is not neutral evidence.
Logically, SES works because of managed, warmed shared-IP reputation and established feedback loops — not because its IPs are somehow non-cloud. Do not extend this to "cloud IPs categorically cannot deliver mail." Verification was via search-index retrieval; direct fetch returned 403.
repost.aws/knowledge-center/ec2-port-25-throttle · docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html
SES base pricing is $0.10 per 1,000 emails — but the "SES is effectively free at small scale" argument is dead.
Live pricing page, checked July 2026: "$0.10/1000 emails" flat, no volume tiering on the base rate. "Free tier customers receive up to 3,000 message charges free each month for the first 12 months after you start using SES." The prior tier was 62,000 outbound/month when sent from AWS compute, plus 1,000 inbound; it was removed in August 2023 and grandfathering closed in August 2024, so no perpetual free tier survives for any account in 2026. Extras on top of the base rate: $0.12/GB outgoing attachment data, $0.15/1,000 for Mail Manager email processing, plus Virtual Deliverability Manager charges.
aws.amazon.com/ses/pricing/ · aws.amazon.com/blogs/messaging-and-targeting/ (revised free tier) · devclass.com
A dedicated SES IP costs $24.95/month (standard) or $15/month per account plus $0.08–$0.02 per 1,000 (managed) — the concrete price point to compare a self-run IP against.
Standard dedicated IPs: "$24.95 per month per IP". Managed: "$15 per month per account" plus tiered per-message charges ($0.08/1,000 up to 10M/mo, $0.04/1,000 to 50M, $0.02/1,000 to 100M). These are add-ons, not replacements for the base sending charge.
Cost framing correction: $24.95/mo is roughly 4–6× the cheapest credible VPS (Hetzner CX22 at about €3.79/mo, DigitalOcean basic droplet at $6/mo), so it is comparable to a mid-tier VPS rather than a small one. The raw infrastructure delta therefore favours self-hosting; the real SES premium buys warmed IP reputation, feedback loops, and not having to operate the stack. Separately, BYOIP carries a reported 256-IP minimum, putting it far out of reach for small operators.
aws.amazon.com/ses/pricing/ · docs.aws.amazon.com/ses/latest/dg/manual-dedicated-ips.html
These appeared in the source material and did not survive adversarial verification. The third in particular is widely repeated in secondary coverage.
| Killed claim | Vote |
|---|---|
| SPF-based DMARC alignment through SES strictly requires the From domain to match the custom MAIL FROM domain. | 0–3 |
| AWS routinely denies port-25 unblock requests with a boilerplate template citing AUP violations, billing standing, or unclear use case. | 1–2 |
Microsoft escalated from junk-foldering to outright SMTP rejection with 550 5.7.515 Access denied effective 5 May 2025. | 1–2 |
Pipeline: 5 search angles → parallel web search → URL dedup and fetch of 20 sources → claim extraction → 3-vote adversarial verification per claim, needing 2 of 3 refutations to kill → synthesis. 102 agents, 99 claims extracted, 25 verified, 22 confirmed, 3 killed, 10 reported after merging semantic duplicates. 6 URL duplicates removed; 4 claims dropped on budget.
Vendor self-interest: a large share of the evidence is AWS documenting AWS policy. That is authoritative for what the rules are; it is not neutral evidence on whether self-hosting works.
Method caveats: the Microsoft primary URL would not render via WebFetch (title only) and the AWS re:Post port-25 article returned 403 on direct fetch. Both were verified via search-index snippets and independent secondaries rather than read first-hand.
Time sensitivity: pricing, quotas and thresholds were fetched live on 19 July 2026 and are current as of that date. SES pricing and free-tier terms have already changed materially once (August 2023), so re-verify before relying on cost figures. Post-sandbox sending limits are explicitly not published. Oracle's port-25 policy dates to 2021 and remains in force with no reversal found.