SMTP relay

An SMTP relay accepts your message over SMTP and delivers it to the recipient's mail server for you. Your application hands over the message; the relay does the DNS lookups, the outbound connections, the retries, and the reputation work that decides whether the message lands in an inbox.

Sendfeather is one. Point any SMTP client at smtp.sendfeather.com — the free plan includes 1,000 emails a month — and every message is signed with your own domain's DKIM key and tracked from accepted to delivered, the same timeline API sends get.

Why send through a relay at all

Sending directly means your server connects to the recipient's mail server on port 25, the way a mail server does. Most cloud and hosting providers block outbound port 25 by default, and a new IP address has no sending history, so mailbox providers have nothing to judge it by. Deliverability is a reputation game, and reputation takes weeks of careful volume to build.

• Port 25 is blocked on most cloud hosts; getting it opened takes a support ticket, and some providers never open it.
• A new IP has to be warmed: low volume first, bounces watched, for weeks.
• Every bounce and complaint lands in your logs, and the cleanup is yours.
• One misbehaving script can put the IP on a blocklist — and then it is not only that script's mail that stops arriving.

What to check in a relay service

Relays differ in what they keep for you. The questions worth asking before you pick one:

• Do your DKIM keys stay yours? If the relay signs with its own domain on your behalf, its reputation is on the line — and the control of it is not yours.
• Is there a delivery timeline? Accepted is not delivered. You want per-message events: delivered, opened, bounced, complained.
• What happens at the rate limit? A relay that drops or refuses mail at the cap loses messages; a temporary error lets a well-behaved client retry.
• Where do bounces go? Suppressing addresses that keep failing is the difference between a relay and a pipe.
• Can it send as your domain? Your From address is what keeps replies coming back to you, and your DKIM key is what makes the sending reputation yours.

Relay, your own mail server, or an HTTP API?

All three move the same message. The choice is about what already exists on your side.

Sending through Sendfeather

1. 1

   Verify your domain

   DKIM signing uses a key generated for your domain. Verification takes minutes, and new sending domains get a quick human review before the first send.

2. 2

   Create an SMTP user

   Open SMTP → Add SMTP user. The password is shown once, so copy it into your client right away.

3. 3

   Point the client at the relay

   Host smtp.sendfeather.com, port 2525 or 587 with STARTTLS, or 465 with TLS. 2525 exists for networks that block 587.

Messages over an SMTP user's hourly limit are refused with a temporary error, so clients retry instead of dropping mail. Every message appears in Activity with the same timeline as API sends.

When you do not need a relay

If you send a handful of messages a day from a real person's address, your mailbox provider's own SMTP server is fine — it is already trusted for that domain. A relay earns its keep when the volume is application-driven, the mail is transactional, and nobody on the team wants to read bounce logs for a living.