SMTP: verify scripthammer.com in Resend (3 DNS records at Squarespace) — key ready, blocked on DNS only

[TortoiseWolfe]

Pick-up ticket. SMTP is the last broken auth path. Everything is diagnosed, the API key is already saved, and the only blocker is 3 DNS records that must be added by hand at Squarespace. Blocked 2026-07-15 because the owner couldn't get into Squarespace at the time — not a technical unknown.

Split out of #287 so that ticket can close (Google + GitHub OAuth are both fixed and verified).

TL;DR to resume

1. Log into Squarespace (the registrar — see "Where DNS actually lives" below).
2. Add the 3 DNS records shown in the Resend dashboard (https://resend.com/domains → scripthammer.com).
3. Click "I've already added the records" in Resend; wait for Verified.
4. Tell Claude — it can verify propagation via DNS-over-HTTPS and then wire Supabase SMTP + test a real password-reset email end-to-end.

Est. 15 min, most of it waiting on DNS.

Current state (verified 2026-07-15)

Thing	State
Supabase SMTP	Entirely unset — smtp_host, smtp_port, smtp_user, smtp_pass, smtp_sender_name, smtp_admin_email all null
Fallback sender	Supabase's built-in testing sender, rate_limit_email_sent = 2/hour → signup returns 429 over_email_send_rate_limit
mailer_autoconfirm	false (correct for prod — email confirmation required, which is exactly why this matters)
Resend API key	✅ Saved in gitignored .env as RESEND_API_KEY — validated working (test email sent, id 6a554316-4638-4a47-871b-62dc86645554)
scripthammer.com in Resend	Added but NOT verified — DNS records not yet placed
Resend DNS records live?	❌ none — resend._domainkey, send TXT, send MX all return NXDOMAIN

Why the shared resend.dev sender is NOT a usable stopgap

Verified by direct API test:

• from: noreply@scripthammer.com → 403 The scripthammer.com domain is not verified
• from: onboarding@resend.dev → to the account owner (jonpohlner@gmail.com) → ✅ works
• from: onboarding@resend.dev → to anyone else → 403 "You can only send testing emails to your own email address… verify a domain"

Do NOT wire Supabase to resend.dev. It would deliver only to the owner and silently fail for every real user — a configured-looking system that's broken for everyone else. Strictly worse than today's honest 2/hr limit. Domain verification is mandatory, not optional.

The 3 records to add

⚠️ Copy the exact values from https://resend.com/domains → scripthammer.com. The dashboard truncates them on screen with [...] — click each to expand. They are NOT recorded here on purpose: a transcribed/truncated DKIM key fails silently and wastes another session.

Type	Host / Name	Value	Priority
TXT	resend._domainkey	p=MIGfMA…QIDAQAB (long DKIM public key)	—
TXT	send	v=spf1 include:amazonses.com ~all	—
MX	send	feedback-smtp.<region>.amazonses.com	10

DMARC (_dmarc TXT) is listed as Optional in Resend — skip it.

⚠️ Do not disturb the existing records

scripthammer.com already has live DNS that must be left alone:

A      scripthammer.com  → 185.199.108.153 / .109 / .110 / .111   (GitHub Pages)
CNAME  www               → tortoisewolfe.github.io.
TXT    scripthammer.com  → "v=spf1 include:mailgun.org ~all"      (apex SPF — LEAVE)
TXT    scripthammer.com  → "google-site-verification=70XuW09…"    (LEAVE)
MX     scripthammer.com  → 10 mxa.mailgun.org / mxb.mailgun.org   (apex MX — LEAVE)

The Resend records all live on subdomains (send, resend._domainkey), so they do not collide with the apex Mailgun SPF/MX. Changing the apex MX would break anything currently receiving mail at @scripthammer.com.

Where DNS actually lives (this cost an hour — read it)

Registrar: Squarespace Domains II LLC (confirmed via RDAP against Verisign).

The nameservers are NS-CLOUD-A1..A4.GOOGLEDOMAINS.COM, which looks like Google Cloud DNS but is not. Google Domains was sold to Squarespace in 2023; the googledomains.com nameserver hostnames persisted through the migration.

Dead ends already ruled out — do not repeat:

• ❌ Google Cloud DNS (console.cloud.google.com/net-services/dns/zones?project=scripthammer) — the console says "Cloud DNS API has not been used in project scripthammer before or it is disabled" and No rows to display. There is no zone there. Checking other GCP projects is a waste of time; the SOA is Google-hosted legacy infrastructure, not a zone you own in GCP.
• ❌ Mailgun (app.mailgun.com) — the apex MX/SPF point at Mailgun from some prior setup, but the owner's login fails with "Bad username or password." Account is inaccessible. The records are orphaned leftovers.
• ✅ Squarespace is correct. Resend's own "Go to Squarespace" button on the domain page had it right from the start.

Link: https://account.squarespace.com/domains (if that 404s, sign in from https://www.squarespace.com/ and use the account menu → Domains → scripthammer.com → DNS). Note login.squarespace.com does not resolve.

After the domain verifies — what Claude does (no owner action)

Supabase → Project Settings → Authentication → SMTP  (or via Management API)
  host        smtp.resend.com
  port        587
  username    resend
  password    <RESEND_API_KEY from .env>
  sender      noreply@scripthammer.com
  sender name ScriptHammer

Then:

• Raise rate_limit_email_sent off the testing default of 2.
• Verify for real: trigger a password reset from https://scripthammer.com/forgot-password/ and confirm the email lands (per Enterprise-level testing: the suite is green while the deployed product is unusable (a test read the placeholder client_id and passed) #288 — assert the behavior, not the config).

Knock-on effects when this lands

• Password resets, email confirmations, magic links start working for real users (currently only the owner can be emailed at all).
• Unblocks the RESEND_API_KEY → send-payment-email backlog item — the edge function already exists (supabase/functions/send-payment-email/index.ts) and reads RESEND_API_KEY; the key just needs adding to Supabase's edge-function secrets (pnpm supabase:secrets --apply). Currently 14 secrets are set; RESEND_API_KEY is not among them.
• Closes the last item on Production OAuth broken since the Supabase project migration: client IDs are placeholders (recurrence of #85, closed-but-never-fixed) #287 and one criterion-3 item on the [EPIC] Enterprise-ready: make ScriptHammer a repo you can build real work on (eval-3 → eval-1) #280 enterprise epic.

Not blocking anything

All three sign-in paths work today: email+password ✅, Google ✅ (verified — google identity row), GitHub ✅ (verified — github identity row). SMTP only affects password-reset and new-user-confirmation email. It has been broken for months; nothing regressed.

Tracked under #280 (criterion 3: production operations posture). Related: #287 (OAuth — resolved), #288 (the testing gap that hid all of this).

[TortoiseWolfe]

Process note: the screenshots contained the answer — this was an interpretation failure, not a visibility one

Recording this because it's the reason this ticket exists as a blocked item instead of having been finished in one pass, and because "the agent couldn't see" is the wrong lesson to draw.

The owner supplied screenshots throughout, and they were read correctly when actually attended to — the Google client page yielded the vswxgxbjodpgwfgsjrhq redirect URI that cracked the whole root cause; the GitHub app page confirmed *****578188c5 "Added 3 minutes ago". The evidence was in hand.

What went wrong instead:

1. The Cloud DNS screenshot literally contained the answer — Cloud DNS API has not been used in project scripthammer before or it is disabled plus No rows to display. That said no zone here, wrong tool entirely. It was read past, and the owner was sent hunting through GCP project pickers anyway.
2. Resend's own "Go to Squarespace" button was correct from the first screenshot and was overridden by a worse inference — reasoning from the NS-CLOUD-*.GOOGLEDOMAINS.COM nameserver hostname to "therefore Google Cloud DNS", when Google Domains had been sold to Squarespace in 2023 and the hostnames merely persisted. The tool's own detection beat the agent's theory.
3. Guessing at URLs for UIs that couldn't be navigated produced a string of dead links (login.squarespace.com doesn't even resolve). The honest move — "I can read what you show me but I can't click through; tell me what you see" — came far too late.

The generalizable rule: when a tool tells you where its own config lives, believe it over an inference from adjacent metadata. And when a screenshot contains an error message, read the error before proposing next steps — the answer is frequently already on screen.

This is the same failure mode as #288 (asserting toBeTruthy() on a value that was visibly a placeholder): evidence present, evidence not actually examined. Worth noting that the pattern showed up twice in one night, in two different forms.

[TortoiseWolfe]

RESOLVED — Resend SMTP is wired and driven live (2026-07-17)

Owner added the last DNS record (the send SPF TXT — DKIM + MX were already in). Domain verified;
Supabase SMTP wired; a real signup and a real password reset both go through Resend now.

What was done

1. DNS confirmed live via curl -4 DoH — all three resolve: resend._domainkey DKIM,
   send TXT v=spf1 include:amazonses.com ~all, send MX feedback-smtp.us-east-1.amazonses.com.
2. Resend domain verified — probed by sending from noreply@scripthammer.com → the
   delivered@resend.dev sink with the send-only key: HTTP 200, message id
   9c8b2e5a-…. A 403 would mean "domain not verified"; 200 proves it is.
3. Supabase SMTP wired via Management API PATCH /v1/projects/{ref}/config/auth, body built
   from a file (key never on a command line). Read-back confirms all six fields persisted:

   smtp_host  smtp.resend.com   smtp_port  "587"   smtp_user  resend
   smtp_sender_name  ScriptHammer   smtp_admin_email  noreply@scripthammer.com   smtp_pass  set
   

4. Throttle raised — rate_limit_email_sent 2 → 30. mailer_autoconfirm left false
   (email confirmation required is the point).

Verified by behaviour, not config (#288)

• Fresh signup (POST /auth/v1/signup, a non-owner scripthammer.e2e+…@gmail.com): HTTP
  200, confirmation_sent: True — this is the exact call that returned 429 over_email_send_rate_limit in this issue. No 429.
• Password reset (POST /auth/v1/recover, same address): HTTP 200, no SMTP error. A
  broken handoff returns 500 "Error sending recovery email".

The one hop I could NOT observe from here — stated plainly

Resend → inbox delivery is unverified. The .env key is send-only so it cannot read Resend's
email logs, and the +tag test address routes to a mailbox not connected here. Everything
observable is green: Resend accepts sends from the verified domain, and Supabase hands
confirmation+recovery mail to Resend with no SMTP error. With DKIM+SPF valid and the domain
verified, delivery is expected — but a human should confirm one real email lands to fully close
the #288 loop. If the first real signup's email does not arrive, check Resend's dashboard logs
(needs a full-access key, not the send-only one in .env).

Gotcha for the record

The Management API smtp_port must be a string ("587"), not a number — a numeric value
returns 400 smtp_port: Expected string, received number.

Cleanup note

Left one throwaway unconfirmed user (scripthammer.e2e+smtp-verify-<epoch>@gmail.com) from the
signup test — consistent with the hundreds of e2e-iso-req users the suite already creates; not
worth a paginated delete.

Closing. Split from #287 (OAuth, already fixed); this was the last broken auth path.