Why Every Open Source Project Needs Its Own Domain Email

When I was starting up with community organizing, our "email system" was one person's Gmail account. Sponsors emailed that person directly. Security reports went to a personal inbox. Sometimes press enquiries sat unread for days because the one person who had the password was on holiday. When a new co-chair came on board, we forwarded credentials over LINE chat. It was embarrassing, and it took us far too long to fix it.

I should have set up proper project email on day one. It would have taken five minutes. Instead, we muddled through for years with a system that worked right up until the moment it did not.

If your open source project is still running on someone's personal email address, this is for you.

The Gmail Problem

Most open source projects start the same way. Someone registers a domain, spins up a static website on GitHub, and communication happens through whatever personal email the founder already uses. [email protected] becomes the de facto contact for the entire project.

This works fine when you are one person building a thing in your spare time. It stops working the moment any of these happen:

1. The bus factor. One person owns the email account. If that person burns out, moves on, or simply forgets the password, the project loses its communication channel. I have seen this happen more than once in the Python community.
2. No forwarding to multiple maintainers. A sponsor sends a partnership enquiry. It sits in Bob's inbox for two weeks because Bob is busy with his actual job. Nobody else even knows the email arrived.
3. Unprofessional sender identity. Your project has a proper domain and a polished website, but when you reply to a conference organiser, the email comes from [email protected]. The disconnect between the project's public face and its email undermines trust.
4. Security reports to personal inboxes. Someone discovers a vulnerability and emails the address listed in your README. That address is a personal Gmail with two-factor disabled and a password reused from 2015. This is not hypothetical. This is common.

A shared Gmail account is not a solution either. Shared passwords are a liability. Google's terms of service technically forbid it. And the moment two people are logged in simultaneously, replies collide and threads become incoherent.

I have talked to maintainers of projects who have the same problem. The pattern is remarkably consistent: it starts as a temporary arrangement ("we will fix this later"), becomes the status quo, and stays that way until something goes visibly wrong. Usually a missed email from a sponsor, a security disclosure that nobody saw for a week, or a domain renewal notice that went to an address nobody checks anymore.

What You Actually Need

The good news is that open source project email does not need to be complicated. For most projects, you need a handful of aliases on your project domain, each forwarding to the right person's existing inbox:

• hello@ or contact@ for general enquiries, forwarding to whoever handles community outreach
• security@ for vulnerability reports, forwarding to your security team (even if that is one person)
• sponsors@ or treasurer@ for financial matters, forwarding to whoever manages the budget
• press@ for media enquiries, if your project is large enough to get them

No shared passwords. No separate inboxes to check. Each maintainer receives project emails in the inbox they already use every day. When someone rotates off the team, you change the forwarding destination. No password resets, no account migrations, no handoff drama.

This is the part I wish someone had explained to me years ago. The mental model most people have is "project email means running a mail server or paying for Google Workspace." It does not. Forwarding aliases on your existing domain give you everything you need for project communication, and the people behind those aliases keep using whatever inbox they already prefer.

Email Forwarding Solves This Without a Mail Server

You do not need to run Postfix on a VPS to get project email working. Email forwarding does exactly what it sounds like: emails sent to addresses on your domain get forwarded to the real inboxes behind them.

The setup is straightforward. You point your domain's MX records at a forwarding service, create your aliases, and specify where each one delivers. The forwarding service handles receiving, and your existing inbox handles everything else.

KaiMail is one such service (and the one I built, so take that disclosure as you will). But the principle applies regardless of which forwarding service you choose. Cloudflare Email Routing, ImprovMX, Forward Email all do variations of the same thing. The point is that you separate the project's email identity from any individual's personal account, and you do it without running infrastructure.

My career started with understanding SMTP and running mail servers. I have a soft spot for email infrastructure. But I would not recommend that any open source project maintain its own mail server in 2026. The operational burden is not worth it when forwarding services exist specifically to solve this problem.

The Five-Minute Setup

Here is what the process actually looks like:

1. You already have a domain. If your project has a website, you have a domain. That is the hard part done.
2. Point your MX records at the forwarding service. This is three DNS records. If you have ever set up a CNAME for a website, you can do this. If you are on AWS Route 53, you may want to read about handling long DKIM keys while you are in the DNS console.
3. Add SPF and DKIM records. These ensure that emails forwarded through the service pass authentication checks. Without them, forwarded emails increasingly end up in spam as Gmail and Yahoo tighten their DMARC enforcement.
4. Create your aliases. security@ goes to Alice. sponsors@ goes to Bob. hello@ goes to both of them.
5. Send a test email. Confirm it arrives. You are done.

The whole thing takes less time than writing a README section about how to contact the project.

Open Source Projects Are Cost-Sensitive (And That Is Fine)

I have been involved in open source communities long enough to know that every dollar matters. PyCon JP, PyCon MY and especially our Python Asia Organization ran on volunteer time and carefully counted yen. Most open source projects operate the same way. Paying per-user fees for Google Workspace when all you need is a few email aliases is not realistic, and it should not be necessary.

Email forwarding services typically offer free tiers that cover exactly what a small to mid-sized open source project needs. One domain, a handful of aliases, reasonable volume. You are not sending marketing blasts. You are receiving sponsor enquiries and security reports. The free tier handles this.

KaiMail's free plan covers one domain with basic forwarding and 300 emails per month. For a project that gets a dozen emails a week, that is plenty. Other services like ImprovMX and Cloudflare Email Routing have their own free tiers with different trade-offs. The important thing is that cost should not be the reason your project is still running on a personal Gmail.

When Your Project Outgrows Forwarding

At some point, forwarding alone stops being enough. The moment you need to reply from your project domain (not from your personal address), you need SMTP sending capability. When a sponsor gets a reply, it should come from [email protected], not [email protected].

KaiMail now supports SMTP sending on paid plans, and other services offer similar features. The upgrade path is natural: you start with forwarding, add sending when you need it, and you never have to migrate away from the setup you built on day one.

If your project grows to the point where you need multiple domains (maybe one for the project and one for the annual conference), higher volume, or webhook integrations that pipe incoming emails into your issue tracker, those options exist too. But most projects will be perfectly well served by a free forwarding plan for a long time.

Your Project Deserves Its Own Email Identity

Looking back at those early days, the email situation was one of those problems that felt small until it was not. A missed sponsor email. A security report that sat unread. A handoff that went badly because credentials were in one person's LINE chat history.

All of that was avoidable. A domain we already owned, a forwarding service, five minutes of DNS configuration. That is it.

If your open source project is still relying on someone's personal email, fix it today. Not because it is a fun infrastructure task (it is not), but because your project's communication should not depend on one person remembering to check their Gmail.

It takes five minutes. Your contributors and your sponsors will thank you for it.

I am a community organizer myself, and we would like to help. We have a free upgrade program for open-source community organizers and project leaders. If this is you, we encourage you to apply.