Set Up Resend Right: A Marketer's Checklist with an AI Agent

Last week our Module 2.7 announcement went out to 335 subscribers. Writing the email took an hour. What took the rest of the afternoon was everything an AI agent found half-configured before we hit send: a release download that didn't contain the lesson the email announced, a hero image that would have arrived broken, and a tracking domain quietly borrowing strangers' reputation.

We run email through Resend and like it a lot. But "domain verified" is where most setups stop, and it's maybe half of a real setup. Here's the checklist worth pinning, what each item protects, and the prompt that makes an agent run the whole audit for you.

Eight items. The first two you probably have; the rest are the ones that slip.

• A verified sending subdomain (like mail.yourdomain.com) with DKIM and SPF showing green. Onboarding walks you through this one.
• Signup wired to do two things: send the welcome email and insert the contact into an Audience. Miss the second and you're greeting people you can never email again.
• A custom click-tracking subdomain instead of Resend's shared one.
• Open tracking switched off.
• A DMARC record in monitor mode, with reports going to an address on your own domain.
• Catch-all email routing (or a dedicated dmarc@ rule) so those reports actually reach an inbox.
• The unsubscribe merge tag in every broadcast footer.
• Every image in the email hosted on your own domain, and deployed before you send.

When click tracking is on, Resend rewrites every link to pass through a redirect domain first. On the shared default, that domain is pooled with thousands of other senders, and their spam complaints drag on your deliverability. The fix is one CNAME: a subdomain you own, like links.mail.yourdomain.com, pointed at Resend. Link reputation becomes yours alone.

Open tracking is the opposite case: Resend itself labels it "Not Recommended". The tracking pixel produces inaccurate opens and can hurt deliverability, so leave it off unless you have a specific reason.

DMARC in monitor mode (p=none) is free insurance. Mailbox providers send you daily reports on every message claiming to be from your domain, without rejecting anything. One detail matters: point the rua report address at your own domain. Reports sent to a cross-domain address like a Gmail inbox get silently ignored by compliant providers. After a month of clean reports, tighten the policy to quarantine.

None of this is hard. All of it is forgettable. The agent's job is refusing to skip the verification steps humans skip. On our send, working inside Claude Code with browser access, the agent:

• Counted the audience before sending (335 contacts, 335 subscribed, 0 unsubscribed) instead of assuming the list was healthy.
• Noticed the course download the email promoted was three months stale and didn't contain the new lesson, and cut a fresh release before the send.
• Caught that the email's cover image would 404 because the site deploy hadn't shipped yet, and reordered: deploy first, test email second, broadcast last.
• Added the tracking CNAME and DMARC records from the command line, verified them with dig, and only then told Resend to check.

The pattern is the same one we teach in the course: the agent handles pattern-matching and verification, you keep the judgment calls, and nothing goes out on vibes.

Paste this into Claude Code (or any agent with browser and DNS access). It works as a first-time setup and as a pre-send audit.

Audit my Resend setup end to end. Work through this checklist and
show me proof for each item (dashboard state, DNS answers, or API
responses). Stop and ask before anything irreversible: sends, DNS
changes, releases.

1. SENDING DOMAIN. Confirm the sending subdomain is verified:
   DKIM and SPF records all green in Resend.
2. AUDIENCE. Confirm the signup flow both sends the welcome email
   AND inserts the contact into an Audience. Report current counts:
   total, subscribed, unsubscribed.
3. CLICK TRACKING. Check whether the domain uses shared click
   tracking. If yes, configure a custom tracking subdomain
   (links.<sending-domain>), add the CNAME (DNS-only, not proxied),
   and verify it.
4. OPEN TRACKING. Confirm it is off unless I explicitly want it.
5. DMARC. Check the _dmarc TXT record on the sending subdomain.
   If missing, add: v=DMARC1; p=none; rua=mailto:dmarc@<root-domain>
   and verify with dig. Remind me to tighten to p=quarantine after
   a month of clean reports.
6. REPORT ROUTING. Confirm dmarc@<root-domain> routes to a real
   inbox (a catch-all rule counts).
7. BROADCAST HYGIENE. Before any send: report the recipient count,
   send me a test email, confirm every image URL in the email
   returns 200, and confirm the unsubscribe link is present.
List anything you could not verify at the end.

Two habits make it stick. Run the audit before every broadcast, not once; settings drift when sites redeploy and releases ship. And make the agent show proof (a dig answer, a status code, a screenshot) instead of accepting "looks good".

This post is the setup half of a bigger practice: making an agent verify the boring parts so your announcement actually lands. The sending half, turning finished work into something worth announcing, is in Module 2.7: Service Package from a Real Engagement . If you're systemizing the whole ship-and-announce loop, The Last Mile of Shipping covers turning release steps into slash commands, and all 4 modules and 19 lessons are free.

Happy sending! Hit reply on any of our emails if your audit turns up something weird, I collect these.