Email is not a solved problem
Most people assume email just works. You add a contact form, it sends a message, it arrives in an inbox. In reality, transactional email has a lot of moving parts. DNS records need to be configured correctly. Domains need to be authenticated. IP reputation matters. And if any of these are set up wrong, messages go to spam or disappear entirely.
We use Resend for transactional email on client projects because it handles the infrastructure layer well and stays out of the way during development. This is part of the broader infrastructure stack we maintain on self-hosted servers, which gives us full control over how each piece is configured and monitored.
What transactional email actually covers
Transactional email is any automated message triggered by a user action. Contact form submissions, booking confirmations, welcome messages after signup, password resets, order receipts. These are not marketing emails. They are functional messages that need to arrive reliably.
The difference matters because marketing email and transactional email have different rules around deliverability, different sending patterns, and different failure modes. For Payload CMS projects, transactional email is typically wired in from the start so form submissions and admin notifications work from day one.
Why Resend fits the way we work
Resend has a clean API, good TypeScript support, and straightforward DNS setup. When we add email to a project, we configure the domain, add the necessary SPF, DKIM, and DMARC records, and connect it to the application through the API. The whole setup takes about an hour.
It also gives us a clear view of what is being sent and whether it is being delivered. If something breaks, the logs are readable and the error messages are useful. That is not always true with older email infrastructure.
The DNS setup that most teams skip
The part that causes the most deliverability problems is DNS authentication. SPF tells receiving mail servers which services are allowed to send on behalf of your domain. DKIM adds a cryptographic signature that proves the message was not tampered with. DMARC tells receiving servers what to do when a message fails either check.
Without all three, email from a custom domain often ends up in spam folders, especially with Gmail and Outlook. With all three configured correctly, messages land reliably. This is one of the maintenance checks we include in any ongoing website maintenance plan — a broken email setup can silently kill lead flow without any obvious error on the site.
Why this matters beyond just forms
Once transactional email is set up properly, it unlocks a lot of functionality. Notification systems, automated follow-ups, confirmation flows, internal alerts. All of it runs through the same infrastructure. Getting the foundation right once means every feature that relies on email works without extra configuration.
