# Envello > Transactional email API with EU data residency, a 24-month price-stability pledge, and long log retention (7 days on the free tier, up to 365 days on paid plans). Envello is a solo-founder, bootstrapped company (not VC-backed). The API is live: account signup, domain verification (SPF/DKIM/DMARC), single and batch sending, delivery/open/click webhooks, suppression handling, and API-key management are all implemented and in production, not placeholder routes. Some backlog items described in the company's public planning docs are still unbuilt; treat only what's linked below as shipped. ## Product - [Homepage](https://envello.dev/): positioning and feature overview - [Pricing](https://envello.dev/pricing) ([plain text](https://envello.dev/pricing.md)): Free (3,000 emails/mo, no daily cap, 7-day retention), Pro (EUR 18-49/mo, 90-day retention), Scale (EUR 85-950/mo, 7-365 day configurable retention), Enterprise-lite (custom) - [Docs](https://envello.dev/docs): quickstart, API-key setup, domain verification ([plain text](https://envello.dev/docs.md)) - [API summary](https://envello.dev/api.md): base URL, auth, endpoints, curl example (plain text) - [For AI coding agents](https://envello.dev/ai-agents): copy-paste prompt for Claude Code, Cursor and similar agents - Use cases: [authentication emails](https://envello.dev/for/authentication-emails), [billing emails](https://envello.dev/for/billing-emails), [order notifications](https://envello.dev/for/order-notifications), [agencies](https://envello.dev/for/agencies) - [Integrations](https://envello.dev/integrations): SDKs, framework guides, SMTP relay, React Email, Supabase Auth - [SDKs & libraries](https://envello.dev/docs/sdks): Node, Python, Go, and PHP clients, plus the migration codemod - [Migration guide](https://envello.dev/docs/migrate): moving from another provider, DNS changeover, dual-sending - [Send from your language or framework](https://envello.dev/docs/languages): framework-specific guides (Django, Rails, Laravel, Next.js, and others) - [GDPR & data residency](https://envello.dev/gdpr): DPA on every plan including free, data-flow diagram, subprocessor list on request - [Security](https://envello.dev/security): encryption in transit, API-key hashing, signed webhooks, tested backups - [Changelog](https://envello.dev/changelog): product release notes ([RSS](https://envello.dev/changelog/feed.xml)) - [Status](https://envello.dev/status): system status and incident history ([JSON](https://envello.dev/status/status.json)) ## Framework guides - [Send email with Node.js](https://envello.dev/nodejs) - [Send email with Python](https://envello.dev/python) - [Send email with Next.js](https://envello.dev/nextjs) - [Send email with NestJS](https://envello.dev/nestjs) - [Send email with Remix](https://envello.dev/remix) - [Send email with Nuxt.js](https://envello.dev/nuxt) - [Send email with SvelteKit](https://envello.dev/sveltekit) - [Send email with Cloudflare Workers](https://envello.dev/cloudflare-workers) - [Send email with Deno](https://envello.dev/deno) - [Send email with Supabase Edge Functions](https://envello.dev/supabase) - [Send email with Django](https://envello.dev/django) - [Send email with FastAPI](https://envello.dev/fastapi) - [Send email with Rails](https://envello.dev/rails) - [Send email with Laravel](https://envello.dev/laravel) - [Send email with Go](https://envello.dev/go) - [Send email with ASP.NET Core](https://envello.dev/dotnet) - [Send email with Spring Boot](https://envello.dev/spring-boot) - [Send email with Elixir / Phoenix](https://envello.dev/elixir) ## Migration guides - [All alternatives](https://envello.dev/alternatives): hub of switching guides by provider - [Resend alternative: migrate to Envello](https://envello.dev/migrate/resend) - [Postmark alternative: migrate to Envello](https://envello.dev/migrate/postmark) - [SendGrid alternative: migrate to Envello](https://envello.dev/migrate/sendgrid) - [Mailgun alternative: migrate to Envello](https://envello.dev/migrate/mailgun) - [Amazon SES alternative: migrate to Envello](https://envello.dev/migrate/amazon-ses) - [Brevo alternative: migrate to Envello](https://envello.dev/migrate/brevo) - [Mailtrap alternative: migrate to Envello](https://envello.dev/migrate/mailtrap) - [MailerSend alternative: migrate to Envello](https://envello.dev/migrate/mailersend) - [SMTP2GO alternative: migrate to Envello](https://envello.dev/migrate/smtp2go) - [Scaleway alternative: migrate to Envello](https://envello.dev/migrate/scaleway) - [MailPace alternative: migrate to Envello](https://envello.dev/migrate/mailpace) - [Flowmailer alternative: migrate to Envello](https://envello.dev/migrate/flowmailer) ## Buyer's guides - [Best EU email API](https://envello.dev/alternatives/best-eu-email-api): what to check when choosing an EU-hosted provider - [Best Node.js email API](https://envello.dev/alternatives/best-nodejs-email-api): evaluation criteria for Node and TypeScript senders ## Free tools - [Email RFC reference](https://envello.dev/email-rfcs): the IETF email standards developers need, grouped by job - [SPF, DKIM & DMARC checker](https://envello.dev/tools/spf-dkim-dmarc-checker): check a domain's email-authentication DNS records - [DMARC aggregate report analyzer](https://envello.dev/tools/dmarc-report-analyzer): parse a DMARC XML report in the browser, nothing uploaded - [SMTP & bounce error code lookup](https://envello.dev/tools/smtp-error-codes): what an SMTP reply or bounce code means and how to fix it - [GDPR / DPA compliance checklist](https://envello.dev/tools/gdpr-dpa-checklist): score an email vendor's data-processing posture - [BIMI record generator](https://envello.dev/tools/bimi-generator): build the _bimi TXT record and check an SVG logo, in the browser ## Blog - [Blog index](https://envello.dev/blog): deliverability, compliance, pricing, and migration guides ([RSS](https://envello.dev/blog/feed.xml)) - [What is transactional email](https://envello.dev/blog/what-is-transactional-email): pillar guide for developers - [Email deliverability guide](https://envello.dev/blog/email-deliverability-guide): pillar guide, authentication through monitoring - [SPF, DKIM and DMARC explained](https://envello.dev/blog/spf-dkim-dmarc-explained): how the three email-auth standards work together - [GDPR-compliant transactional email: a developer's guide](https://envello.dev/blog/gdpr-compliant-transactional-email-developer-guide): pillar guide, lawful basis through breach notification - [Why EU data residency matters for transactional email](https://envello.dev/blog/eu-data-residency-transactional-email): what "EU-hosted" actually requires - [Does the US CLOUD Act reach your EU-hosted provider](https://envello.dev/blog/us-cloud-act-eu-data-residency): how the US CLOUD Act interacts with EU data-residency claims - [Hidden costs in email API pricing](https://envello.dev/blog/hidden-costs-email-api-pricing): overage rates, retention gating, and other line items to check - [Bulk sender requirements: Gmail and Yahoo 2026](https://envello.dev/blog/bulk-sender-requirements-gmail-yahoo-2026): current authentication and complaint-rate rules - [Monthly deliverability report](https://envello.dev/blog/deliverability-report): Envello's commitment to publish bounce, complaint, and delivery-time numbers each month ## Key Facts - Company: AKTAI LTD, registered in England and Wales, Companies House No. 17199439, ICO No. ZC151787 - Bootstrapped and solo-founder, not VC-backed - Sending infrastructure: AWS SES, eu-central-1 (Frankfurt) - Interfaces: REST API, SMTP relay, official SDKs for Node, Python, Go, and PHP - Differentiators: EU data residency by default (API, database, logs, backups), signed DPA on every plan including free, 24-month price lock with 6-month change notice, configurable 7-365 day log retention - Free tier: 3,000 emails/month, no daily cap, no credit card ## Contact - Website: https://envello.dev - Email: hello@envello.dev - Imprint: https://envello.dev/legal/imprint ## Optional - [Full text of key pages](https://envello.dev/llms-full.txt): this index plus the pillar posts in full - [Terms of service](https://envello.dev/legal/terms) - [Privacy policy](https://envello.dev/legal/privacy) - [Acceptable use policy](https://envello.dev/legal/aup) --- # Full text of key pages The sections below repeat the pillar blog posts listed above in full. ## What is transactional email? A guide for developers Source: https://envello.dev/blog/what-is-transactional-email Transactional email is any message triggered by a user action: password resets, order confirmations, login alerts. What it is and how to get it right. Every time a user resets a password, completes a purchase, or gets a login alert, the message that lands in their inbox is transactional email. It's the infrastructure behind the moments users actually expect to hear from you, not because you decided to send a campaign, but because they did something that requires a response. Transactional email is often invisible until it breaks. Nobody notices a fast password reset email. Everybody notices when it doesn't arrive. That asymmetry makes transactional email one of the most quietly critical parts of any web application, and one of the least understood outside the teams that build it. This guide covers what transactional email actually is, how it differs from marketing email (legally and technically), the common types, the architecture behind reliable delivery, and the decisions you'll face when building or choosing a sending system. ### Definition: what makes an email transactional A transactional email is a message sent to a single recipient in direct response to an action they took or a state change in their account. The content of the message relates to a transaction, relationship, or ongoing interaction the recipient already has with the sender. The defining characteristic is that the recipient expects it. They clicked 'reset password,' so they expect a reset link. They placed an order, so they expect a confirmation. They triggered a 2FA challenge, so they expect a code. The message exists because the user did something, not because a marketer scheduled it. This matters beyond semantics. Email regulations in the EU (GDPR), the US (CAN-SPAM), and Canada (CASL) treat transactional email differently from marketing email. Transactional messages are generally exempt from opt-in/opt-out requirements because withholding them would break the service the user signed up for. A password reset email isn't optional, so requiring an unsubscribe link on it doesn't make sense. That said, the exemption has limits. If your 'order confirmation' includes a promotional section pushing related products, regulators and mailbox providers may reclassify it as marketing. Keep transactional messages focused on the transaction. ### Transactional vs. marketing email Transactional email is triggered by one recipient's action and sent to that recipient alone; marketing email is composed as a campaign and sent in bulk to a list the recipient opted into. That single difference drives three practical consequences: legal compliance, deliverability, and infrastructure. Marketing email (newsletters, promotions, drip campaigns) requires explicit opt-in consent, must include an unsubscribe mechanism, and is subject to stricter sending regulations. Transactional email is exempt from most of these requirements because the recipient initiated the interaction. Deliverability is the second reason to keep them separate. Mailbox providers like Gmail and Outlook track sender reputation per sending domain and IP. A marketing campaign that generates complaint spikes can drag down the reputation of your transactional sends if they share the same infrastructure. A bounce from a purchased list shouldn't delay a password reset email. Infrastructure is the third. Marketing email is batched: you compose a campaign, segment an audience, and send thousands of messages at once. Transactional email is event-driven: a single message fires in response to a single user action, and latency matters. A marketing platform optimized for batch throughput isn't necessarily fast at single-message, low-latency delivery. Most teams that start by routing everything through one provider eventually split transactional and marketing sending onto separate domains, separate IPs, and often separate providers. Starting with that separation is cheaper than untangling it later. | | Transactional | Marketing | | --- | --- | --- | | Trigger | A user action or account state change | A campaign or schedule you set | | Consent | Not required (service-necessary) | Explicit opt-in required | | Unsubscribe link | Not required | Required | | Recipients per send | One | Hundreds to millions | | Latency sensitivity | High (seconds matter) | Low (batch delivery) | | Sending infrastructure | Isolated domain and IP | Separate domain, IP, or provider | ### Common types of transactional email Transactional email in a typical SaaS or e-commerce application falls into six categories: authentication, account lifecycle, commerce and billing, security alerts, collaboration and workflow, and system and operational notices. Each has its own latency and deliverability profile, and authentication messages are the most time-sensitive of the set. - Authentication messages: password reset links, email verification codes, two-factor authentication (2FA/OTP) codes, magic link logins. These are the most time-sensitive transactional emails. A 2FA code that arrives 30 seconds late breaks the login flow. - Account lifecycle: welcome emails (the transactional kind, confirming signup, not the marketing kind), account suspension notices, plan change confirmations, account deletion confirmations. - Commerce and billing: order confirmations, shipping notifications, delivery updates, receipts, invoices, failed payment (dunning) notices, refund confirmations. - Security alerts: new device login alerts, password change confirmations, unusual activity warnings, API key rotation notices. - Collaboration and workflow: team invitation emails, shared document notifications, comment and mention alerts, approval request notifications. - System and operational: scheduled maintenance notices, usage threshold warnings, certificate expiration alerts, API deprecation notices. ### Why transactional email needs its own infrastructure Transactional email needs dedicated sending infrastructure once you cross three thresholds: volume, deliverability, and visibility. Below those, your framework's built-in mailer (Django's send_mail(), Rails' Action Mailer, Laravel's Mail facade) pointed at your host's SMTP relay works fine, and for a side project with a handful of users it is the right call. The thresholds: first, volume, because shared SMTP relays have rate limits, and hitting them means your password reset queues behind someone else's newsletter. Second, deliverability, because without proper SPF, DKIM, and DMARC authentication, messages land in spam. Third, visibility, because when a send fails, SMTP gives you a bounce message in a log file somewhere, while an API-based provider gives you webhook events, delivery status, and queryable logs. A transactional email API (Envello, Resend, Postmark, SendGrid, Mailgun, Amazon SES) handles the parts that are hard to do well yourself: authenticated sending domains, IP reputation management, bounce and complaint processing, delivery event tracking, and retry logic for temporary failures. The trade-off is dependency on an external service. The mitigation is that a well-designed email API integration is a thin layer: a single HTTP call with from, to, subject, and html fields. Switching providers is an endpoint and auth header change, not a rewrite, as long as you haven't locked yourself into provider-specific template systems or SDKs with deep framework integration. ### The anatomy of a transactional email send Here's what happens when your application sends a transactional email through an API provider, from the moment the user clicks 'reset password' to the message appearing in their inbox. - Your application makes an HTTP POST to the provider's API with the message payload: sender address, recipient, subject, HTML body (and optionally a plain-text fallback). - The provider validates the request: is the API key valid, is the sending domain verified, is the recipient on the suppression list (previous hard bounce or complaint)? - If validation passes, the message enters the send queue. Most providers return a 202 Accepted at this point, not a 200, because the actual SMTP delivery hasn't happened yet. - The provider's sending infrastructure connects to the recipient's mail server (MX lookup), negotiates TLS, and transmits the message. SPF, DKIM, and DMARC records on your domain authenticate the message so the receiving server knows the provider is authorized to send on your behalf. - The receiving mail server accepts or rejects the message. A rejection is a bounce: hard (permanent, like a nonexistent address) or soft (temporary, like a full mailbox). - If accepted, the message enters the recipient's mailbox. The provider fires a 'delivered' webhook event to your application. If the recipient opens, clicks, or marks the message as spam, those events fire too. ### Authentication: SPF, DKIM, and DMARC Email authentication is how receiving mail servers verify that a message actually came from the domain it claims to be from. Without it, anyone can forge your From address, and mailbox providers will treat your legitimate messages with suspicion. SPF (Sender Policy Framework) is a DNS TXT record listing which IP addresses are authorized to send email for your domain. When your email provider's servers send a message as you@yourdomain.com, the receiving server checks your SPF record to confirm those IPs are allowed. SPF has a hard limit of 10 DNS lookups per evaluation (RFC 7208); exceed it and the check returns permerror and fails, so keep the record flat rather than chaining many include: statements. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message header. Your email provider signs each outgoing message with a private key; the receiving server uses the public key published in your DNS to verify the signature wasn't tampered with in transit. Use a 2048-bit DKIM key; 1024-bit keys are now treated as weak and some mailbox providers discount them. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy: what should a receiving server do if a message fails both checks? The three policies are 'none' (monitor only), 'quarantine' (send to spam), and 'reject' (block entirely). Start with 'none' to collect data, then move to 'reject' once you're confident all legitimate sending sources are authenticated. Setting up all three is table stakes for transactional email. Skip any of them and you're leaving deliverability on the table. Most email API providers walk you through the DNS records during domain verification. ### Deliverability: getting to the inbox Authentication gets your message accepted by the receiving server. Deliverability determines whether it reaches the inbox or the spam folder. Sender reputation is the primary factor. Mailbox providers track bounce rates, complaint rates (users clicking 'mark as spam'), and engagement patterns per sending domain and IP. High bounce rates signal a sender who doesn't maintain clean lists. High complaint rates signal unwanted mail. Both damage your reputation and move future messages toward spam. For transactional email, the most common deliverability problems are sending to addresses that no longer exist (hard bounces, which must be suppressed immediately), sharing infrastructure with marketing sends that generate complaints, and failing to authenticate your domain properly. The numbers are not arbitrary. Gmail and Yahoo's bulk-sender rules, in effect since 2024, require senders of more than 5,000 messages a day to a given provider to keep the user-reported spam rate below 0.3%, with 0.1% as the safe operating target. Track your bounce rate (keep it under 2%), complaint rate (under 0.1%), and delivery rate over time, and investigate before any of them drifts. A good email API provider surfaces these metrics in a dashboard and via webhooks so you can react quickly. ### Handling bounces, complaints, and suppressions When a message bounces or generates a complaint, your system needs to handle it, not just log it. Hard bounces (550 errors: address doesn't exist, domain doesn't exist) must result in immediate suppression. Never send to a hard-bounced address again. Continuing to send to invalid addresses is the fastest way to damage your sender reputation. Soft bounces (temporary failures: mailbox full, server temporarily unavailable) can be retried, but with limits. Most providers handle retry logic automatically with exponential backoff. If a soft bounce persists across multiple retries, treat it as a hard bounce. Complaints (when a recipient marks your message as spam via the feedback loop) should also suppress future sends to that address. Even if the complaint was accidental, continuing to send to someone who complained risks further damage. A suppression list is a per-account blocklist of addresses you should never send to again. Your email API provider maintains one, and you should respect it in your application code too: check before sending, and surface the suppression reason to your support team so they can handle user inquiries. ### How to choose a transactional email provider Transactional email providers fall into three categories: raw cloud infrastructure, developer-focused email APIs, and all-in-one platforms that combine marketing and transactional sending. Which category fits depends on how much of the deliverability work you want to own yourself. The factors that actually matter when choosing: - Data residency: if your users are in the EU and you're subject to GDPR, does the provider offer EU-hosted infrastructure? Or does your data cross the Atlantic? - API design: is the API simple enough that switching providers later is a one-hour job, not a one-week job? Avoid deep SDK lock-in and provider-specific template systems. - Log retention: when a user reports 'I never got that email,' can you look up what happened 30, 60, or 90 days later? Or do logs disappear after a week? - Pricing predictability: does the provider have a track record of stable pricing, or has it changed terms on existing customers without notice? - Webhook reliability: are delivery events (delivered, bounced, complained) sent reliably, with retry on failure? Can you verify webhook signatures to confirm they're authentic? - Suppression handling: does the provider automatically suppress hard bounces and complaints? Can you query and manage the suppression list via API? | Category | Examples | Setup effort | Fits when | | --- | --- | --- | --- | | Raw cloud infrastructure | Amazon SES | High | You have in-house deliverability expertise and want low-level control | | Developer email API | Resend, Postmark, Envello | Low | You want a fast integration, structured webhooks, and queryable logs | | All-in-one platform | SendGrid, Brevo, Mailgun | Medium | You need marketing and transactional sending in one product | ### How to build a transactional email integration The simplest integration is a single function that makes an HTTP POST to your provider's API. Here's the general pattern, applicable to any language and any provider. - Store your API key in an environment variable, never in source code. - Create a send function that accepts from, to, subject, and html (plus optional text fallback, cc, bcc, attachments). - Make the HTTP call. Handle the response: a 2xx means the message was accepted for delivery (not necessarily delivered yet). A 4xx means validation failed (bad address, unverified domain, suppressed recipient). A 5xx means a server-side error, retry with backoff. - For anything triggered by a user action in a web request (signup confirmation, password reset), send from a background job or task queue so a slow API response doesn't block your HTTP response to the user. - Set up a webhook endpoint to receive delivery events. At minimum, handle bounces and complaints by suppressing future sends. Log delivery confirmations for debugging. ### Email content and design Transactional emails don't need to be beautiful, but they do need to be clear, fast to render, and functional across email clients. Keep the message focused on the action: a password reset email contains a reset link and maybe an expiry note. An order confirmation contains the order details. Don't stuff promotional content into transactional messages; it hurts deliverability and may reclassify the message under stricter marketing regulations. For rendering, you have three common approaches. Plain HTML with inline CSS is the most portable across email clients. MJML is a markup language that compiles to email-compatible HTML and handles the quirks of Outlook and Gmail rendering. React Email lets you build email templates as React components, which is convenient if your frontend is already React-based. Whatever you choose, render the final HTML in your application and send it via the API. This keeps your templates in version control, testable, and free of provider lock-in. Avoid provider-specific template systems that store templates on their servers and inject variables at send time, as they make switching providers harder. ### How to test transactional email Don't test transactional email by sending to real inboxes during development. Use one of these approaches instead. Most email API providers offer a test or sandbox mode: your API call is accepted and validated, webhook events fire, but no message is actually delivered. This is the closest to production behavior without reaching a real inbox. Tools like Mailtrap, MailHog, or Mailpit capture outgoing messages and let you inspect them in a web UI. These work well for local development, especially when testing HTML rendering across different email clients. For automated tests, mock the HTTP call to your provider's API and verify the request payload: correct recipient, correct subject, correct template rendered. Don't test your provider's delivery infrastructure; test that your application constructs the right message. ### Monitoring and alerting Transactional email is infrastructure, and like any infrastructure it needs monitoring. Track delivery rate (percentage of sends that result in a 'delivered' event), bounce rate, complaint rate, and median send latency (time from API call to delivered event). Set alerts on any metric that drifts outside normal bounds. A sudden spike in bounces could mean a bad import touched your user database. A drop in delivery rate could mean an authentication record was accidentally deleted. Most email API providers surface these metrics in a dashboard. If yours doesn't, build the monitoring yourself from webhook events. The data is there; it just needs to be aggregated. Review delivery logs periodically, not just when something breaks. A slow upward trend in soft bounces is easy to miss if you only look at dashboards during incidents. ### GDPR and data privacy considerations Transactional email involves processing personal data: at minimum, the recipient's email address. Under GDPR, this makes your email provider a data processor, and you need a Data Processing Agreement (DPA) in place before sending any email through them. Data residency matters: if your provider processes email through US-based infrastructure, you're transferring personal data outside the EU, which requires additional safeguards (Standard Contractual Clauses at minimum). An EU-hosted provider avoids this complexity entirely. Recipient email addresses should not appear in application logs. Log a message ID or a hashed identifier for debugging, not the raw address. Your email provider's logs are the place to look up what happened to a specific message, not your application's stdout. Retention policies must be documented and enforced. If your privacy policy says you retain email logs for 90 days, your provider's actual retention must match. And 'delete' must mean delete, not soft-delete to an archive that lives forever. ### Summary Transactional email is the infrastructure behind every user-triggered message your application sends. It differs from marketing email in legal treatment, deliverability requirements, and technical architecture. Getting it right means authenticating your domain (SPF, DKIM, DMARC), handling bounces and complaints, keeping transactional and marketing sends on separate infrastructure, and choosing a provider whose data practices match your compliance requirements. It's not glamorous work. But when a user clicks 'reset password' and the email arrives in three seconds, in their inbox and not their spam folder, that's transactional email doing its job. ## Email deliverability guide: reach the inbox, not spam Source: https://envello.dev/blog/email-deliverability-guide A practical guide to email deliverability for developers: SPF, DKIM, DMARC, sender reputation, bounce handling, and monitoring, with concrete thresholds. Deliverability is the gap between 'the email was sent' and 'the email reached the inbox.' Your application can send a message successfully (the API returns 202, the SMTP server accepts it), and the recipient still never sees it because it landed in spam, was silently dropped, or bounced. For transactional email, deliverability is everything. A marketing email that lands in the Promotions tab is an inconvenience. A password reset email that lands in spam is a broken product. Users don't check spam for password resets; they click 'reset' again, then again, then contact support, then lose trust in your application. This guide covers the technical and operational practices that determine whether your transactional emails reach the inbox. It's written for developers who are setting up transactional email for the first time or debugging deliverability problems with an existing setup. ### Authentication: the foundation Email authentication is the single most important factor in deliverability. Without it, receiving mail servers have no way to verify that a message claiming to be from your domain actually came from an authorized sender. The three protocols you need are SPF, DKIM, and DMARC. ### SPF (Sender Policy Framework) SPF is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email for your domain. When a receiving server gets a message from your domain, it checks your SPF record to see if the sending server's IP is on the list. A typical SPF record for a domain using Envello looks like: v=spf1 include:_spf.envello.dev ~all. The 'include' directive delegates to your provider's SPF record, which lists their sending IPs. The '~all' at the end is a soft fail for any IP not on the list. Common mistakes: having multiple SPF records on the same domain (only the first is evaluated, the rest are ignored), exceeding the 10 DNS lookup limit (each 'include' counts as a lookup, and nested includes compound), and forgetting to add a provider after setting them up for sending. Check your SPF record with a DNS lookup tool. If you're getting soft fails or permerrors, fix the record before worrying about anything else. ### DKIM (DomainKeys Identified Mail) DKIM adds a cryptographic signature to each outgoing message. Your email provider signs the message with a private key; the receiving server retrieves your public key from a DNS CNAME or TXT record and verifies the signature. If the signature is valid, the server knows the message wasn't tampered with in transit and that an authorized sender produced it. Your email provider generates the DKIM key pair during domain setup and gives you one or two DNS records to publish. Once published, every message sent through that provider for your domain gets signed automatically. DKIM alignment matters for DMARC: the domain in the DKIM signature (the d= value) must match the From domain in the message header. If your provider signs with a different domain (some do by default), DMARC alignment fails even though the signature itself is valid. Verify that your provider signs with your domain, not theirs. ### DMARC (Domain-based Message Authentication, Reporting, and Conformance) DMARC ties SPF and DKIM together and tells receiving servers what to do when neither passes. It also sets up reporting so you can see who is sending email as your domain, whether legitimate or not. DMARC has three policy levels, and you move through them in order as you gain confidence that every legitimate source authenticates: | Policy | What the receiver does on failure | When to use it | | --- | --- | --- | | p=none | Nothing; delivers as normal, sends you reports | Weeks 1 to 4, while you confirm every legitimate source passes | | p=quarantine | Delivers failing mail to the spam folder | After none looks clean, as a safety step before reject | | p=reject | Blocks failing mail outright | The goal state, once no legitimate source is failing | ### Rolling out a DMARC policy safely Start with p=none and the rua tag pointing to an address where you can receive aggregate reports: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. Monitor the reports for a few weeks to make sure all legitimate sending sources pass authentication. Then move to p=quarantine, monitor again, and finally p=reject. Skipping straight to p=reject without monitoring is risky: if a legitimate sending source (your application, a SaaS tool that sends on your behalf, a forwarding service) fails authentication, those messages get blocked. The monitoring phase catches these before they become outages. For new domains with no legacy sending, the ramp from none to reject can happen in a week. For established domains with multiple sending sources, give it a month. ### Sender reputation Authentication gets your message accepted. Reputation determines inbox vs. spam. Mailbox providers (Gmail, Outlook, Yahoo, and others) maintain internal sender scores based on your domain's and IP's sending history. The score is influenced by bounce rate, complaint rate, engagement signals (opens, clicks, replies vs. deletes-without-opening), spam trap hits, and volume consistency. You don't get to see the score directly. Google Postmaster Tools shows some reputation data for Gmail; Microsoft SNDS shows some for Outlook. Beyond that, you infer reputation from your delivery metrics. For transactional email, the biggest reputation risks are sending to invalid addresses (bounces), sharing IP space with senders who generate complaints, and sudden volume spikes that look like a compromised account. ### Bounce handling Bounces are the most direct signal to mailbox providers about your list quality. There are two types, and they require different handling. Hard bounces (5xx SMTP errors: '550 User unknown,' '550 Domain not found') are permanent. The address doesn't exist and never will. Suppress it immediately, meaning add it to your suppression list and never attempt delivery to that address again. Continuing to send to hard-bounced addresses tells mailbox providers you don't maintain your list, which damages reputation. Soft bounces (4xx SMTP errors: '452 Mailbox full,' '421 Try again later') are temporary. Most email providers retry soft bounces automatically with exponential backoff. If a soft bounce persists across multiple retry cycles (typically 24-72 hours), treat it as a hard bounce and suppress. Target: keep your hard bounce rate under 2%. If it's consistently above that, something is wrong with how addresses enter your system. Common causes: no email verification at signup, accepting typo-ridden addresses without validation, or importing old user lists without cleaning them first. ### Complaint handling A complaint happens when a recipient clicks 'Report spam' or 'Mark as junk' in their email client. The mailbox provider sends a feedback loop (FBL) notification to your email provider, who passes it along as a webhook event. Complaints are the most damaging signal for sender reputation. Gmail's threshold is 0.1%: if more than 1 in 1,000 recipients complain, your reputation starts taking hits. Other providers have similar thresholds. For transactional email, complaints are rare because the messages are expected. When they do happen, it's usually because the user doesn't recognize the sender (use a clear, recognizable From name), the message arrived too late to be useful, or the content was confusingly similar to marketing. When a complaint fires, suppress that address. Even if it was accidental, sending again to someone who complained risks another complaint. Your provider's suppression list handles this automatically; make sure your application respects it too. ### Warming up a new domain or IP Warmup is the process of gradually increasing sending volume from a new domain or IP over 2 to 4 weeks so mailbox providers can build a positive reputation profile for it. A brand-new domain or IP has no reputation, and providers are cautious with unknown senders: early messages face higher scrutiny, slower inbox placement, or temporary rate limiting. Start with your most engaged users (those most likely to open and interact with the message), send small batches, and ramp volume week by week. A reasonable warmup ladder for a new transactional domain: - Week 1: 50-200 emails/day, prioritizing email-verified users - Week 2: 500-1,000 emails/day, expanding to all active users - Week 3: 2,000-5,000 emails/day, approaching normal volume - Week 4: full volume, monitoring metrics throughout ### How much warmup a shared pool needs vs a dedicated IP Monitor bounce rate, complaint rate, and inbox placement at each stage of the ramp. If any metric spikes, hold at the current volume until it stabilizes before ramping further. For shared-IP sending (most providers, including Envello's default shared pool), warmup is less critical because the IP already has established reputation from other senders. Domain warmup still matters, but the ramp can be faster. For dedicated IPs (available on Envello's Scale plan), warmup is essential. A dedicated IP starts cold, and sending high volume immediately from a cold IP is the fastest way to land in spam across all major mailbox providers. ### Suppression lists A suppression list is a per-account record of email addresses you should never send to again. It typically includes hard-bounced addresses, addresses that generated complaints, and addresses manually added (user unsubscribe requests, legal requests). Your email provider maintains a suppression list and should automatically prevent sends to suppressed addresses (returning an error instead of accepting the message). Check that your provider does this, and check that your application handles the error gracefully: don't retry a suppressed send, surface the suppression reason to your support team. Suppression lists should be append-mostly. Removing an address from suppression and attempting delivery again is risky: if the address bounced before, it'll probably bounce again, and the second bounce damages reputation more than the first because it shows you didn't learn from it. ### Content and formatting factors Content plays a smaller role in deliverability than authentication and reputation, but it's not zero. Spam filters look for patterns in message content, headers, and structure. For transactional email, the main content-related risks are: HTML-only messages with no plain-text alternative (some filters flag this), a high image-to-text ratio, URL shorteners in links (which look like they're hiding the destination), and missing or suspicious List-Unsubscribe headers. Best practices: always include a plain-text version alongside HTML, use your own domain for links (not shortened URLs), keep the message focused on the transaction (no promotional sidebars or 'you might also like' sections), and set the Subject to clearly describe the message content. The From name matters more than most developers think. Use a recognizable name: 'Acme' or 'Acme Security' rather than 'noreply@acme.com.' Recipients who don't recognize the sender are more likely to ignore, delete, or report the message. ### Monitoring deliverability You can't improve what you don't measure. Track five metrics continuously, not just when something breaks: delivery rate, bounce rate, complaint rate, inbox placement, and send latency. | Metric | Target | What it measures / where to see it | | --- | --- | --- | | Delivery rate | Above 98% | Sends confirmed delivered to the recipient's server, not just accepted by your provider | | Hard bounce rate | Below 2%, ideally below 0.5% | Sends that hit a permanent failure; your provider's dashboard and webhooks | | Complaint rate | Below 0.1% | Delivered messages the recipient marked as spam, via feedback loops | | Inbox placement | As high as possible | Delivered mail landing in the inbox vs spam; partial visibility in Google Postmaster Tools for Gmail | | Send latency | Seconds, not minutes | API call to delivery confirmation; a 5-minute password reset feels broken | ### Alerts and diagnosing a delivery problem Set up alerts on bounce rate and complaint rate. A sudden spike in either usually means something broke: a bad user import, a code change that sends to the wrong audience, or an authentication record that was accidentally deleted. Review Google Postmaster Tools weekly if you have significant Gmail volume. It shows domain reputation, spam rate, authentication pass rates, and delivery errors. Microsoft SNDS provides similar data for Outlook/Hotmail. Your email provider's dashboard is the first place to look when diagnosing a delivery problem. Check the event timeline for the specific message: was it accepted? Delivered? Bounced? Delayed? The event log tells you where in the pipeline the problem occurred. ### Common deliverability problems and fixes Here are the issues you'll encounter most often, with concrete fixes. - Messages landing in spam for Gmail users: check Google Postmaster Tools for reputation. Verify SPF, DKIM, and DMARC all pass (use the 'Show original' feature in Gmail to inspect headers). If reputation is 'Bad,' investigate recent bounce/complaint spikes. - High bounce rate after a deployment: a code change probably introduced a bug in address handling, sending to test addresses, or breaking the email verification flow. Roll back the change, suppress the bounced addresses, and fix the bug. - Sudden complaint spike: check whether a transactional message was accidentally sent to a marketing segment, or if a code change made a message look like marketing (added promotional content, changed the From name to something unrecognizable). - Intermittent delivery delays: check your provider's status page. If the provider is healthy, check whether your sending volume spiked suddenly (which can trigger rate limiting from mailbox providers). Smoothing send volume with a queue helps. - Authentication failures (SPF/DKIM/DMARC): run your domain through a checker tool. Common causes: DNS propagation lag after a record change, a deleted DKIM record, or an SPF record that exceeded the 10-lookup limit after adding a new service. ### Dedicated IPs vs. shared pools A shared IP pool sends your mail from IPs used by other customers of the same provider, so your reputation is partly tied to theirs. A dedicated IP is yours alone: your reputation is entirely your own, but you have to generate enough volume to keep it warm and you warm it from scratch. | | Shared pool | Dedicated IP | | --- | --- | --- | | Reputation | Shared with other senders on the pool | Entirely your own | | Volume needed | None | Roughly 50,000+ emails/month to stay warm | | Warmup | Minimal; the IP is already warm | Required; ramp over 2 to 4 weeks from cold | | Best for | Under 100,000 emails/month | 100,000+/month, or when isolation is contractually required | ### Choosing between a dedicated IP and a shared pool The volume threshold is the deciding factor. You need enough volume, typically 50,000 or more emails a month, to maintain a warm dedicated IP. For most transactional senders under 100,000 emails/month, a shared pool from a reputable provider is the better choice. The provider maintains the IP reputation across all senders, which means you benefit from their aggregate volume and reputation management. A dedicated IP at low volume can actually hurt deliverability because mailbox providers don't have enough data to build a confident reputation profile. Consider a dedicated IP if you send 100,000+ emails/month, if you need to isolate your reputation from other senders on the pool, or if a customer's security requirements mandate a dedicated sending infrastructure. ### Blocklist monitoring Blocklists (sometimes called blacklists) are databases of IP addresses and domains identified as spam sources. If your sending IP or domain appears on a major blocklist (Spamhaus, Barracuda, SORBS), deliverability drops immediately. For shared-IP sending, your provider monitors and manages blocklist status for the pool. For dedicated IPs, you're responsible. Check your IP against major blocklists regularly (MXToolbox is a common free tool), and act immediately if listed. Getting delisted usually involves identifying and fixing the root cause (a spike in bounces or complaints, an open relay, a compromised account), then submitting a delisting request to the blocklist operator. Most operators have automated delisting forms; Spamhaus requires manual review for persistent issues. Prevention is better than delisting: maintain clean sending practices, suppress bounces and complaints immediately, and monitor your metrics so problems don't escalate to a blocklist event. ### Summary: the deliverability checklist Deliverability isn't a one-time setup. It's an ongoing practice. Here's the checklist, in priority order. - Authenticate your domain: SPF, DKIM, and DMARC all configured and passing. DMARC policy at p=reject once you've confirmed all legitimate sources pass. - Handle bounces: hard bounces suppressed immediately, soft bounces retried then suppressed. Bounce rate under 2%. - Handle complaints: complaints suppressed immediately. Complaint rate under 0.1%. - Warm up new domains/IPs: gradual volume ramp over 2-4 weeks, monitoring metrics at each stage. - Separate transactional from marketing: different domains, different IPs, ideally different providers. - Monitor continuously: delivery rate, bounce rate, complaint rate, and send latency. Alerts on anomalies. - Keep content focused: no promotional content in transactional messages, recognizable From name, plain-text version included. - Use a reputable provider: one that handles suppression automatically, provides webhook events, and surfaces delivery metrics. ## SPF, DKIM, and DMARC explained for SaaS founders Source: https://envello.dev/blog/spf-dkim-dmarc-explained The three DNS records that decide whether your transactional email lands in the inbox or the spam folder, in plain language. Every mailbox provider (Gmail, Outlook, Yahoo) runs the same basic question against every message that arrives: is this sender who they claim to be? SPF, DKIM, and DMARC are the three DNS records that answer that question. Get them wrong and your password-reset emails land in spam. Get them right and they're invisible, which is exactly the point. ### SPF: who's allowed to send SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are allowed to send email claiming to be from your domain. When a receiving server gets a message from acme.eu, it checks whether the sending IP is on acme.eu's approved list. A typical record looks like: v=spf1 include:_spf.envello.dev ~all. The include tells receivers to also trust our sending IPs. The ~all at the end is a soft-fail: messages from unlisted servers get flagged, not outright rejected. ### DKIM: a cryptographic signature DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The receiving server looks up your public key in DNS and verifies the signature matches. If anything in the message changed in transit, the signature breaks and the receiver knows. Unlike SPF, which checks the sending server, DKIM checks the message itself, so it survives forwarding in a way SPF doesn't. ### DMARC: the enforcement policy DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both: quarantine it, reject it outright, or do nothing and just report on it. It also gives you an aggregate report of who's sending email as your domain, including anyone spoofing you. Start with p=none while you confirm your legitimate senders pass, then move to p=quarantine and eventually p=reject once you're confident. ### Why this got stricter in 2024 Google and Yahoo's 2024 bulk-sender requirements made all three effectively mandatory for anyone sending meaningful volume: valid SPF and DKIM, a DMARC policy, and a one-click unsubscribe header even on some transactional mail. Providers that handle this configuration for you (generating the records, verifying propagation, monitoring DMARC reports) save you from finding out the hard way that a typo in a TXT record quietly tanked your delivery rate. ### The two-alignment problem: SPF and DKIM aren't interchangeable A message can pass SPF and fail DKIM, or the reverse, and DMARC only counts a pass if at least one of them is both valid and aligned with the visible From domain. Alignment means the domain that signed (DKIM) or authorized (SPF) the message matches, exactly or by subdomain, the domain your recipient actually sees in their inbox. A message sent through a third-party ESP whose SPF record covers its own sending domain, not yours, will fail SPF alignment even if SPF itself technically passes for the ESP. This is the most common reason a setup that looks correct in isolation still fails DMARC: SPF passes for the sending infrastructure, DKIM passes for the sending infrastructure's own signing domain, but neither aligns with the From address the recipient sees. The fix is making sure your provider signs with a DKIM key under your domain (a CNAME to their key, typically) rather than their own. ### Reading a DMARC aggregate report DMARC's rua tag points receivers at an address (or, more commonly, a report-processing service) where they send daily XML aggregate reports. Raw, these are dense: rows of source IP, message count, and pass/fail status for SPF and DKIM, individually and in alignment. In practice almost nobody reads raw DMARC XML by hand. What matters is watching for two patterns: legitimate sending sources failing (a misconfigured subdomain, a forgotten mail server) and unfamiliar sending sources appearing at all, which is usually either a forwarding service mangling headers or an actual spoofing attempt. Start p=none long enough to see a full reporting cycle (a week is a reasonable minimum, a full month is safer for anything with weekly billing or digest emails) before moving to quarantine. Skipping straight to reject on day one is the most common way teams accidentally block their own legitimate mail. ### What changes if you switch providers Migrating email providers means re-doing all three records for the new provider's infrastructure, and it's worth doing it as an overlap rather than a hard cutover: add the new provider's SPF include and DKIM CNAMEs alongside the old ones, confirm the new provider's messages pass DMARC alignment, then remove the old provider's records only once cutover is confirmed. Running two providers' SPF includes simultaneously is fine, SPF has no penalty for listing multiple authorized senders, as long as you stay under the 10 DNS lookup limit the spec imposes. ## GDPR-compliant transactional email: a developer's guide Source: https://envello.dev/blog/gdpr-compliant-transactional-email-developer-guide Eight decisions that make transactional email GDPR-compliant: lawful basis, message content, processor contract, transfers, retention, tracking, breaches. Most GDPR advice about email is written for marketing teams: consent checkboxes, unsubscribe links, double opt-in. Transactional email (password resets, receipts, magic links, security alerts) works under different rules, and the compliance work sits mostly with the developer who wires up the sending path. This guide walks through the eight decisions that matter, in the order you hit them, and links to a deeper post for each. This is general information for engineers, not legal advice. Your data protection officer or counsel has the final word on your specific processing. ### 1. Lawful basis: you usually don't need consent A password reset or an order confirmation is necessary to perform the contract you have with the user, which is a lawful basis under Article 6(1)(b) GDPR. Security alerts and service notices often sit under legitimate interests, Article 6(1)(f). Neither needs a consent checkbox. The line moves the moment you add promotional content. A receipt with a "you might also like" block is no longer purely transactional, and the marketing rules under the ePrivacy framework start to apply. Keep transactional templates free of promotion, or send marketing as a separate message with its own consent. ### 2. Data minimisation: what goes in the message Article 5(1)(c) says process only what you need. For email that means the subject line and body are the biggest risk: they're stored by every mail server and provider the message passes through, and shown on lock screens. Put the minimum in the email and link to the authenticated app for the rest. - No health, financial or other special-category detail in subject lines. - Link to an invoice in your app rather than attaching one, where you can. - Don't log full message bodies in your own application logs. ### 3. Your provider is a processor: get the DPA Your email API provider processes recipient addresses and message content on your behalf, which makes it a processor under Article 28. Article 28 requires a written contract (the data processing agreement) covering what the provider may do with the data, its security measures, subprocessors, and deletion at the end of the contract. Without a signed DPA, you're out of compliance before the first send. Envello includes a signed DPA on every plan, including Free, with no sales call. Before you sign any provider's data processing agreement, check the subprocessor, deletion and breach-notification clauses. ### 4. Transfers: where the data actually goes Chapter V of the GDPR (Articles 44 to 49) restricts transfers of personal data outside the EEA. An email provider that sends from an EU region but stores logs, account data or support tickets elsewhere is still transferring data, and needs a mechanism such as Standard Contractual Clauses (Article 46). Ask your provider where four things live: the API, the database, the delivery logs and the backups. Envello runs all four in the EU, with sending through AWS SES in Frankfurt. That's what EU data residency means in practice: every copy of the data, not just the sending endpoint. It also has to survive the question of whether the US CLOUD Act reaches a provider's parent company. ### 5. Retention and erasure: delete on a schedule Storage limitation, Article 5(1)(e), means delivery logs shouldn't live forever. Pick a retention window you can justify (long enough to debug delivery problems and answer "I never got the email", short enough to defend) and make sure the provider actually deletes when it expires. Envello's log retention job hard-deletes event and log data past your window: 7 days on Free, 90 on Pro, configurable from 7 to 365 on Scale. That schedule is also how the right to erasure under Article 17 is met in practice for delivery logs. ### 6. Open and click tracking: off unless you need it Tracking pixels and rewritten links collect extra personal data: when someone opened a message, from roughly where, and what they clicked. For a password reset, that data rarely serves a purpose you could defend. Turn tracking on only for messages where you'll actually use it, and document why. On Envello, open and click tracking are off by default and enabled per sending domain. ### 7. Security: what Article 32 means for a sending path Article 32 asks for security appropriate to the risk. For transactional email the practical list is short: - API keys in a secret store, scoped per environment, rotated when someone leaves. - TLS for every hop you control, and SPF, DKIM and DMARC on the sending domain so your mail can't be spoofed. - Webhook signature verification before you act on any webhook. - An audit trail of who created keys and changed domains. ### 8. Breaches and records If personal data leaks, Article 33 gives you 72 hours to notify your supervisory authority once you're aware of it. Your DPA should oblige the provider to tell you without undue delay, so check that clause. Separately, Article 30 requires a record of processing activities; add the email provider and what it processes, and keep its subprocessor list on file. ### A checklist to copy into your ticket | Decision | Done when | | --- | --- | | Lawful basis | Each template is mapped to contract or legitimate interests, with no promotional content | | Minimisation | No special-category data in subjects; bodies link to the app | | DPA | Signed DPA on file for the plan you're actually on | | Transfers | API, database, logs and backups located; transfer mechanism documented if any are outside the EEA | | Retention | Window chosen and justified; provider deletes on schedule | | Tracking | Off, or on per domain with a documented reason | | Security | Keys in a secret store, DMARC published, webhooks verified | | Breaches and records | Breach clause checked; provider in your Article 30 record | ## Why EU data residency matters for transactional email Source: https://envello.dev/blog/eu-data-residency-transactional-email GDPR, NIS2, and the questions your DPO asks before signing off on a US-hosted email provider, and what "EU-hosted" should actually mean. "Where does the data live?" used to be a question only regulated industries asked. In 2026, it's a standard line item in vendor security reviews for any EU SaaS company, thanks to GDPR enforcement patterns, NIS2's expanded scope, and a general tightening of procurement standards across the Mittelstand and startup scene alike. ### What "EU-hosted" should actually mean A lot of providers advertise EU sending while quietly keeping account data, logs, and backups in the US. That distinction matters: sending infrastructure in eu-central-1 doesn't help if the message content and metadata that hit your logs are replicated to us-east-1 for the dashboard to query. The honest version of "EU-hosted" means the API, the database, the object storage for raw MIME, and the backups all sit in EU datacenters, and it means saying so specifically (which region, which provider) rather than a vague "EU-based company" claim that says nothing about where the bytes actually are. ### What your DPO is actually checking - Is there a signed DPA available without a sales call? - Is there a documented, current subprocessor list? - Does data residency hold for logs and backups, not just the sending hop? - Is there a real, human answer to a security questionnaire, not a static PDF from 2022? ### The gap this creates Most category leaders in transactional email were built for the US market first, with EU residency (if offered at all) bolted on as an enterprise add-on behind a sales call. That's a real gap for the large and growing set of EU-based teams who need this from day one, not after they've outgrown the free tier and finally triggered a compliance review. NIS2's expanded scope is its own topic with its own specifics worth getting right, covered separately in "NIS2 and what it actually changes for SaaS email infrastructure" on this blog rather than folded in here as a footnote. ### Data residency versus data transfer: two different questions "Residency" (where data is stored at rest) and "transfer" (whether data crosses a border at all, even temporarily) are related but separate compliance questions, and vendors sometimes answer one while implying they've answered both. A provider can store your database in Frankfurt while still routing support tooling, error monitoring, or analytics through a US-based subprocessor, which reintroduces a transfer question even though the residency claim is technically true. The GDPR-relevant follow-up question is whether that US subprocessor relies on Standard Contractual Clauses, and whether the SCCs actually hold up given the recipient's exposure to US surveillance law, the question the Schrems II ruling put back on every DPO's desk. A current, specific subprocessor list, not a general "we take privacy seriously" statement, is what lets you actually answer that for your own compliance file. ### What actually changes in your architecture Choosing an EU-resident provider doesn't remove the need to think about where your own application sends email metadata. If your app logs recipient addresses to a US-hosted error tracker, or your CRM syncs email engagement events to a US-based analytics tool, the provider's EU residency doesn't cover that path. EU residency at the email API layer is a necessary piece of a compliant sending pipeline, not a substitute for auditing every system downstream that touches the same data. Practically, this means the useful question to ask a provider isn't just "where do you host," but "which systems in your stack touch message content or recipient PII, and where does each of those live." A one-line residency claim on a marketing page rarely answers that; a documented data-flow diagram does. ## Does the US CLOUD Act reach an EU-hosted email provider? Source: https://envello.dev/blog/us-cloud-act-eu-data-residency Data location and corporate jurisdiction are two different questions. Why that distinction matters when a vendor claims EU-hosted. "EU-hosted" gets used to mean two different things, and the difference matters more than it looks like on a pricing page. One meaning: the servers are physically in the EU. The other, stronger meaning: the company operating those servers isn't subject to US legal process that could compel data disclosure regardless of where the servers sit. The US CLOUD Act is specifically why that second meaning matters. ### What the CLOUD Act actually does The US CLOUD Act (2018) clarified that US law enforcement can compel a US company, or a company otherwise subject to US jurisdiction, such as a US subsidiary, to produce data it controls, regardless of where that data is physically stored. A US-headquartered provider running EU data centers doesn't escape US legal process just because the servers are in Frankfurt; the compellable party is the company, not the hardware. ### Why this surprises people evaluating "EU-hosted" vendors The instinct is to treat data center location as the whole answer to "is my data subject to US jurisdiction," because that's the variable most pricing pages and marketing copy actually highlight. Corporate structure, who legally controls the company operating those servers, is a separate and arguably more decisive variable, and it's much less visible on a typical vendor comparison page. A US cloud giant's EU region is still, legally, a US company's infrastructure. ### The practical distinction worth asking about This is genuinely a legal question with real nuance, not something a vendor's blog post should present as settled law, and this isn't legal advice. Two things matter: whether a US parent controls the company, and whether the US has a bilateral data-access agreement with the country where the company is incorporated. Envello is operated by AKTAI LTD, a private limited company registered in England and Wales, with no US parent controlling it. That answers the first question cleanly. The second is worth being specific about rather than glossing over: the US and UK have had a bilateral CLOUD Act Executive Agreement in force since July 2020, giving US and UK law enforcement a faster route to compel data from each other's providers than exists between the US and most other countries, including EU member states, where no equivalent agreement is in place today. So a UK-incorporated provider and a fully EU-incorporated one aren't in an identical legal position on this specific question, even though neither has a US parent. What doesn't change: Envello's data itself is stored on EU infrastructure (AWS SES eu-central-1), a separate question from where the operating company is incorporated, covered above, and any request under the UK-US Agreement still goes through that agreement's own process rather than a unilateral one. ### How this interacts with SCCs and subprocessors Corporate jurisdiction and data transfer mechanisms are related but distinct questions. Standard Contractual Clauses (covered in their own post) govern lawful transfer of data to a subprocessor outside the EEA; they don't change which government can compel the primary vendor itself. Even a fully EU-incorporated company could still use a US-based subprocessor for some narrow function, in which case the SCC question and the corporate-jurisdiction question both apply, to different links in the chain. ### What to actually ask a vendor - Is the entity you're contracting with EU-incorporated, UK-incorporated, or a subsidiary of a US parent? Each sits in a different legal position - "EU-hosted" alone doesn't answer the jurisdiction question, ask specifically about corporate structure and country of incorporation, not just data center location - If the entity is UK-incorporated, ask whether the US-UK CLOUD Act Agreement (in force since 2020) matters for your case, it's a faster channel than exists between the US and most other non-US countries - If any subprocessor in the chain is US-based or US-owned, what transfer mechanism (SCCs, typically) governs that specific relationship - If this matters materially for your compliance posture, get a specific, written answer rather than inferring it from marketing language ## Email API costs that aren't on the pricing page Source: https://envello.dev/blog/hidden-costs-email-api-pricing Overage rates, add-ons, and the questions worth asking before you pick a tier, using Envello's own published numbers as the example. The advertised per-tier price is rarely the whole story for any usage-based API. The costs that actually surprise teams are the ones that only show up once you're past the included volume or need a feature that's gated behind an add-on. Using Envello's own published numbers as a concrete example of what to check, whichever provider you're evaluating: ### Overage rates Envello's Pro tier includes 50,000 to 100,000 emails per month depending on the plan variant, with overages billed at €0.90 per 1,000 emails beyond that. That rate is published on the pricing page, not something you discover on your first invoice after a traffic spike. Check whether a provider you're evaluating publishes its overage rate at all; many don't show it until you're already a customer. ### Add-ons that aren't in the base tier price Dedicated IPs are a real add-on on Envello's Scale tier (€25/month), not bundled into the base price. That's a reasonable and disclosed cost, the kind worth checking for on any provider: does the tier price include everything you'll actually need, or does reaching feature parity require stacking add-ons that change the effective price? ### Questions worth asking before you commit - What's the exact overage rate, and is it published or only visible after signup? - Which features require an add-on rather than being included in the base tier? - Does the retention window scale with the tier, or is long retention itself an upsell? - What happens on a missed payment, immediate suspension or a grace period? ### The volume tiers that don't map cleanly to usage Most providers price in bands: a tier covers up to N emails, and the next tier up covers the next band at a higher base price. The trap is a team that regularly sends 55,000 emails a month landing on a 50,000-email tier and paying overage every single month instead of the next tier up, which might be cheaper overall once the overage rate is factored in. Run the actual math on your typical month, not your lowest month, before picking a tier: overage rates are usually priced as a convenience premium, not a bulk discount. The opposite trap is picking a tier two sizes too large "to be safe" and paying for headroom that never gets used. A published, granular pricing calculator that lets you plug in your actual monthly volume and see the real total, tier price plus expected overage, is worth more than a static pricing table for this exact reason. ### Support tier gating Response-time SLAs and priority support queues are commonly gated by tier, which is a reasonable business model, but it's worth knowing upfront rather than discovering it during an incident. If your production sending depends on a fast answer to a deliverability question, check whether your intended tier includes priority support or whether that's itself a higher-tier feature. A cheap base tier with a 5-business-day support response isn't necessarily cheaper once you count an outage's cost against the support tier you'd actually need to resolve it quickly. ### Migration and export costs A cost that rarely appears on any pricing page: what it costs, in time and in dollars, to leave. Some providers charge for data export, gate historical log access behind a support ticket once you've cancelled, or simply don't offer a documented export path at all. Before committing to a provider, check whether you can export your own send history and suppression list on your own schedule, not just while you're an active paying customer. That's not a line item on the pricing page, but it's a real cost if the answer turns out to be no. ## Gmail and Yahoo bulk sender requirements 2026 Source: https://envello.dev/blog/bulk-sender-requirements-gmail-yahoo-2026 Valid SPF and DKIM, a DMARC policy, a sub-0.3% spam complaint rate, and one-click unsubscribe. What's actually enforced and at what volume. Gmail and Yahoo's 2024 bulk-sender requirements reshaped what's table stakes for anyone sending meaningful email volume, and the rules have held steady since, they're not a one-time hurdle you clear and forget. The threshold that triggers enforcement: roughly 5,000 messages a day to a single provider, though the safest approach is meeting these requirements regardless of your current volume, since growth can cross that line without a deliberate decision to. ### The checklist - Valid SPF and DKIM on your sending domain, aligned with the domain in your From address - A published DMARC policy, at minimum p=none for monitoring, moving toward enforcement over time (see the separate post on the p=none to p=reject migration path) - Spam complaint rate kept under 0.3% as measured in Google Postmaster Tools, sustained, not just on your best day - One-click unsubscribe (the List-Unsubscribe header, RFC 8058 compliant) on any message a recipient could reasonably mark as unwanted, which in practice means most bulk and marketing mail, and arguably some transactional categories too if they're not strictly expected - Messages formatted to actual internet standards, valid MIME formatting isn't optional at this point ### Where transactional email fits Pure, expected transactional mail (a password reset the user just requested) is lower-risk under these rules than bulk marketing, but SPF, DKIM, and DMARC alignment apply regardless of message type. The complaint-rate threshold matters here too: a transactional email a recipient didn't expect, or one that reads as promotional despite being labeled transactional, can generate complaints the same way marketing mail does. ### The 5,000-message threshold in practice The threshold counts messages to a single receiving domain per day, so a product sending 4,000 emails to Gmail addresses and 3,000 to Yahoo addresses in the same day sits under each individual threshold even though total volume is 7,000. That said, the enforcement threshold isn't a hard gate that only matters the day you cross it, both providers apply general deliverability signals below the threshold too; the specific bulk-sender requirements are just guaranteed enforcement above it, not the entire story below it. ### What's actually new to check for in 2026 The core requirements (SPF, DKIM, DMARC, complaint rate, one-click unsubscribe) have been stable since the original 2024 rollout. What's worth periodically re-verifying is your DMARC alignment mode (strict vs. relaxed) and whether your complaint rate has crept upward as your sending volume or recipient list has grown, since a rate that was comfortably under 0.3% at low volume can drift closer to the threshold as volume scales, without any single dramatic change triggering an alert. ### What a provider handling this for you actually saves Generating and monitoring SPF, DKIM, and DMARC records correctly, and catching a slow complaint-rate creep before it crosses 0.3%, is exactly the kind of ongoing maintenance that's easy to set up once and then forget to monitor. A typo in a TXT record or a slowly rising complaint rate that nobody's watching is how deliverability quietly degrades over months, not something that shows up as an obvious outage.