When I decided to add a newsletter to my portfolio, I expected it would be easily done in a few prompts to Claude. Add a form, connect my Gmail, done. Spoiler: it wasn't.
I had implemented email sending before at work, but it was always a few code snippets connecting to an API. I would just connect the frontend and backend logic and email sending would automatically work. The domain configuration, DNS records, and API keys were handled by DevOps colleagues who had everything set up before I touched it. I never had to think about what was underneath.
My initial plan was to store newsletter subscribers in a Neon Postgres database. But the more I thought through the full flow, a welcome email, notifications when a new post goes live, an unsubscribe option, the more it made sense to let Resend handle all of that. Building it myself would mean writing a lot of infrastructure for problems that were already solved. So I switched to Resend.
The first thing I did was look for a way to paste in my Gmail address as the sender. There was no such option. That's when I realised I had no idea how email actually works.
Why you can't just use Gmail
My assumption was simple: I have a Gmail account, I want to send emails, so I use my Gmail. That is not how it works.
Email providers like Resend send emails on your behalf from their own servers. If they tried to send an email claiming to be from vucomarija00@gmail.com, Gmail's servers would immediately flag it as suspicious. The sending server and the domain in the From address don't match, and that's exactly what email spoofing looks like. Spam filters are built to catch it.
There are workarounds.
Gmail SMTP relay. Use Gmail's own server to send emails. Limits you to 500 emails per day and requires configuring an App Password, a special code Google generates so third-party apps can access your account without using your real password.
Google Workspace. Pay around $6/month and get a real hello@yourdomain.com Gmail address. A cool option, but I am building this portfolio just for fun. It makes no sense to spend money on a personal email just for it.
The proper solution is to verify your own domain and send from that. It's free, professional, and the way everyone else does it. So I verified marijavuco.com in Resend and now send from noreply@marijavuco.com.
How email authentication actually works
To send emails from noreply@marijavuco.com, I had to prove to the internet that I own that domain and that I've authorised Resend to send on my behalf. That proof lives in DNS records.
There are four records involved.
SPF (Sender Policy Framework) authorises which servers are allowed to send email for your domain. It is a TXT record listing approved senders. When a receiving mail server gets an email from noreply@marijavuco.com, it checks the SPF record to see if Resend's servers are on that list.
DKIM (DomainKeys Identified Mail) validates the integrity and authenticity of the email. Resend adds a cryptographic signature to every email it sends on your behalf. The receiving server checks that signature against a public key in your DNS. If the signature matches, the email hasn't been tampered with in transit and genuinely came from an authorised sender.
DMARC (Domain-based Message Authentication, Reporting and Conformance) enforces policy by telling receiving servers what to do if SPF or DKIM fails: deliver it, quarantine it, or reject it outright.
MX (Mail Exchange) records primarily tell other mail servers where to deliver email for your domain. They can also be scoped to a subdomain, which is what Resend does for bounce handling. The host is send, so the record lives on send.marijavuco.com, not the root domain.
All of these are records you add in Namecheap. Resend tells you exactly what to paste in.
Receiving replies in Gmail
I originally wanted to set up email forwarding in Namecheap so that direct emails to hello@marijavuco.com would land in Gmail. But Namecheap disables Email Forwarding as soon as you add custom MX records. I needed Resend's MX record for bounce handling, so the two features are mutually exclusive.
I added a replyTo field in the Resend API call pointing to my Gmail address, so replies go there automatically.
The fix was to switch the sender address to noreply@marijavuco.com. It signals to recipients that replies aren't expected there, which is honest. Newsletter replies still go to Gmail via replyTo.
What I would do differently
I would read before I built. I jumped straight into the form without understanding how email actually works, which meant I had to figure out authentication, DNS records, and sender verification as I went. None of that was obvious, and an hour of reading upfront would have saved a lot of time.
I also would have picked the right tool from the start. I began with a Postgres approach before realising Resend handled everything I needed. That switch mid-way cost time that better research would have avoided.