How to Set Up Email Forwarding on Your Developer Server

Why Email Forwarding Matters for Developer Hosting

You've just spun up a new Linux server to host your side project. Your domain is live. Traffic is coming in. Then a user tries to contact you via your domain's contact form, and the email vanishes into the void.

This happens because email is hard. Setting up a full mail server (Postfix, Dovecot, SpamAssassin) takes hours, requires constant maintenance, and can land you on spam blacklists if you misconfigure DKIM or SPF. Most developers don't need to receive mail on their server—they just need to forward it somewhere they actually check.

Email forwarding is the pragmatic middle ground. You configure your server to accept mail for your domain, then silently redirect it to your personal Gmail, Outlook, or work inbox. No mail queue to monitor. No spam filtering headaches. Just working email in five minutes.

The Two Approaches: Catch-All vs. Specific Aliases

Before we get technical, understand what you're choosing:

• Catch-all forwarding: Any email sent to anything@yourdomain.com gets forwarded to your inbox. Simple, but risky—you'll catch typos and spam addressed to nonexistent addresses.
• Specific alias forwarding: You define exact addresses (info@, contact@, noreply@) and only those get forwarded. More control, slightly more setup.

For a side project, start with specific aliases. You can always add a catch-all later if you're confident in your domain's reputation.

Step 1: Install Postfix (the Minimal Way)

Postfix is a mail transfer agent (MTA)—it accepts incoming mail and decides what to do with it. You don't need it to store mail; you just need it to forward it.

On Ubuntu/Debian:

sudo apt update
sudo apt install postfix mailutils

During installation, select "Internet Site" when prompted for the configuration type. Set your hostname to your domain (e.g., myproject.com).

On CentOS/RHEL:

sudo yum install postfix mailutils
sudo systemctl enable postfix
sudo systemctl start postfix

Verify Postfix is running:

sudo systemctl status postfix

Step 2: Configure DNS Records (MX and SPF)

Your server needs to tell the world it handles mail for your domain. You do this with DNS records.

Add an MX record:

• Type: MX
• Name: @ (or your domain root)
• Value: mail.yourdomain.com (or your server's hostname)
• Priority: 10

Add an A record (if not already present):

• Type: A
• Name: mail
• Value: Your server's IP address

Add an SPF record:

• Type: TXT
• Name: @
• Value: v=spf1 mx ~all

Wait 15–30 minutes for DNS to propagate. You can check with:

dig yourdomain.com MX
dig mail.yourdomain.com A

Step 3: Set Up Email Aliases

Now tell Postfix where to forward mail. Edit the virtual aliases file:

sudo nano /etc/postfix/virtual

Add your forwarding rules. Each line maps a local address to your real email:

info@yourdomain.com     yourname@gmail.com
contact@yourdomain.com  yourname@gmail.com
support@yourdomain.com  yourname@gmail.com
@yourdomain.com         yourname@gmail.com

The last line is a catch-all for anything not explicitly listed. You can omit it if you prefer to only forward specific addresses.

Save and exit (Ctrl+X, then Y in nano).

Now hash the virtual file so Postfix can read it quickly:

sudo postmap /etc/postfix/virtual

This creates a compiled database at /etc/postfix/virtual.db.

Step 4: Update Postfix Configuration

Tell Postfix to use your virtual aliases file. Edit the main configuration:

sudo nano /etc/postfix/main.cf

Find or add these lines:

virtual_alias_domains = yourdomain.com
virtual_alias_maps = hash:/etc/postfix/virtual

If your domain is already in mydestination, remove it from there—virtual aliases won't work if Postfix treats the domain as local.

Reload Postfix:

sudo postfix reload

Check for configuration errors:

sudo postfix check

If you see no output, you're good. If there are errors, they'll print here.

Step 5: Test Your Setup

Send a test email to one of your aliases. From Gmail, another email account, or a terminal:

echo "Test message" | mail -s "Testing email forwarding" info@yourdomain.com

Check your inbox in 30 seconds to 2 minutes. If it arrives, you're done.

If it doesn't arrive, check Postfix logs:

sudo tail -f /var/log/mail.log

Common issues:

• "Relay access denied": Postfix is rejecting the forward. Verify your virtual aliases are mapped correctly and Postfix was reloaded.
• "Unknown user": The domain isn't recognized. Check that virtual_alias_domains is set in main.cf.
• Email lands in spam: Your SPF record is missing or incorrect. Add it to your DNS.

Bonus: Add DKIM for Better Deliverability

SPF helps, but DKIM (DomainKeys Identified Mail) is even better. It cryptographically signs outgoing mail so Gmail and other providers trust it more.

Install opendkim:

sudo apt install opendkim opendkim-tools

Generate keys:

sudo opendkim-genkey -D /etc/dkimkeys -d yourdomain.com -s default

Add the public key to your DNS as a TXT record (the content is in /etc/dkimkeys/default.txt). Then configure Postfix to use it—but this gets complex fast. If you're forwarding mail only, SPF is usually enough.

If you're using a service like Vibesies that provisions your server with email already configured, this step is done for you. Otherwise, DKIM is worth 30 minutes of effort if you're sending transactional mail from your domain.

Monitoring and Maintenance

Once it's live, you need almost nothing:

• Check logs weekly: sudo tail -20 /var/log/mail.log to spot delivery failures.
• Update aliases as needed: Edit /etc/postfix/virtual, run sudo postmap /etc/postfix/virtual, then sudo postfix reload.
• Monitor disk space: Postfix queues mail briefly if your forward fails. A full disk can cause backups. Check with df -h.
• Set up log rotation: Postfix logs can grow large. Most systems handle this automatically via logrotate, but verify with ls -la /etc/logrotate.d/ | grep postfix.

When Email Forwarding Isn't Enough

Email forwarding works great for contact forms and notifications. But if you need to:

• Send mail from your domain in code (transactional emails, newsletters)
• Receive and store mail on the server
• Support multiple team members checking the same inbox

…then you need a full mail server or an external service like AWS SES, SendGrid, or Mailgun. These handle authentication, bounce management, and compliance for you—and they're cheaper than running your own if you're sending more than a few hundred emails per month.

For example, if you're using Vibesies's managed Linux VPS setup, SES is pre-configured with DKIM/SPF, so you can send transactional mail without touching Postfix at all.

Wrapping Up: Simple Email for Developers

Email forwarding on your developer server takes 15 minutes and removes a major operational headache. You get a working contact address for your domain without the complexity of managing a mail queue, spam filtering, or user accounts.

The key steps: install Postfix, add DNS records (MX, A, SPF), define your aliases, and test. After that, it just works. Your users' messages arrive in your inbox, and you can focus on shipping code instead of debugging mail delivery.

If you'd rather skip the setup entirely, consider a managed hosting provider that includes email forwarding in the baseline—but if you're already running your own managed Linux VPS or cloud server, this is the fastest path to working email.