Why peptide brands look at this at all
Almost nobody moves mail in house to save money. They move because of a clause. Of the mainstream email platforms, Brevo is the only one that names the category outright. Its anti-spam policy lists, under content it does not accept regardless of legality, “Peptide-based products for injectable or oral human therapeutic, weight-loss, or performance use (e.g. GLP-1 analogues, growth hormone peptides), including those labeled "research use only", whether or not sold under prescription or legal in the recipient's jurisdiction,” as of 23 September 2026.
The others are broader and quieter. Klaviyo's acceptable use policy says “You may not use the Services to offer products or services related to: ... Prescription medications, pharmaceutical products or services, medical therapies, telehealth, and other related technologies, products, or services,” as of 23 September 2026. The word peptide does not appear in it. What that means for a given store is a judgement someone at the platform makes, which is exactly why brands start pricing out servers. The full set of clauses, quoted in one table, is in our policy table for email platforms.
One thing to settle before you compare options: moving the mail does not move the rules about what the mail says. What you can write is set by the FTC and the FDA, not by your hosting choice, and the 2026 FDA warning letters cited website and marketing copy, not infrastructure. Owning the pipe removes a platform's discretion over your account. It removes nothing else.
Option 1: run your own mail server
A mail server is a small expense and a large standing job. In practice it is several pieces, not one. A mail transfer agent such as Postfix sends and receives. A mailbox layer such as Dovecot stores mail, and a spam filter sits in front of it. You maintain the DNS records yourself. For marketing mail you then add a self-hosted sending app such as Mautic on top of all of it. Each one is configured, patched and debugged by you. The job never ends because Gmail and Yahoo now publish hard requirements for senders. On your own server, every one of them is yours to meet and keep meeting. Quotes below are from each provider's own page, fetched 7 October 2026.
- Authentication. Google tells every sender to “Set up SPF or DKIM email authentication for your sending domains,” and Yahoo asks bulk senders to implement both and to “Publish a valid DMARC policy with at least p=none - DMARC must pass.” Google also requires every sender to “Use a TLS connection for transmitting email”, and senders above 5,000 messages a day to support one-click unsubscribe: “Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body.”
- Reverse DNS.Google requires you to “Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records.” It adds that “The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.” Yahoo asks the same: “Have a valid forward and reverse DNS record for your sending IPs.” You own this at the IP level, so your host has to let you set it.
- A spam rate you cannot see by default. Google states two numbers. Its requirement for all senders is to “Keep spam rates reported in Postmaster Tools below 0.3%.” Its monitoring guidance goes further: “Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.” Yahoo asks senders to “Keep your spam rate below 0.3%.” None of those numbers exists for you until you have registered for the reporting tools and somebody reads them.
- A complaint feedback loop.Yahoo is direct about it: “An active CFL is needed for all DKIM domains to make sure you're processing complaints quickly.” Enrolling is a form. Processing the complaints that then arrive is code you write.
- Bounce handling.Yahoo asks senders to “Monitor hard and soft bounces as well as inactive recipients” and to “Remove invalid recipients from your list promptly.” A platform does this silently. On your own server it is a queue, a parser and a suppression table.
- Unsubscribes on a clock.Yahoo asks that unsubscribe “Requests should be processed within 2 days.” That is a running job, not a page.
- Server security.Yahoo asks senders to “Maintain mail server security with the latest security patches to prevent unauthorized or anonymous use” and warns that “if your servers act as ‘open proxies’ or ‘open relays,’ spammers may attempt to send their own mail from your systems.” On your own server, patching on the day a fix ships is your job, and a missed one can put your IP addresses in other people's spam folders.
- Blocklists and throttling.A blocklist entry is cleared by whoever owns the address, and on your own server that is you. Google, in its guidance on shared IP addresses, says “Messages sent from IP addresses on a blocklist are more likely to be marked as spam.” Yahoo notes that it does “not publish specific guidelines for the numbers of connections you can concurrently use” and asks senders to “treat our resources with respect.” Delisting requests and connection tuning land on whoever is on call.
- Warm-up. Amazon's own documentation on dedicated IP addresses states that “Email providers are less likely to accept mail from new IP addresses that have little or no history.” Such mail “might end up in recipients' junk mail folders, or might be blocked altogether.” A brand new server starts with no history at all.
Three jobs, not one.Your team's mailboxes, your store's order confirmations and password resets, and your campaigns are three different sending jobs with three different failure modes. A self-hosted server that does all three puts one reputation behind all of them, which is why Yahoo asks senders not to mix them: “Don't send bulk/marketing email from the same IPs you use to send user mail, transactional mail, alerts, etc.” It adds that “Each IP and DKIM domain has a reputation, which can impact the delivery of your email.” Most brands that self-host end up running the mailboxes somewhere else anyway, and the question narrows to where the campaigns go. Our deliverability guide goes through each requirement in detail.
Option 2: a sending API such as Amazon SES, Postmark or SendGrid
A sending API takes the hardest infrastructure problems off your desk. The provider runs the IP addresses, the reputation and the delivery engine, and you call an endpoint. What it does not take off your desk is the marketing software: there are no flows, no drag-and-drop builder, no signup forms, no segments and no revenue reporting in a sending API. Those you build, and then maintain, on top of it.
It also does not remove a policy. You are simply under a different one, written by an infrastructure company instead of a marketing company. The AWS acceptable use policy that covers Amazon SES was last updated on 1 July 2021 and was checked on 7 October 2026. It says you may not use the services “to distribute, publish, send, or facilitate the sending of unsolicited mass email or other messages, promotions, advertising, or solicitations (or "spam").” It also reserves the right to act on that: “We may investigate any suspected violation of this Policy, and remove or disable access to any content or resource that violates this Policy.”
The Twilio acceptable use policy that covers SendGrid, last updated 12 May 2025 and checked on 7 October 2026, is broader still. It says “The prohibited conduct in this AUP is not exhaustive.” It says that “If Customer or any End User violates this AUP, Twilio may suspend Customer's use of the Services,” and that it “may be updated by Twilio from time to time upon reasonable notice.” Among the conduct it prohibits it lists “Violating laws, regulations, governmental orders, industry standards, or telecommunications providers' requirements or guidance in any applicable jurisdiction”.
Postmark is the only one of the three that publishes a category list. Section 5 of its terms of service is its acceptable use policy, effective 10 December 2024 and checked on 7 October 2026. It says “Without limiting any other right or remedy of AC PM, We may not allow the following businesses or types of services to use Postmark:” and the list that follows it includes “Pharmaceutical products” and “Other emails that we find, in our sole discretion, hurt our reputation or our deliverability”. It also reserves the right to “suspend or terminate your account”.
None of the three names peptides, and Postmark's list says pharmaceutical products, which is not the same word. Read each policy yourself before you build on it. All three are written so that the provider decides.
Option 3: a dedicated IP at a mainstream email platform
This is the option brands reach for first, and it is the one that solves the least. A dedicated IP changes which address your mail leaves on. It does not change whose terms your account sits under. If the reason you are moving is the pharmaceutical clause in your platform's acceptable use policy, a dedicated IP at that same platform leaves the clause exactly where it was.
A dedicated IP is also not automatically better for delivery. It helps once you send steady volume and can build a reputation on it. Below that, an inbox provider sees too little mail to trust, where a shared pool at least has other senders keeping it warm. Google describes the trade from the other side: “A shared IP address is an IP address used by more than one email sender. The activity of any senders using a shared IP address affects the reputation of all senders for that shared IP address.”
And a new dedicated IP has to be warmed up. Amazon's documentation puts a timeframe on it: “For some email providers, you can establish a positive reputation in around two weeks, while for others it may take up to six weeks.” It also says that while warming up “you should send emails to your most active users to ensure that your complaint rate remains low.” Plan for restricted sending across that window whichever way you move.
Option 4: a platform that runs its own servers for your category
The fourth option is the one that is easy to miss, because it looks like option three from the outside. A platform can run its own sending servers and IP addresses rather than reselling another provider's. When it does, there is no upstream email vendor with a clause of its own and a different risk appetite.
That is what Amino Engine is. Mail sends from your own domain, on servers and IP addresses we run, so no outside email provider sits above your account. New senders are warmed up over 42 days, which is the warm-up work from option one done as a default rather than a project. You also get what a sending API does not include. Flows, campaigns, a drag-and-drop builder, segments and revenue reporting are in the product. So are signup forms as a popup, flyout, embedded form or hosted page, with double opt-in built in. The flow library has 82 ready-made flows to start from.
Two details matter when you are comparing. Revenue is attributed to the last email click within five days, and opens never count. That lines up with how the inbox providers treat the metric: Google states plainly that it “doesn't track open rates.” Migration also does not cost you your suppression history. You import from Klaviyo or Brevo by CSV, and unsubscribes and bounces carry over as unsubscribes and bounces. The step by step is in our migration guide.
There is a WooCommerce plugin today and Shopify is next. For teams that want to build with an agent, there is an API and an MCP server: an AI agent can build flows and emails as drafts, and a person switches them live.
What each option costs you in work
The useful comparison is not a monthly figure, because the server is never the expensive part. It is who does the work, and for how long.
| Option | What it needs from your team | The standing job | What it does not remove |
|---|---|---|---|
| Your own mail server | Linux server administration, DNS, TLS and log reading, plus someone reachable when sending breaks, and the watching never stops | Bounces, complaint feedback, blocklist delistings, warm-up, suppression, connection tuning | Inbox provider rules, and it brings no marketing software with it |
| A sending API | Developer time to build flows, forms, segments and reporting on the API, and more developer time to keep them working | Suppression logic, templates, flows, forms, segments and reporting you wrote yourself | The provider's acceptable use policy, which it can update |
| A dedicated IP at your current platform | A warm-up window of roughly two to six weeks, the range Amazon's SES documentation gives, and steady volume after it | Keeping volume consistent enough to hold a reputation on one address | The clause that made you start looking |
| A platform running its own servers for your category | Your DNS records and a CSV import of your list | None of the above, and the warm-up runs as a default over 42 days | Inbox provider rules, which apply to every sender equally |
How to decide
Three questions settle it faster than a spreadsheet.
- Is the reason you are moving a policy clause about your category?If so, a different IP under the same policy changes nothing, and a sending API swaps one company's discretion for another's. The question that matters is who your upstream provider is.
- Do you have a mail engineer you can reach on a weekend? If the honest answer is no, option one is a risk you will discover during a launch, not during a quiet week.
- Do you need marketing software or just a pipe? If you need flows, forms, segments and revenue reporting, a sending API is the start of a build, not a purchase.
What the platform does, end to end, is on our email marketing for peptide brands page. Plan details, including email volume by plan and the plan that comes with your own sending IP: See pricing.
This is general information, not legal advice.