DEV Community: Chitransh Gupta

Email as the Human-in-the-Loop for AI Agents

Chitransh Gupta — Thu, 19 Mar 2026 10:24:26 +0000

In July 2025, a developer told his AI agent eleven times, in ALL CAPS, not to touch production.

The Replit agent wiped months of work, fabricated data to cover its tracks, and when asked to rate its own handling of the situation, gave itself a 95/100 on the data catastrophe scale.

This isn't isolated. Developers across the community are actively asking how to stop agents from going rogue in production.

The answer isn't always better instructions. Sometimes it's a simple checkpoint: ask a human first.

One way to do this: A human-in-the-loop approval system built using email. The agent pauses, sends an approval email, and waits. One tap from your inbox and it knows whether to proceed or not. No new tools. Just your inbox.

The Scenario

There's an agent monitoring support tickets. During one of its runs, it identifies some users hitting the same authentication bug introduced in the last deployment and decides to email all of them with a workaround.

Sounds helpful. But what if the workaround is wrong? What if it emails the wrong users? Without any guardrails, it would just do it.

Instead, it pauses and sends you an approval email with just enough context to make the call:

Action: Send workaround email to 12 affected users

Bug: Authentication failure on login after v2.3.1 deployment

Sample affected users: john@acme.com, sara@corp.io, mike@startup.com

Message that will be sent: "We've identified an issue affecting your account after our recent update. As a temporary workaround, please clear your browser cache and log in again."

You spot-check a name or two, and tap Approve or Reject right from your inbox. Nothing happens until you decide.

Architecture Overview

Here's the full flow:

Agent detects users hitting the same bug
        ↓
Server generates two signed URLs (approve + reject)
        ↓
Resend sends an approval email with context and two buttons to the approver
        ↓
Approver taps Approve or Reject from their inbox
        ↓
Next.js API route verifies the signature and checks expiry
        ↓
Decision is recorded, agent proceeds or stops
        ↓
Confirmation email fires, loop closed

Three moving parts:

The agent → detects the issue and triggers an approval request instead of acting immediately.
The approval email → built with React Email, sent via Resend, contains two buttons backed by signed URLs. This is the only thing the approver ever sees.
The Next.js API routes → generate the signed URLs, send the email, handle the click, and update the agent's state.

Prerequisites

Node.js
A Resend account with a verified domain
A Groq account for a free API key

Setting Up the Project

git clone https://github.com/Calm-Rock/agent-email-approval.git
cd agent-email-approval
npm install

Create a .env.local file in the root by using .env.example as a reference:

RESEND_API_KEY=re_xxxxxxxxx
SECRET_KEY=your_key                # generate with: openssl rand -hex 32
APPROVAL_BASE_URL=http://localhost:3000
APPROVER_EMAIL=you@youremail.com
FROM_EMAIL=agent@yourdomain.com
GROQ_API_KEY=your_groq_api_key_here

RESEND_API_KEY → Your Resend API key.
SECRET_KEY → A random secret string used to sign the approve and reject URLs. This makes sure nobody can forge a click. You can generate one by running openssl rand -hex 32 in your terminal.
APPROVAL_BASE_URL → The base URL of your Next.js server. During development this will be http://localhost:3000. When you deploy, replace this with your actual domain.
APPROVER_EMAIL → The email address that will receive the approval request. It can be your personal Gmail, work email, anything.
FROM_EMAIL → The email address the agent sends from. This must be a verified domain on your Resend account.
GROQ_API_KEY → Your Groq API key for ticket analysis. Get a free key here.

Here's how the project is laid out:

agent-email-approval/
├── emails/
│   └── ApprovalEmail.jsx
├── app/
│   └── api/
│       ├── request-approval/
│       │   └── route.jsx
│       ├── approval/
│       │   └── route.js
│       └── approval-status/
│           └── route.js
├── utils/
│   ├── tokens.js
│   └── store.js
├── agent.js
├── tickets.json
└── .env.local

These are covered in the sections that follow.

The Approval Email

The approval email is built with React Email. It carries just enough context for the approver to make an informed decision: the bug, how many users are affected, a sample of who's impacted, and the exact message that will be sent to them.

The two buttons, Approve and Reject, are backed by signed URLs.

But why buttons? Why not just let the approver reply with 'APPROVE' or 'REJECT'?

One tap and you're done. No typing, no formatting, no opening a reply window.
Reply parsing is fragile and error-prone. Email clients add signatures, quote previous messages, and format text differently.
Replies can be spoofed. A signed URL is cryptographically tied to the action and expires after 24 hours.

The signed URL is the authentication. The approver doesn't need to log in anywhere. Clicking the button is the proof they have the right to decide.

You can find the full React Email template code at emails/ApprovalEmail.jsx.

The Approval Flow

This is where everything connects. When the agent detects an issue, it hits /api/request-approval. That endpoint generates two signed URLs, one to approve and one to reject, and fires off the approval email via Resend.

Signing the URLs

utils/tokens.js handles this. Each URL contains the action ID, the decision, and an expiry timestamp, all signed with HMAC-SHA256 using your SECRET_KEY. Verification uses timingSafeEqual instead of a regular string comparison to prevent timing attacks.

Sending the Email

app/api/request-approval/route.jsx takes the action details, generates the signed URLs, and sends the approval email via Resend.

Handling the Click

app/api/approval/route.js does four things in order: verifies the signature, checks expiry, guards against double clicks, and records the decision. Once recorded, it fires a confirmation email back to the approver and returns a response the approver sees in their browser.

The Agent

The agent is a standalone Node.js script, agent.js, that runs separately from the Next.js server. It communicates with the server entirely over HTTP.

Here's what it does in order:

Loads tickets from tickets.json, a set of sample support tickets used to simulate real incoming requests.
Sends them to Groq for analysis to determine which users are affected, what the bug is, and what workaround message to send
Hits /api/request-approval with the analysis and waits
Polls /api/approval-status every 3 seconds for a decision. The agent has no way of knowing when the approver has clicked, so it keeps checking the server until it gets an answer. In production, you could flip this around and have the server notify the agent directly via a webhook once the decision is recorded.
If approved, sends the workaround email to every affected user via Resend
If rejected, stops

To run it, start the Next.js server first:

npm run dev

Then in a separate terminal run the agent:

node agent.js

NOTE: In Resend's free plan, you are limited to 2 requests per second. The agent already includes a 600ms delay between sends to handle this.

Here's what it looks like when you run it:

Once the agent finishes, you can check your Resend dashboard to see the delivery statuses for each email.

You can find the full agent script at agent.js and the sample tickets at tickets.json.

What This Protects Against

This setup doesn't make your agent smarter. It makes its mistakes catchable before they cause damage. Specifically, three things:

Incomplete reasoning: The agent decided on a workaround, but it doesn't know if it's correct, worded right, or targeting the right users. You do.

Irreversible actions: Emails can't be unsent. A ten second checkpoint is cheaper than a mass email apology.

Forged or replayed clicks: The token is tied to a specific action ID, expires after 24 hours, and can only be used once. A forged click gets rejected.

One limitation worth knowing: this is only as secure as the approver's inbox.

Where to Take It Next

Replace the in-memory store with a database: Decisions reset on every server restart. Swap utils/store.js for a proper database and you get persistence and an audit trail.

Multi-stakeholder approvals: Require two out of three approvers before the agent proceeds.

Timeout handling: Add a timeout so the agent stops or escalates if no decision is made within X hours.

Webhook instead of polling: Have the server notify the agent directly once a decision is recorded, instead of polling every 3 seconds.

Conversational approvals: Resend just launched a Chat SDK that turns email into a two-way channel. The approver could ask follow-up questions before making a final call.

Conclusion

The Replit agent deleted a production database, fabricated data to cover its tracks, and rated its own handling a 95 out of 100 on the catastrophe scale. Not because it was told the wrong thing. Because nothing stopped it from acting before a human could intervene.

That's the gap this fills. Not smarter instructions, not better prompts. Just a checkpoint before the action runs. One email, two buttons, the agent waits for a human to decide.

Email isn't the only way to put a human in the loop. But it's about as universal as it gets.

The full code is available on GitHub.

Email Is Infrastructure. Start Treating It Like One.

Chitransh Gupta — Thu, 19 Mar 2026 10:04:48 +0000

For most people, email is a UI experience. You open Gmail or Yahoo, click Compose, write a subject and body, add a recipient, and hit send.

From an application perspective, email behaves more like infrastructure. Messages pass through external providers, delivery happens asynchronously, and a single send can trigger multiple downstream events.

But if email is infrastructure, can it be made observable like the rest of an application?

Yes. By converting email lifecycle events into telemetry.

This guide shows how to do that. Using Resend webhooks and OpenTelemetry (OTel), email events (sent, delivered, bounced, complained) become traces and metrics visible alongside the rest of your application telemetry.

How It Works

Resend fires a webhook for every email event. A lightweight webhook receiver picks it up and emits a OpenTelemetry span and metric. This guide uses SigNoz as the observability backend, but the same setup should work with any OTLP compatible vendor.

Your App → Resend API
                ↓
         Resend sends email
                ↓
         Email event occurs
         (delivered / bounced / complained)
                ↓
         Resend fires webhook
                ↓
         Webhook receiver (index.js)
         emits spans + metrics
                ↓
         SigNoz / OTel Vendor

Interesting insight 💡

Because this approach stores Resend webhook events as traces and metrics in the observability backend, you get webhook retention as part of your observability data for free. On SigNoz Cloud that is 15 days for traces and 30 days for metrics. On self-hosted SigNoz you can also move older data to cold storage.

Prerequisites

Resend account and API key
Node.js v18+ installed
SigNoz Cloud account (self-hosted works too)
ngrok to expose your local webhook endpoint

The Sample App

The sample app is a Node.js app that simulates a user registration flow, one of the most common transactional email use cases. When a user registers, the app sends a welcome email built with React Email via Resend.

You can find the full code in the GitHub repository. Clone it and install dependencies:

git clone https://github.com/Calm-Rock/resend-email-observability.git
cd resend-email-observability
npm install

The OTel packages required for tracing and metrics are already included in package.json and will be installed automatically.

What OTel packages are installed?

@opentelemetry/api - the core OpenTelemetry API for creating spans and metrics
@opentelemetry/auto-instrumentations-node - automatically instruments HTTP, Express and other libraries without any code changes. This package also pulls in the Node.js SDK and OTLP exporters as dependencies, so you don't need to install them separately.

The sample app (sample-app.js) has three endpoints:

POST /register → sends a welcome email to a real address
POST /register/bounce → triggers a bounce scenario
POST /register/spam → triggers a spam complaint scenario

Copy .env.example to .env

cp .env.example .env

And add your Resend API key (starts with re_) and sender email.

RESEND_API_KEY=your_api_key
SENDER_EMAIL=you@yourdomain.com

yourdomain.com should be a domain you have verified in Resend. If you don’t have a verified domain yet, you can use onboarding@resend.dev as the sender email for testing. However, emails sent from this address can only be delivered to the email address associated with your Resend account.

Run the sample app:

node sample-app.js

This will start the sample app on port 3001.

Send a test email

Send a test email to verify the sample app is working:

curl -X POST http://localhost:3001/register \
  -H "Content-Type: application/json" \
  -d '{"name": "Your Name", "email": "your@email.com"}'

Replace your@email.com with the email address where you want to receive the test welcome email. You will receive the welcome email as shown below.

The Webhook Receiver

The webhook receiver is a single Express app (index.js) that listens for Resend webhook events and converts them into spans and metrics.

When an email is sent through Resend, webhook events are triggered for each state change in the email lifecycle. Each payload contains a type field describing the event, such as email.sent, email.delivered, or email.bounced, and a data object with details about the email. See the full list of event types.

Here is an example email.sent payload:

{
  "created_at": "2026-03-05T20:18:44.871Z",
  "data": {
    "created_at": "2026-03-05T20:18:44.739Z",
    "email_id": "095e18f0-ef44-4327-a083-a2ec5a19a27c",
    "from": "onboarding@resend.dev",
    "subject": "Welcome to Forge — your workspace is ready",
    "to": [
      "test@gmail.com"
    ]
  },
  "type": "email.sent"
}

Setting up the webhook endpoint

The webhook receiver listens for POST requests on /webhook. When a Resend event arrives, it extracts the email details from the payload, creates an OTel span and increments a metric counter.

The complete code for the webhook receiver is in the index.js file in the resend-email-observability repository you cloned earlier.

⚠️ NOTE

For simplicity this example does not verify webhook signatures. In production environments you should verify Resend webhook signatures to ensure requests originate from Resend and prevent spoofed events.

Here is a walkthrough of the key sections:

Parsing the webhook payload

Each incoming webhook request is parsed to extract the event type and relevant email details.

const event = req.body;
const eventType = event.type;
const data = event.data;
const emailId = data?.email_id;
const toEmail = data?.to?.[0] ?? "unknown";
const domain = extractDomain(toEmail);
const bounceType = data?.bounce?.type ?? null;
const bounceSubType = data?.bounce?.subType ?? null;

eventType is the event name like email.bounced. bounceType and bounceSubType are only present in bounce events and contain values like Permanent or Transient.

Initializing the tracer and meter

const tracer = trace.getTracer("resend-webhook-receiver");
const meter = metrics.getMeter("resend-webhook-receiver");

const emailEventCounter = meter.createCounter("email.events", {
  description: "Count of Resend email events by type",
});

This sets up the OTel tracer for creating spans and a counter metric that will track email events by type.

Traces let you debug individual emails, while metrics power aggregate dashboards. The webhook receiver emits both for every event.

Creating a span for each email event

const span = tracer.startSpan(`resend.${eventType}`);

const attributes = {
  "email.event_type": eventType,
  "email.id": emailId,
  "email.to": toEmail,
  "email.domain": domain,
  "email.from": data?.from ?? "unknown",
  "email.subject": data?.subject ?? "unknown",
  "email.timestamp": data?.created_at ?? "unknown",
};

if (bounceType) attributes["email.bounce_type"] = bounceType;
if (bounceSubType) attributes["email.bounce_subtype"] = bounceSubType;

span.setAttributes(attributes);

Each webhook event becomes a span with a name like resend.email.bounced. Email details are attached as attributes such as email.id, email.to, email.domain, email.subject, along with event specific attributes like email.bounce_type for bounce events.

Incrementing the metric counter

const metricAttributes = {
  "email.event_type": eventType,
  "email.domain": domain,
};
if (bounceType) metricAttributes["email.bounce_type"] = bounceType;

emailEventCounter.add(1, metricAttributes);

span.setStatus({ code: SpanStatusCode.OK });
span.end();

res.status(200).json({ received: true });

Every event increments the email.events counter tagged with the event type and recipient domain as dimensions. Bounce events also include email.bounce_type as a metric attribute, so you can track hard and soft bounces separately on your dashboard. After the metric is recorded, span.setStatus marks the span as successful and span.end() closes it. This is important because spans are only exported after they complete.

Returning a 200 response is important because Resend uses it to confirm the webhook was received. If your endpoint returns a non-2xx status, Resend will retry delivery.

Exposing webhook receiver with ngrok

Resend needs a public URL to deliver webhook events to. During local development, you can expose your server using ngrok:

ngrok http 3000

The webhook receiver runs on port 3000 . The ngrok command above exposes it as a public HTTPS URL that Resend can deliver webhooks to.

Copy the HTTPS forwarding URL from the ngrok output:

Forwarding  https://your-id.ngrok-free.app -> http://localhost:3000

https://your-id.ngrok-free.app is your forwarding URL. Append /webhook to it:

https://your-id.ngrok-free.app/webhook

Make sure the endpoint URL ends with /webhook, since that is the route the receiver listens on.

This is the URL you will add to Resend in the next step.

Configuring Resend webhooks

Go to the Resend Webhooks dashboard and click Add Webhook. Paste your ngrok webhook URL (with /webhook) and select All Events so your endpoint receives every webhook event.

Running the Webhook Receiver

Start the webhook receiver with OpenTelemetry configured to export to SigNoz. Run the below commands in the root folder:

export OTEL_TRACES_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=<your-ingestion-endpoint>:443
export OTEL_EXPORTER_OTLP_HEADERS="signoz-ingestion-key=<your-ingestion-key>"
export OTEL_EXPORTER_OTLP_TIMEOUT=5000
export OTEL_NODE_RESOURCE_DETECTORS=env,host,os
export OTEL_SERVICE_NAME=resend-email-observability
export NODE_OPTIONS="--require @opentelemetry/auto-instrumentations-node/register" 
node index.js

Click to know details about the OTEL environment variables

These environment variables configure the OTel SDK without any code changes. OTEL_EXPORTER_OTLP_ENDPOINT tells the SDK where to send data, OTEL_SERVICE_NAME is how your service will appear in SigNoz, and NODE_OPTIONS loads the auto-instrumentation library which automatically captures HTTP spans alongside your custom email spans.

Detailed explanation about the OTel environment variables can be found in the OpenTelemetry docs for SDK configuration and OTLP exporter configuration.

Replace <your-ingestion-key> with your SigNoz ingestion key and <your-ingestion-endpoint> with your SigNoz ingestion endpoint, For example, https://ingest.us.signoz.cloud .

Note: For Self-Hosted version of SigNoz, update the endpoint and remove the ingestion key header as shown here.

In a separate terminal, start the sample application by running this command in the root folder:

node sample-app.js

Triggering email events

The sample application has three endpoints, each simulating a different email delivery outcome.

/register → triggers email.sent and email.delivered events
/register/bounce → triggers email.sent and email.bounced events
/register/spam → triggers email.sent and email.complained events

Trigger all three scenarios:

curl -X POST http://localhost:3001/register \
  -H "Content-Type: application/json" \
  -d '{"name": "Test User", "email": "your@email.com"}'

curl -X POST http://localhost:3001/register/bounce \
  -H "Content-Type: application/json" \
  -d '{"name": "Test User"}'

curl -X POST http://localhost:3001/register/spam \
  -H "Content-Type: application/json" \
  -d '{"name": "Test User"}'

Replace your@email.com with your own email address in the first command.

You should see webhook events arriving in your terminal:

These events are now being converted into OTel spans and metrics. Let's see them in SigNoz.

Viewing Traces in SigNoz

Head over to SigNoz and click on Traces. Filter by service.name = resend-email-observability and you should see a trace for the different webhook events.

Click on any trace to see the full span details. Here is what a resend.email.bounced span looks like:

The trace shows a POST /webhook request flowing through the JSON parser middleware into the webhook handler, which creates the resend.email.bounced child span with all email attributes attached.

Every email attribute attached in index.js is visible here — email.id, email.to, email.domain, email.bounce_type and more. This means you can:

Filter traces by email.bounce_type = Permanent to find all hard bounces
Filter by email.domain to see which domains are causing issues
Filter by email.id to trace the full lifecycle of a single email across multiple events

Custom Dashboard

Traces help you debug individual emails. A dashboard shows the aggregate picture.

A ready-to-import SigNoz dashboard JSON is available here. Import it from Dashboards → New Dashboard → Import JSON.

The dashboard includes panels for email event volume over time, distribution by event type, bounce type breakdown, events by recipient domain, and HTTP endpoint latency and status codes from auto-instrumentation.

Each panel includes a description. Hover over the ⓘ icon in your Dashboard to read it.

Here is what the dashboard looks like:

One thing worth highlighting is that SigNoz dashboards are interactive. Clicking any data point in a panel lets you jump directly to the related traces, so you can move from aggregate metrics to individual email spans in a single click.

Troubleshooting

If events are not appearing as expected, use this table to diagnose the issue.

Symptom	Likely Cause	Fix
No data in SigNoz, no errors in terminal	Wrong ingestion endpoint or key	Double-check both values against your SigNoz ingestion settings
Webhook events log in terminal but no traces in SigNoz	Incorrect `OTEL_SERVICE_NAME` or endpoint	Verify all `export` commands ran in the same terminal session before `node index.js`
Events worked before, now nothing arrives	ngrok URL changed after a session restart	Update the webhook URL in the Resend Webhooks dashboard
Email sends but no webhook event logged in terminal	Resend webhook not configured or pointed at wrong URL	Check the Resend Webhooks dashboard for delivery attempts and errors
`email.delivered` never arrives	Delivery confirmation can take several minutes	Wait for some time, or check Resend logs for delivery status
`email.bounced` or `email.complained` not triggering	Test endpoints use hardcoded Resend test addresses	Use `/register/bounce` and `/register/spam` as-is — no email field needed

Going Further

Alerting on bounce spikes

SigNoz lets you set up alerts on any metric. A useful one is alerting when the bounce rate crosses a threshold.

For example, if email.bounced events exceed a set threshold in a 5 minute window, you can configure this from Alerts → New Alert → Metrics Alert in SigNoz using the email.events metric filtered by email.event_type = 'email.bounced'.

Using the Docker image

If you'd rather not install Node.js, you can run the webhook receiver as a Docker container using a pre-built Docker image . A Dockerfile is also included in the repository if you want to customize it.

Run the pre-built image:

docker run -p 3000:3000 \
  -e OTEL_EXPORTER_OTLP_ENDPOINT=<your-ingestion-endpoint>:443 \
  -e OTEL_EXPORTER_OTLP_HEADERS="signoz-ingestion-key=<your-ingestion-key>" \
  -e OTEL_EXPORTER_OTLP_TIMEOUT=5000 \
  -e OTEL_SERVICE_NAME=resend-email-observability \
  chitranshgupta/resend-webhook-receiver

Replace <your-ingestion-key> with your SigNoz ingestion key , <your-ingestion-endpoint> with your SigNoz ingestion endpoint. For example, https://ingest.us.signoz.cloud .

Conclusion

Most teams find out about email delivery problems when users complain. With Resend webhooks and OpenTelemetry, you find out the moment it happens in the same place you already watch the rest of your stack.

The macOS Terminal Email Setup Nobody Talks About

Chitransh Gupta — Tue, 03 Mar 2026 23:29:31 +0000

A while ago, while watching a video about "How Email Works?" I got to know about UNIX mail and how you can send email from your terminal to anyone with a single command. I set it up with Gmail, went through 2FA, App Passwords, and a handful of extra steps, and finally got to excitedly send a test email to a friend.

Getting there was some work, and I wanted one thing: my own domain in that sender address instead of @gmail.com.

While looking around, I remembered Resend where I had set up my domain and it had been refreshingly simple. A quick check confirmed they have their own SMTP service that uses an API key to send emails from your verified domain. Perfect!

This guide will show you how to set up your macOS terminal to send emails using Resend. Once it's configured, you can send a quick note from a script, get updates from a long-running build, or have an AI agent ping you when a task completes, all without leaving your shell.

Prerequisites

Prefer a one-command setup? Run the setup script directly. It handles everything interactively and sends a test email at the end. Otherwise, follow the guide below to understand exactly what is happening under the hood.

Download the script, unzip it, and run:
chmod +x resend-macos-setup.sh && ./resend-macos-setup.sh

Setup

macOS comes pre-built with Postfix, the default Mail Transfer Agent (MTA) which works on-demand. Whenever you send an email from your terminal, it is put in a local queue and Postfix tries to authenticate with your SMTP server. Once the authentication is successful, it relays the message from the queue to Resend, which then handles delivery to the destination.

Let's configure Postfix to send messages to your Resend SMTP server.

Step 1: Configure Postfix as a Relay Host

A relayhost is an intermediate mail server that receives your local emails and relays them to their destination. In this case, you will be using Resend as your SMTP provider.

Run the following command in your terminal:

sudo nano /etc/postfix/main.cf

This will open the Postfix config file. Scroll to the bottom of the file and add the following lines to point Postfix to Resend's SMTP server:

mydestination =
relayhost = [smtp.resend.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_sasl_mechanism_filter = login
smtp_generic_maps = hash:/etc/postfix/generic
local_transport = error:local delivery disabled

🔧 View Configuration Details

Setting	Purpose
`relayhost`	Sends all mail through Resend's SMTP server
`smtp_sasl_auth_enable`	Enables authentication
`smtp_sasl_password_maps`	Points to the file with your Resend API key
`smtp_sasl_mechanism_filter = login`	Ensures Postfix uses the LOGIN handshake required by Resend
`smtp_tls_security_level = encrypt`	Mandates encryption to protect your API key during transit
`smtp_generic_maps`	Maps your local Mac username (eg., `cheeto@MacBook.local`) to a verified domain email
`local_transport = error: ...`	Prevents Postfix from trying local delivery
`mydestination =` (empty)	Forces Postfix to treat every email as external and send it to relay

By default, your Mac tries to send mail as localuser@hostname.local, which modern servers like Resend will block. So, we use generic maps to rewrite that local address to your verified domain. The local_transport and mydestination settings act as a one-way street sign. Without them, Postfix would try to deliver your email locally to your Mac, silently succeeding at "delivery" while your message goes nowhere. These two settings together tell Postfix that every message is outbound.

Step 2: Secure Your Authentication Credentials

To allow Postfix to log in to Resend, you need to create a credential file and compile it into a format the system can read quickly. Run the following commands in your terminal:

sudo bash -c 'echo "[smtp.resend.com]:587 resend:YOUR_RESEND_API_KEY" > /etc/postfix/sasl_passwd'

sudo chmod 600 /etc/postfix/sasl_passwd

sudo postmap /etc/postfix/sasl_passwd

sudo chmod 600 /etc/postfix/sasl_passwd.db

Replace YOUR_RESEND_API_KEY with the full key from your Resend dashboard (it usually starts with re_).

⚠️ Do this now — Clear your shell history

The command above writes your API key inline, which means it will be saved to your shell's history file (.zsh_history or .bash_history). After running it, clear the entry:

# zsh
fc -p

# bash
history -d $(history 1)

postmap compiles your credentials into a fast lookup database that Postfix can read. The chmod 600 step is not optional. Without it, your API key sits in a plain-text file readable by any process on your machine.

Step 3: Map Your Local User to a Verified Domain

By default, your Mac tries to send mail from username@hostname. Resend will reject this non-verified address, so you must use a generic map to rewrite your local identity to your real, verified email address. Run the following commands in your terminal:

sudo bash -c 'echo "$(whoami)@$(hostname) SENDER@YOURDOMAIN.COM" > /etc/postfix/generic'

sudo postmap /etc/postfix/generic

Replace SENDER@YOURDOMAIN.COMwith your verified Resend email. For example, cheeto@cheeto.dev

🛠️ Having issues? Verify your hostname

Postfix uses its own internal $myhostname to match addresses against the generic map. If it differs from what $(hostname) returns in your shell, the map never fires, Resend rejects the address, the queue empties, and nothing is delivered with zero error messages.

Run this to check:

postconf myhostname

The output should match $(whoami)@$(hostname) exactly. If it doesn't, replace the $(hostname) part of the command above with the exact output of postconf myhostname and re-run it.

This creates a mapping file to replace your Mac's local identity ($(whoami)@$(hostname)) with your verified domain. Running postmap then compiles this into a .db binary that Postfix can actually read and query.

Step 4: Start/Reload Postfix

Postfix on macOS is "on-demand," meaning it doesn't run as a persistent background service. It spins up when needed. Run this to start it and load your new configuration in one go:

sudo postfix start; sudo postfix reload

If Postfix was already running, the start command will say so. That is not an error, just ignore it. The reload is what picks up your config changes.

Testing your Configuration

Send a test email with the command below:

echo "Hello from my Mac Terminal via Resend" | mail -s "Postfix Test with Resend" recipient@example.com

Replace recipient@example.com with the actual email address where you want to receive the message.

Confirming Success

Run this to check the local queue:

mailq

If it returns Mail queue is empty, Postfix has handed the message off. That does not mean it was delivered yet. Head to the Emails section of your Resend Dashboard to confirm the actual delivery status.

🛠️ Having issues?

Open a second terminal tab and run:

sudo tail -f /var/log/mail.log

This gives you a live view of exactly what Postfix is doing when you send. If something is failing, the error will show up here in real time.

Alternative: A Faster Setup

If Postfix feels like overkill, msmtp is a lightweight, relay-only client that is much easier to configure. It doesn't run in the background and simply sends your mail directly to Resend when you call it.

Installation

brew install msmtp

Create and Configure the `.msmtprc` File

nano ~/.msmtprc #No sudo needed

Paste the following into the file:

defaults
auth           on
tls            on          # STARTTLS on port 587 for encrypted connection
tls_starttls   on
logfile        ~/.msmtp.log

account resend
host smtp.resend.com
port 587
from SENDER@YOURDOMAIN.COM
user resend
password YOUR_RESEND_API_KEY

account default : resend

Replace YOUR_RESEND_API_KEY with the full key from your Resend dashboard and SENDER@YOURDOMAIN.COM with your verified Resend email.

Secure Permissions

This file contains your plain-text API key. You must lock it down to owner-only access or msmtp will refuse to run for security reasons:

chmod 600 ~/.msmtprc

Send a Test Email

Verify that your setup is working properly by sending a test email using the command below:

printf "Subject: msmtp Test via Resend\nTo: recipient@example.com\n\nHello from msmtp via Resend." | msmtp recipient@example.com

Replace recipient@example.com with the actual email address where you want to receive the message.

Unlike Postfix, msmtp gives you instant feedback directly in your terminal. If the connection to Resend fails, you will know immediately.

Real-World Use: AI Agent Notifications

If you're running Claude Code, Codex, or any local agent loop, you can now give your agent the ability to send email with a single shell command:

echo "Task complete: dependency audit finished. 3 issues found." | \
  mail -s "Agent Report: $(date)" SENDER@YOURDOMAIN.COM

Add this as a final step in any agent workflow. No Slack bot, no webhook, no extra API to set up. Just your terminal, talking back to you.

DEV Community: Chitransh Gupta

Email as the Human-in-the-Loop for AI Agents

The Scenario

Architecture Overview

Prerequisites

Setting Up the Project

The Approval Email

The Approval Flow

Signing the URLs

Sending the Email

Handling the Click

The Agent

What This Protects Against

Where to Take It Next

Conclusion

Email Is Infrastructure. Start Treating It Like One.

How It Works

Prerequisites

The Sample App

The Webhook Receiver

Setting up the webhook endpoint

Exposing webhook receiver with ngrok

Configuring Resend webhooks

Running the Webhook Receiver

Triggering email events

Viewing Traces in SigNoz

Custom Dashboard

Troubleshooting

Going Further

Alerting on bounce spikes

Using the Docker image

Conclusion

The macOS Terminal Email Setup Nobody Talks About

Prerequisites

Setup

Step 1: Configure Postfix as a Relay Host

Step 2: Secure Your Authentication Credentials

Step 3: Map Your Local User to a Verified Domain

Step 4: Start/Reload Postfix

Testing your Configuration

Confirming Success

Alternative: A Faster Setup

Installation

Create and Configure the .msmtprc File

Secure Permissions

Send a Test Email

Real-World Use: AI Agent Notifications

Create and Configure the `.msmtprc` File