Domain-based email, without ever running your own mail server
Lesson 7 explained how SPF/DKIM/DMARC prove an email claiming to be from your domain is legitimate. This lesson is the other half of the same picture: how you@example.com actually becomes a real, working inbox at all, without anyone on your team ever operating a mail server.
Beginner
2 min read
The confusion this lesson exists to clear up: web hosting and email are completely independent
A genuinely common misconception: that whatever platform hosts a website (Vercel, Railway, Render — this whole subcategory's other domains) also handles that domain's email. It doesn't, and was never meant to — a web host serves HTTP requests; email is an entirely separate protocol (SMTP for sending, IMAP/POP for reading) requiring its own, separate service, configured through its own, separate DNS records (MX, specifically, plus lesson 7's SPF/DKIM/DMARC).
Full mailbox hosting: Google Workspace or Microsoft 365
For a real, full inbox (sending, receiving, a genuine mail client experience) under your own domain, Google Workspace and Microsoft 365 are the two dominant managed options — each provisions real mailboxes (you@example.com) and tells you exactly which MX records to add, handling SPF/DKIM/DMARC setup guidance as part of onboarding specifically because getting those three records right (lesson 7) is what determines whether mail sent from these services actually gets delivered cleanly.
Forwarding-only email: when you need the address to exist, but not a real inbox
contact@example.com → forwards to → your-real-gmail@gmail.com
Many registrars and DNS providers (Cloudflare's own free email routing being a common choice) offer forwarding-only email — you@example.com isn't a real, separate mailbox at all; it's a rule that immediately redirects any mail sent to it into an existing inbox you already check. This is genuinely sufficient for a small project or personal domain wanting a professional-looking address without paying for (or managing) a full mailbox — the real limitation: you can typically only receive mail at the custom address this way, not send from it directly without extra configuration on the receiving mailbox's own side (most providers, including Gmail, support "send as" configuration for exactly this case).
Why this curriculum's own project used exactly this pattern
This curriculum's own devreps project uses dev.reps.ai@gmail.com — a real Gmail inbox, not a custom domain's own dedicated mailbox — which is a completely legitimate, common choice for a project at this stage: full Workspace hosting is a real, recurring cost that doesn't always justify itself before a project has the email volume or professional-appearance need to warrant it. Choosing forwarding (or simply using a plain email provider's own address) instead of full mailbox hosting is a real, deliberate cost/convenience trade-off, not a lesser or incomplete setup.
The practical decision, summarized
Need: a professional appearance, occasional contact form emails
→ forwarding-only is genuinely sufficient
Need: a real team, multiple people needing their own inbox,
genuine email-based collaboration (shared calendars, real
attachments workflow)
→ full Workspace/365 hosting is worth the cost