DEV Community: SendFleet

Amazon SES without the AWS homework: how SendFleet runs your email in your own account

SendFleet — Wed, 28 Oct 2026 06:11:56 +0000

Amazon SES is cheap, fast and reliable, and your sending reputation is your own. Most teams that choose it then spend days on everything around sending. This post walks through that work, and how SendFleet automates it inside the customer's own AWS account.

1. Getting access without holding keys

SendFleet never stores AWS keys. The customer launches a CloudFormation template that creates one IAM role, SendFleet-BYOC-Role. Its trust policy allows exactly two SendFleet roles, and only with an ExternalId generated for that customer:

"Condition": {
  "StringEquals": { "sts:ExternalId": "<your ExternalId>" },
  "ArnEquals": { "aws:PrincipalArn": [
    "arn:aws:iam::<sendfleet>:role/SendFleetByocRelay",
    "arn:aws:iam::<sendfleet>:role/SendFleetByocControl"
  ]}
}

The ExternalId prevents the confused-deputy problem. The PrincipalArn condition means even SendFleet's own web servers cannot assume the role. All management calls go through one control
Lambda in an isolated AWS account.

2. The region problem

SES production access is granted per region. An account can be live in Ireland and sandboxed in Singapore. SendFleet reads SES in every supported region with one role session, in parallel, and picks the region with production access and the biggest quota. If there is none, it prefers a region where AWS is already reviewing a request. Choosing a region by hand stays available, for data residency.

3. Tracking that heals itself, but never fights you

SendFleet creates a configuration set (sendfleet-tracking) and an SNS topic (sendfleet-events) in the customer's account, and subscribes its own queue to the topic. Fixed names make every step idempotent: a repair re-creates the same set, so messages already queued with that name still work.

A daily sweep checks the set, topic and subscription. If something drifted, it repairs it, unless:

the customer turned automatic repair off: it only reports the drift;
the same resources were removed again within 24 hours of a repair: it assumes the customer meant it, stops, and asks.

Every write to the configuration row is fenced on a generation counter, so a stale worker can never overwrite a newer decision.

4. Paying only for the events you need

SNS bills the customer per published event. Bounces, complaints and rejections are always published: protection depends on them, and they are rare. Deliveries, which are about one event per recipient, are optional.

"Sent" is never published at all. The relay already knows when SES accepted a message, so it reports that itself, signed with a secret only SendFleet holds.

5. Protection before AWS steps in

AWS reviews accounts at a 5% bounce rate or 0.1% complaint rate. SendFleet evaluates the customer's own traffic over 24 hours and 7 days against a profile they choose. It warns first, then pauses sending with a clear API error until the customer reviews and resumes. Addresses skipped by SES Auto Validation are counted as suppressed, not bounced, matching how AWS measures it.

6. Logs without content

With email logs on, each send appears in the log as "Queued" the moment the API accepts it, moves to sent, delivered or bounced as events arrive, and turns "Failed" with a plain reason if it never reaches SES. Bodies are never stored, and subjects can be switched off.

Try it

SendFleet is free for 3,000 emails a month and $5 a month after that, with 20,000 emails included emails included, then $0.10 per 1,000.
You pay AWS for SES directly.

https://sendfleet.net · Docs: https://docs.sendfleet.net/byoc

I would love feedback, especially from anyone running SES at scale.

SendFleet now has a WordPress plugin. Try it and tell me what breaks

SendFleet — Tue, 20 Oct 2026 17:17:11 +0000

SendFleet now has a plugin on WordPress.org.

SendFleet is a transactional email API. The plugin connects it to WordPress, so the emails your site sends (WooCommerce orders, contact forms, password resets) go through SendFleet instead of PHP mail(). You can use your own AWS SES account or SendFleet's.

Try it

Install the plugin: https://wordpress.org/plugins/sendfleet
Create a free SendFleet account and copy your API key
Paste the key in the plugin settings
Send a test email

On the free plan, test emails only go to your own address. Sending to other people needs the paid plan or your own SES account.

What I need from you

This is the first version, so I want to hear what breaks. A confusing setup step, a bug, a missing feature, anything. Write it in the comments and I will read every one.

If you don't run WordPress, you can still help. If you know someone who does, send them the link.

DNS records every developer sending email must understand (SPF, DKIM, DMARC explained)

SendFleet — Wed, 20 May 2026 12:02:37 +0000

Adding DNS records to send email is one of those tasks where most developers do exactly what the dashboard tells them without understanding why. That works until it doesn't — and when deliverability breaks, debugging without understanding the underlying mechanisms is genuinely painful.

This post covers the five DNS record types involved in email authentication, what each one actually does, which ones are required, and how to verify your setup is correct.

Why email authentication exists

Email was designed in an era of trust. The original protocols have no mechanism for verifying that the server claiming to send mail from acme.com actually has permission to do so. Anyone can configure a mail server to say it is sending from your domain. This is why spam and phishing exist at industrial scale.

SPF, DKIM, and DMARC are the three authentication layers built on top of the original protocols to address this. Mailbox providers at Google, Microsoft, Apple, and others evaluate all three when deciding whether to deliver your mail, send it to spam, or reject it outright.

SPF: who is allowed to send for your domain

SPF (Sender Policy Framework) is a TXT record on your root domain that lists the IP addresses and services authorized to send email on your behalf. A receiving mail server checks this record when it receives a message claiming to be from your domain.

A minimal SPF record looks like this:

v=spf1 include:amazonses.com ~all

This says: servers listed in Amazon SES's SPF record are authorized to send for this domain. The ~all at the end is a soft fail — messages from unauthorized servers are flagged but not rejected. -all is a hard fail — reject them. ~all is the recommended starting point.

The include: mechanism is how you authorize third-party senders. Every service you send email through needs to be listed. If you use multiple services, you chain them: v=spf1 include:amazonses.com include:sendgrid.net ~all.

SPF has a 10-lookup limit. If your include chain requires more than 10 DNS lookups to resolve, SPF evaluation fails. This is a real problem for organizations using many email services simultaneously.

DKIM: cryptographic signing for your messages

DKIM (DomainKeys Identified Mail) lets the sending server cryptographically sign outgoing messages. The receiving server retrieves your public key from DNS, verifies the signature, and confirms the message was not modified in transit.

The DNS record is a CNAME or TXT record published at a selector subdomain. SES uses three CNAME records, each pointing to SES-managed keys:

selector1._domainkey.acme.com → selector1._domainkey.REGION.dkim.amazonses.com selector2._domainkey.acme.com → selector2._domainkey.REGION.dkim.amazonses.com selector3._domainkey.acme.com → selector3._domainkey.REGION.dkim.amazonses.com
All three must be present and resolving correctly. The private key lives in SES; you publish only the public key via CNAME. Key rotation is handled automatically by SES when you use the CNAME delegation approach — no manual intervention required.

DKIM is the most important of the three from a deliverability perspective. Gmail, for example, heavily weights DKIM alignment when scoring inbound mail. It is also the only record required by SendFleet before you can send — without DKIM, your domain identity is not fully verified.

DMARC: policy and reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and adds two things: a policy telling receivers what to do with mail that fails authentication, and a reporting mechanism that sends you data about what is happening to your email.

The record lives at _dmarc.yourdomain.com and looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@acme.com

The p= field is the policy:

p=none: do nothing, just send reports. This is monitoring mode - the right place to start.
p=quarantine: send failing mail to spam
p=reject: reject failing mail entirely

Start with p=none and review the aggregate reports (rua) for at least a few weeks before moving to quarantine. The reports show you every source sending mail claiming to be from your domain — including misconfigured legitimate senders you might not know about.

MAIL FROM subdomain: proper bounce routing

The MAIL FROM subdomain (also called the envelope from or return path) is a subdomain you configure — typically send.yourdomain.com — that SES uses as the bounce address for your emails.

Two records are required:

An MX record on the subdomain pointing to SES's feedback servers:
send.acme.com MX 10 feedback-smtp.us-east-1.amazonses.com.

And a separate SPF TXT record on the subdomain:
send.acme.com TXT "v=spf1 include:amazonses.com ~all"

Without a custom MAIL FROM, SES uses its own domain as the return path, which can cause SPF alignment failures under DMARC. With a custom MAIL FROM on your subdomain, the return path is under your domain and SPF alignment passes.

Domain ownership TXT record

This is the simplest of the five: a TXT record on your root domain that proves to SES (and through it, to SendFleet) that you control the domain. It looks like this:

_amazonses.acme.com TXT "some-verification-token"

This must be verified before any other verification can proceed.

What is required versus what is recommended

Required to send with SendFleet: domain ownership TXT and all three DKIM CNAMEs.

Strongly recommended: SPF, MAIL FROM subdomain, DMARC in p=none mode.

Without SPF and MAIL FROM, some mailbox providers will mark your mail as suspicious. Without DMARC, you have no visibility into authentication failures and cannot protect your domain from spoofing at the policy level.

SendFleet's domain dashboard shows per-record verification status with individual verify buttons. Use these to confirm propagation - the dashboard checks DNS directly.

Quickstart BYOC - SendFleet

SendFleet — Thu, 14 May 2026 05:48:04 +0000

For the BYOC path you need:
→ An AWS account with SES approved for
production access
(out of sandbox mode)
→ A domain you control (to add DNS records)
→ Access to create IAM roles in your AWS account

Create a SendFleet account
Register at sendfleet.net/register. Email verification is required before you can send. The Starter plan is free with 50 BYOC emails/month - no credit card needed.
Create an IAM role in AWS
In your AWS console, go to IAM → Roles → Create role. Choose Custom trust policy and paste the trust policy shown in your account settings → BYOC section. It will include your unique ExternalId automatically. Attach the required SES permissions (also listed in settings). See the full guide in BYOC Setup →
Connect your IAM role
Go to Dashboard → Settings. Paste your IAM Role ARN and select your SES region. Click Validate & save. We'll verify that we can assume the role and that your SES account is out of sandbox mode.
Example Role ARN
arn:aws:iam::123456789012:role/SendFleet-BYOC-Role
Add and verify a sending domain
Go to Dashboard → Domains → Add BYOC domain. Enter your root domain (e.g. acme.com). We'll register the identity in your SES and show you the DNS records to add. Once the TXT ownership record propagates, click Verify ownership - then Verify DKIM. DKIM verification is required before any email can be sent.
Generate an API key
Go to Dashboard → API Keys → New key. Give it a name (e.g. "Production"). The full secret key is shown exactly once - copy it and store it in your environment variables or secrets manager.
Send your first email

curl -X POST https://sendfleet.net/api/send/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"to": "user@example.com",
"from_email": "hello@acme.com",
"from_name": "Acme",
"subject": "Welcome aboard",
"message": "Thanks for signing up!"
}'

A 200 OK means your email has been accepted and queued. Delivery happens asynchronously.

200 OK
{
"success": true,
"message": "Email queued for delivery via your SES account.",
"message_id": "1a2b3c4d-5e6f-7890-abcd-ef1234567890",
"mode": "byoc"
}