Getting Started with Resend: Domain Setup, API Keys, and Sending from n8n

The intro covered what Resend is and why it exists. This guide is about getting it working — from a blank account to sending real emails from an n8n workflow. We’ll go in order: account, domain verification, API key, testing the API directly, then connecting it to n8n and building a real workflow.

Don’t skip the domain verification step. I know it looks like the boring part. It’s actually the most important part. Everything else in this guide depends on it working correctly.

---

Creating Your Resend Account

Go to resend.com and sign up. The process is quick — email, password, done. You don’t need a credit card to start. The free tier covers everything you need while you’re building and testing.

Once you’re in, take 60 seconds to orient yourself in the dashboard. The main sections you’ll use:

• API Keys — Where you generate and manage the keys your automations use to authenticate with Resend
• Domains — Where you add and verify the sending domains for your emails
• Emails — A log of every email you’ve sent, with delivery status and event history for each one
• Audiences — Resend’s contact list feature (not relevant for pure automation use cases, but worth knowing it’s there)

The Emails section is where you’ll spend time debugging. When something doesn’t arrive, that’s the first place to look.

---

Adding and Verifying Your Domain

This is the step that most people want to rush past. Don’t. Until your domain is verified, your emails will either land in spam or not arrive at all. This is not a Resend limitation — it’s how email works.

Step 1: Add your domain in Resend

Go to Domains → Add Domain. Enter the domain you’ll be sending email from. If your website is yourcompany.com and you want to send from jobs@yourcompany.com, enter yourcompany.com.

Step 2: Copy the DNS records Resend provides

Resend will give you three or four DNS records to add to your domain. These are the records that authenticate your emails:

• SPF record (TXT type) — Tells receiving mail servers that Resend is authorized to send on behalf of your domain. Without this, servers can’t verify your emails are legitimate and will treat them as suspicious.
• DKIM record (TXT or CNAME type) — Adds a cryptographic signature to every email. The receiving server checks this signature against your DNS to confirm the message wasn’t altered in transit.
• DMARC record (TXT type) — Tells receiving servers what to do if SPF or DKIM checks fail (reject it, quarantine it, or do nothing). Also enables you to receive reports about authentication failures on your domain.

Step 3: Add the records in your DNS provider

Where you add these depends on who manages your domain’s DNS. Common providers:

• Cloudflare — DNS → Add Record → paste the name, type, and value Resend gives you
• Namecheap — Advanced DNS → Add New Record
• GoDaddy — DNS Management → Add record

The record names and values are shown exactly in Resend’s dashboard. Copy them precisely — a single character error will cause verification to fail.

Step 4: Wait for verification

DNS propagation can take anywhere from a few minutes to 48 hours, though it’s usually under an hour. Resend’s Domains page shows the verification status for each record. When all records show as verified, you’re good to send. You can also use a tool like mxtoolbox.com to check your DNS records independently.

One practical note: if you’re testing during development and don’t have a business domain yet, use whatever domain you own. The important thing is that you own it and can add DNS records. Don’t try to send from a Gmail or other provider’s address — Resend won’t let you, and rightfully so.

---

Generating Your API Key

Go to API Keys → Create API Key.

Give it a descriptive name — something like “SendJob Production” or “n8n Automation.” Under permissions, give it Full Access for now. (When you’re operating in production with multiple services, you might want to create scoped keys — but start with full access while building.)

Click Create, and the key is displayed exactly once. Copy it immediately and store it somewhere safe — a password manager, an environment variable file, or your n8n credential store. You will not be able to see it again after you close that dialog. If you lose it, you just create a new one.

Important: this is a secret key. Do not put it in client-side code, do not commit it to a public Git repository, do not paste it into a Notion doc shared with your team. Treat it the same way you’d treat a password.

---

Testing the API Before Touching n8n

Before you wire anything into n8n, confirm the API works with a direct call. This isolates problems — if the API call works but the n8n workflow doesn’t, you know the issue is in the n8n configuration, not the Resend credentials.

Open your terminal and run this cURL command, replacing the placeholders with your real values:

curl -X POST https://api.resend.com/emails \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "jobs@yourverifieddomain.com",
    "to": ["your@email.com"],
    "subject": "Test email from Resend",
    "html": "<p>This is a test. If you got this, the API is working.</p>"
  }'

If everything is working, you’ll get a JSON response with an id field — that’s the Resend message ID. If you get an authentication error, check your API key. If you get a domain error, your domain isn’t verified yet or you’re using the wrong from address.

The from field must use your verified domain. You can’t send from a Gmail address or any domain that isn’t verified in your Resend account. This is by design.

---

Connecting Resend to n8n

n8n has a native Resend node, but I find it easier to use the HTTP Request node directly — it’s more flexible, and you’ll understand exactly what’s happening. Here’s how to set it up both ways.

Option 1: HTTP Request node (recommended)

First, store your API key as a credential in n8n:

1. In n8n, go to Credentials → New → Header Auth
2. Name: “Resend API”
3. Name field: Authorization
4. Value field: Bearer YOUR_API_KEY
5. Save

Now build a simple test workflow:

1. Add a Manual Trigger node
2. Add an HTTP Request node connected to it
3. Configure the HTTP Request:
   • Method: POST
   • URL: https://api.resend.com/emails
   • Authentication: Predefined Credential Type → Header Auth → select “Resend API”
   • Body Content Type: JSON
   • Body:

     {
       "from": "jobs@yourverifieddomain.com",
       "to": ["your@email.com"],
       "subject": "Test from n8n",
       "html": "<p>n8n and Resend are connected.</p>"
     }
     

Run it manually. If you get a successful response and the email arrives, the connection is working.

Option 2: Native Resend node

n8n’s built-in Resend node works the same way under the hood — it just wraps the HTTP call in a cleaner UI. Go to Add Node → search “Resend” → configure with your API key credential. The native node is fine, but switching to HTTP Request later (when you need more control over the payload) is easy.

---

Building a Real Email in n8n

A static test email isn’t useful. Here’s how to make the email dynamic — pulling data from the workflow to populate the content.

Imagine you have a webhook that receives a new job submission. The payload includes the customer’s name, the job type, and their email address. You want to send them a confirmation email.

Add a Webhook trigger node to receive the job submission. The incoming payload looks like this:

{
  "customer_name": "Maria Santos",
  "customer_email": "maria@example.com",
  "job_type": "HVAC repair",
  "appointment_date": "March 30, 2026"
}

In your HTTP Request node (pointing to Resend), set the body to use n8n expressions:

{
  "from": "jobs@yourcompany.com",
  "to": ["{{ $json.customer_email }}"],
  "subject": "Your {{ $json.job_type }} appointment is confirmed",
  "html": "<p>Hi {{ $json.customer_name }},</p><p>Your appointment is confirmed for {{ $json.appointment_date }}. We'll be in touch before we arrive.</p><p>Questions? Reply to this email.</p>"
}

The double curly brace syntax {{ $json.fieldName }} is n8n’s expression syntax. It pulls values from the incoming data and inserts them into your payload. Run this with a test payload and you’ll get a personalized confirmation email with the customer’s actual name and job details.

For more complex HTML templates — multiple sections, a company logo, branded styling — you’ll want to build the HTML in a Code node first, then reference the output in the HTTP Request body. The advanced guide covers building React Email templates that compile to consistent inbox-ready HTML.

---

Reading the Resend Dashboard

After your workflow runs, go to the Emails section in Resend. Every email you sent appears here with its full event history.

For each email you can see:

• Delivered — The receiving mail server accepted the message
• Opened — The recipient opened the email (tracked via a 1x1 pixel image)
• Clicked — The recipient clicked a link (if click tracking is enabled)
• Bounced — The email couldn’t be delivered (address doesn’t exist, server rejected it)
• Complained — The recipient marked it as spam

A note on open tracking: the open event fires when the tracking pixel loads. This works fine for most email clients, but Apple’s Mail Privacy Protection (introduced in iOS 15 and macOS Monterey) pre-loads email content, which means opens from Apple Mail users will show as “opened” even if they never actually read it. Don’t build critical business logic on open rates alone. Delivery confirmation is reliable; open tracking is directional at best.

---

Testing Best Practices

A few rules I follow to keep testing clean:

Never test with real customer email addresses. Use your own email account or a dedicated test inbox. Services like Mailosaur and Mailtrap give you test inboxes specifically for this purpose — emails arrive for inspection but never land in a real person’s inbox.

Use a separate API key for development. Create one API key named “Development” and one named “Production.” Use the development key in your n8n test environment. This way, if you need to rotate or revoke the production key for any reason, your live automation isn’t affected.

Test all failure modes, not just the happy path. Send to a deliberately invalid email address (test@thisdoesnotexist.invalid) to see what a bounce looks like in your dashboard. Understanding what failures look like before they happen in production means you’ll recognize them faster when they do.

Check your Emails log after every test. Don’t just assume the email arrived. Look at the Resend dashboard and confirm the delivery status. A missing delivery event tells you where in the chain something broke.

---

Once the basics are working, Advanced Resend → covers templates, bounce handling, and deliverability best practices.