Stale Mailgun DNS after the Resend cutover: root SPF, dead MX, and DMARC without reporting

[TortoiseWolfe]

Split out from #356, which is closed because the question it was filed to answer — is sign-up mail actually reaching people? — is now answered: yes. All 32 real sign-ups delivered, and the 78.6% bounce rate came entirely from one E2E test, now fixed (#361) and guarded by a daily bounce-rate gate (#363).

These DNS items from that issue are still outstanding. None of them is breaking delivery today, which is exactly why they are easy to forget.

Verified live 2026-07-27:

scripthammer.com        TXT  v=spf1 include:mailgun.org ~all
_dmarc.scripthammer.com TXT  v=DMARC1; p=none;
scripthammer.com        MX   10 mxa.mailgun.org / 10 mxb.mailgun.org
send.scripthammer.com   TXT  v=spf1 include:amazonses.com ~all   ← correct (Resend)
resend._domainkey…      TXT  present                              ← correct (Resend DKIM)

1. Root SPF still authorises dead Mailgun, not Resend. Mail passes DMARC today via aligned DKIM, and the return-path subdomain carries its own valid SPF — so this is latent, not broken. It becomes real the moment anything sends with the root domain as the envelope sender, or if DKIM signing is ever disrupted. The record should name the current sender or be removed.

2. DMARC has no reporting. p=none; with no rua= means nobody would ever learn that authentication started failing. Given the whole point of #356 was that a mail problem went unnoticed for six weeks, adding a rua= destination is the cheapest possible detection.

3. MX still points at Mailgun. Inbound mail to @scripthammer.com is black-holed. Anyone replying to a confirmation email — or a mailbox provider probing the domain — hits a dead host.

DNS is at Squarespace (nameservers still googledomains), so these are console changes, not API ones. See reference_scripthammer_dns_and_smtp.

Order to do them in: (2) first, since reporting tells you whether (1) is actually hurting anything.

[zac343]

I re-checked the public records at 2026-07-27 02:31 UTC and they match the issue: root Mailgun SPF/MX, send.scripthammer.com SES/Resend SPF, resend._domainkey, and DMARC p=none without reporting.

One boundary is worth making explicit before editing the root SPF: do not replace include:mailgun.org with include:amazonses.com merely because Resend is current. The live Resend return path is already the send.scripthammer.com subdomain. SPF is evaluated against the SMTP envelope domain, so the root record should describe only services that actually use a root-domain MAIL FROM. If none do, removing the stale root SPF is cleaner than authorizing SES there without evidence; if another service does, preserve that sender instead. Also avoid publishing a second root SPF record.

I would make the cutover proof three independent gates:

1. DMARC: add one rua destination at p=none, confirm reports arrive, and add external-report authorization if the aggregate mailbox is on another domain.
2. Outbound: send one controlled Resend message and retain its full headers; prove aligned DKIM and the actual envelope/SPF domain from Authentication-Results rather than inferring it from DNS alone.
3. Inbound: decide where replies to the visible From/Reply-To addresses must land, prove that mailbox receives, then replace/remove the Mailgun MX. Removing the old MX before choosing an inbound route would turn a known stale route into an explicit no-mail route.

That sequence keeps the inbound MX decision separate from outbound authentication and gives a before/after artifact for #368.

Public no-login baseline for the exact domain: https://mailcheck.agentcartai.com/?domain=scripthammer.com&dkimSelector=resend&autostart=1&utm_source=github&utm_medium=issue_comment&utm_campaign=scripthammer_resend_dns_368

[TortoiseWolfe]

Verified target state

Queried the Resend API directly (2026-07-27). Resend requires exactly three records, all verified, and none of them is at the root domain:

Name	Type	Value	Status
resend._domainkey	TXT	p=MIGfMA0GCSqG…	verified
send	MX	feedback-smtp.us-east-1.amazonses.com	verified
send	TXT	v=spf1 include:amazonses.com ~all	verified

Do not touch those three, or the google-site-verification TXT. Everything else on the root is Mailgun leftover.

Mail currently passes DMARC on aligned DKIM (the key above signs as scripthammer.com), which is why all 32 real sign-ups delivered despite the root SPF naming a dead provider. That is also why this is latent rather than broken.

1. Root SPF — replace, do not just delete

scripthammer.com  TXT   v=spf1 include:mailgun.org ~all     ← remove
scripthammer.com  TXT   v=spf1 -all                         ← add

Resend sends with an envelope sender under send.scripthammer.com, which carries its own SPF, so the root needs no include:. The only other root TXT is a Search Console verification, which does not send. -all states plainly that nothing sends directly as the bare domain, which is what makes spoofing it harder.

Deleting the record instead of replacing it would leave no SPF policy, which is weaker than an explicit -all.

2. Root MX — a decision, not just an edit

scripthammer.com  MX  10 mxa.mailgun.org
scripthammer.com  MX  10 mxb.mailgun.org

Mail sent to @scripthammer.com is handed to a provider that is no longer in use. Anyone replying to a confirmation email is silently black-holed today.

• If inbound mail is not wanted: replace both with a null MX (RFC 7505) — MX 0 . — so senders get an immediate, honest bounce instead of silence.
• If inbound mail is wanted: point MX at a real mailbox provider. That is a paid signup, not a DNS-only change.

This does not affect the send subdomain MX, which is separate and must stay.

3. DMARC reporting — blocked on a destination

_dmarc.scripthammer.com  TXT  v=DMARC1; p=none;

No rua=, so nobody would learn if authentication started failing — the exact blind spot that let #356 run for six weeks unnoticed.

Adding rua= needs a destination that can actually receive reports, and there isn't one yet:

• scripthammer.com cannot receive (see item 2).
• A Gmail address does not work: RFC 7489 §7.1 requires the receiving domain to publish scripthammer.com._report._dmarc.gmail.com, which we cannot add to gmail.com.
• crudgames.com and geolarp.com were checked — neither publishes MX, so neither can receive either.

Workable options:

1. A free DMARC report service (Postmark DMARC digests, URIports, dmarcian free tier). They provide an address on their own domain and publish the required authorization record. Needs a signup.
2. Resolve item 2 with a real mailbox provider first, then use dmarc@scripthammer.com.

Once a destination exists the record becomes:

_dmarc.scripthammer.com  TXT  v=DMARC1; p=none; rua=mailto:<destination>; fo=1

Keep p=none until reports confirm all legitimate mail passes; only then consider quarantine.

Why this cannot be scripted

DNS is at Squarespace (nameservers still googledomains). There is no DNS API credential in the environment and Squarespace exposes no DNS API, so these are console edits. Verification afterwards is scriptable — DoH queries confirm propagation, and scripts/check-email-health.mjs already watches the delivery side.

Suggested order: 1 → 2 → 3, since the DMARC destination depends on what item 2 decides.

[TortoiseWolfe]

Correction: free forwarding is already included — this replaces items 2 and 3 above

Squarespace-managed domains include email forwarding at no cost, up to 100 aliases, and it auto-creates the MX/TXT/DMARC records. That is strictly better than the null-MX option and removes the third-party DMARC service entirely.

Why it solves DMARC too: with forwarding, dmarc@scripthammer.com becomes deliverable, so rua= points at the same domain. RFC 7489 §7.1's external-destination rule only applies to other domains — so no _report._dmarc authorization record is needed, and no signup.

Revised order — enable forwarding FIRST

My original 1 → 2 → 3 order was wrong. Squarespace adds its own TXT and DMARC records when forwarding is enabled, so setting ours first risks being overwritten or, worse, duplicated.

Step 1 — enable forwarding (Squarespace → Domains → Email Forwarding)

• dmarc@scripthammer.com → your Gmail — the reporting destination
• optionally a catch-all or hello@ so replies to confirmation mail reach a human

Step 2 — reconcile SPF, and check for a duplicate

⚠️ Two SPF records on one name is a hard error — RFC 7208 says evaluators must return permerror, which is worse than the stale record we started with. If Squarespace adds its own SPF TXT at the root, do not simply add v=spf1 -all alongside it. There must be exactly one:

scripthammer.com  TXT  v=spf1 include:mailgun.org ~all   ← remove (dead provider)
scripthammer.com  TXT  v=spf1 -all                       ← only if Squarespace did not add one

Forwarding is inbound and does not need root SPF; Resend sends from send.scripthammer.com, which has its own. So -all remains correct unless Squarespace publishes something that must stay.

Step 3 — set DMARC with reporting

Squarespace may auto-add a DMARC record. Whatever it publishes, the final value should be:

_dmarc.scripthammer.com  TXT  v=DMARC1; p=none; rua=mailto:dmarc@scripthammer.com; fo=1

Keep p=none until reports confirm all legitimate mail passes.

Known limitations, stated plainly

• Receive-only. Replies you send come from your Gmail, not the alias. Irrelevant here — Resend does the sending.
• No chained forwarding. The destination cannot itself be a forwarding address.
• Conflicts with a real mailbox. If the domain ever gets a hosted mailbox, forwarding must be turned off first.
• Custom nameservers. Squarespace only auto-adds records when it manages DNS. The nameservers still read googledomains (inherited from the Google Domains migration); if the console asks for manual records instead of doing it itself, that is why — the values above are what to enter.
• Reports are raw XML. DMARC aggregate reports arrive as daily XML attachments, which are machine-readable, not human-readable. It closes the blind spot (the data exists and is arriving), but reading trends means feeding them to a parser later. Free and correct now beats nothing.

Verification

Once done, the checks are scriptable and I can run them: DoH queries confirm exactly one root SPF, the MX targets, and the DMARC value including rua. scripts/check-email-health.mjs already watches the delivery side daily.

[TortoiseWolfe]

State as of 2026-07-27 — resume here

Research is complete; nothing further can be done without console access.

Established (verified live, not assumed):

• Resend requires exactly 3 records, all verified, none at the root: resend._domainkey TXT, send MX, send TXT. Do not touch them, or the google-site-verification TXT.
• Mail passes DMARC on aligned DKIM, which is why deliverability is fine despite the root SPF naming a dead provider. This is latent, not broken.
• No DNS API credential exists and Squarespace exposes no DNS API → console edits only. Verification afterwards is scriptable.
• Neither crudgames.com nor geolarp.com publishes MX, so no owner-controlled domain can receive DMARC reports today.

Decided: use Squarespace's free built-in email forwarding (100 aliases, auto-creates records). It solves inbound mail and makes rua= same-domain, removing the need for any third-party DMARC service. $0, no new accounts.

Open question for tomorrow: whether to add a catch-all / hello@ alias alongside dmarc@, or only the reporting address.

The one trap to remember: two SPF records on one name is a permerror under RFC 7208 — worse than the stale record. Check what Squarespace publishes before adding anything.