The email pipeline gets tested on production because DNS only exists there

Transactional email cannot be fully tested in staging. Resend validates the sending domain through DKIM records configured on the production DNS. A staging environment on a different hostname would need its own domain, its own DNS records, its own Resend verification — at which point it is no longer testing the production pipeline. So the tests run on production. Each test submission carries a message that describes what it is verifying. The first confirms the form submits and the notification arrives in the inbox. The second confirms the subject line formats correctly with a business name in parentheses. The third tests without a business name to verify the conditional formatting. The fourth adds the auto-responder and checks that the enquirer receives a confirmation. The fifth and sixth iterate on the auto-responder wording and verify the final version delivers correctly. Each test message reads like a code comment — it states the expected outcome so the inbox becomes a verification log. If an email is missing, the message on the previous test tells you what should have arrived. If everything is present, the inbox contains a chronological record of passing checks. The whole process takes under twenty minutes. No test framework, no mock SMTP server, no assertion library. Real form submissions on the real domain with real Resend delivery to a real inbox. The alternative — mocking Resend in a test suite — would verify that the code calls the SDK correctly but would not verify that the DNS records work, the domain is verified, the API key has the right permissions, or the emails actually arrive. Unit tests verify code paths. Production tests verify delivery. Both matter. The unit tests run in CI with mocked transports. The production tests run once after deployment, by hand, with messages that explain themselves.