DEV Community: KW Servers

How to Run a Mail Server on Ubuntu 24.04 with Postfix, Dovecot and OpenDKIM

KW Servers — Fri, 09 Oct 2026 06:44:57 +0000

Running your own mail server gives you control over your email infrastructure, dedicated IP address, sending limits, and mailbox data. But getting Postfix and Dovecot running is only part of the job.

The real challenge is making sure your emails are trusted by receiving mail servers.

Missing DNS records, incorrect reverse DNS (PTR), failed email authentication, and poor IP reputation can cause legitimate messages to land in spam—or get rejected entirely.

In this guide, we'll walk through how to set up a mail server on Ubuntu 24.04 LTS using Postfix, Dovecot, and OpenDKIM, then configure the authentication and reputation safeguards needed for reliable email delivery.

What You'll Learn

How to prepare an Ubuntu dedicated server for email hosting
How to configure Postfix for sending and receiving email
How to set up Dovecot for secure IMAP mailbox access
How to configure SPF, DKIM, and DMARC
Why reverse DNS (PTR) matters for email deliverability
How to enable TLS encryption for mail connections
How to test your configuration and prevent an open relay
How to warm up a new IP address and monitor sender reputation
How to troubleshoot common email delivery problems

Why Run a Mail Server on a Dedicated Server?

A dedicated server gives you greater control over your email environment, including its IP address, server configuration, DNS settings, and resource allocation.

Self-hosting can make sense if you need control over email data, want to host multiple mailboxes, or send transactional messages from your own applications.

However, self-hosting also means taking responsibility for security updates, spam prevention, backups, monitoring, and deliverability. For large marketing campaigns or businesses that need specialized delivery infrastructure, a dedicated email delivery service may be a better fit.

The Core Components

Before starting the setup, understand the role of each component:

Postfix: Handles SMTP mail transfer and message delivery.
Dovecot: Provides mailbox access through IMAP.
OpenDKIM: Adds cryptographic signatures to outgoing messages.
SPF: Identifies which servers are authorized to send email for your domain.
DKIM: Allows receiving servers to verify a message's cryptographic signature.
DMARC: Defines how receivers should handle messages that fail authentication checks and provides reporting.
Reverse DNS (PTR): Maps your server's IP address back to its hostname.

These components work together to help receiving mail servers verify your messages and assess your sending infrastructure.

The Setup Process

The complete tutorial covers the following steps:

Prepare Ubuntu 24.04 and configure the server hostname.
Create the required DNS records, including A, MX, SPF, and DMARC.
Obtain a TLS certificate for your mail hostname.
Install and configure Postfix.
Install Dovecot and configure secure mailbox access.
Generate a DKIM key and publish the public key in DNS.
Test email delivery, authentication results, and relay restrictions.
Monitor IP reputation and maintain the server over time.

How to Keep Your Mail Server's IP Reputation Clean

A functioning mail server does not automatically guarantee inbox placement. Reputation depends on technical configuration and how recipients interact with your messages.

Here are some essential practices:

1. Start with a clean IP address.

Check your IP against reputable blocklists before sending mail. An IP's previous history can affect deliverability.

2. Verify authentication and reverse DNS.

Make sure SPF, DKIM, and DMARC are configured correctly, and that your PTR record and forward DNS resolve consistently.

3. Warm up the IP gradually.

Avoid sudden sending spikes from a new IP. Begin with wanted messages to engaged recipients and increase volume cautiously while monitoring bounces, deferrals, and complaints.

4. Send only wanted email.

Use consent-based mailing lists, remove hard bounces, honor unsubscribe requests, and never purchase or scrape recipient lists.

5. Separate transactional and marketing email.

Where appropriate, use separate IP addresses or subdomains to reduce the risk of one stream affecting the other.

6. Monitor your reputation.

Use Google Postmaster Tools, Microsoft's sender monitoring and complaint-feedback services where eligible, DMARC reports, server logs, and blocklist checks.

7. Keep the server secure.

Use strong authentication, apply security updates, monitor failed logins, protect mail accounts, and ensure your server cannot be abused as an open relay.

Common Problems to Watch For

If messages are not being delivered, check the fundamentals first:

Outbound mail is stuck: Confirm that your hosting provider permits outbound TCP port 25.
Messages land in spam: Review SPF, DKIM, DMARC, reverse DNS, and sender reputation.
Mail is rejected for reverse DNS: Verify that your PTR record matches your mail hostname and that the hostname resolves to the correct IP.
DKIM fails: Check the selector, published DNS key, and OpenDKIM configuration.
SMTP authentication fails: Review your Postfix submission settings, Dovecot authentication socket, TLS configuration, and logs.

Always test your setup before using it for production email. Configuration details can vary by package version and server environment.

Read the Complete Step-by-Step Tutorial

This post covers the main concepts, but the full guide includes the installation commands, configuration examples, DNS records, testing procedures, troubleshooting steps, and maintenance checklist.

👉 Read the complete tutorial on KW Servers:

https://www.kwservers.com/tutorials/howto/run-mail-server-dedicated-server/

Final Thoughts

Running your own mail server can provide flexibility and control, but reliable email delivery requires more than installing software. Correct DNS, working authentication, TLS, a secure configuration, and responsible sending practices are all essential.

If you're planning to host email on a dedicated server, get those fundamentals right before increasing your sending volume.

Published by KW Servers, practical guides for dedicated server infrastructure and Linux administration.

How to Choose a Dedicated Server for 3D Rendering and Video Transcoding

KW Servers — Thu, 08 Oct 2026 09:51:54 +0000

3D rendering and video transcoding are sustained, resource-intensive workloads. A single Blender render, V-Ray scene, or batch of 4K video transcodes can keep server hardware running at high utilization for hours.

That makes server selection different from choosing infrastructure for a typical website or application.

The right configuration depends on whether your workload is primarily CPU-based, GPU-based, or focused on video encoding.

In this guide, we'll look at the most important hardware considerations when choosing a dedicated server for rendering and transcoding.

CPU vs GPU: Start With Your Workload

The first question is simple:

Does your software use the CPU, GPU, or both?

For CPU-based rendering, core count and memory capacity are major factors. Render engines can distribute frames or tiles across many CPU threads, making high-core-count processors particularly useful.

AMD EPYC processors are a strong option for CPU rendering because they provide high core counts and large memory capacity.

For lighter or mixed workloads, AMD Ryzen processors can also make sense because of their strong clock speeds and lower platform cost.

GPU rendering works differently.

Applications such as Blender Cycles, Octane, Redshift and V-Ray can use GPUs to accelerate rendering. In these workloads, GPU compute performance and VRAM capacity become critical.

Why VRAM matters

Your scene needs to fit into available GPU memory.

A faster GPU with insufficient VRAM may not be useful if the scene exceeds its memory capacity.

For example, a scene requiring around 40 GB of GPU memory cannot comfortably run on a 24 GB graphics card simply because the GPU is faster.

When selecting a GPU server, check:

VRAM capacity
CUDA or OptiX support for NVIDIA workloads
HIP support for compatible AMD workloads
Renderer compatibility
Multi-GPU scaling

Multiple GPUs can provide significant rendering performance improvements when the workload scales efficiently across cards.

How Much RAM Does a Rendering Server Need?

RAM requirements depend heavily on scene complexity.

A simple starting point is:

Workload	Suggested RAM
Light to medium rendering	64 GB
Heavy production scenes	128–256 GB
Large VFX or simulation workloads	512 GB+

Large textures, simulations, geometry and complex scenes can consume substantial memory.

The important rule is to size the server around your largest production workload, rather than your average project.

Why NVMe Storage Matters

Rendering and transcoding can involve constant reads and writes.

Render servers may repeatedly access:

Project files
Textures
Assets
Simulation caches
Temporary files
Frame sequences

NVMe storage provides high throughput and low latency for active workloads.

A practical architecture is to keep active projects and working data on NVMe while using larger HDD storage for archives and completed projects.

Dedicated Servers for Video Transcoding

Video transcoding converts media between codecs, resolutions and bitrates.

A typical video platform may take a high-quality source file and generate several output versions for an adaptive bitrate ladder used by HLS or DASH.

There are two main approaches to encoding.

CPU Encoding

Common CPU-based encoders include:

x264
x265
SVT-AV1

CPU encoding can provide excellent quality and is particularly useful for quality-focused or batch-oriented workflows.

The downside is that encoding can be significantly slower, especially when using slower quality presets.

GPU Hardware Encoding

Modern GPUs can include dedicated video encoding hardware.

For example, NVIDIA NVENC can encode video using dedicated hardware rather than relying entirely on the GPU's general compute resources.

GPU encoding is useful for:

Live streaming
High-volume transcoding
Fast turnaround
Multiple parallel streams

However, don't assume every GPU is suitable for video encoding.

Before purchasing a server, verify:

Hardware encoder availability
H.264 support
HEVC support
AV1 support
Concurrent encoding/session capabilities
Compatibility with your FFmpeg workflow

CPU Encoding vs GPU Encoding

Factor	CPU Encoding	GPU Hardware Encoding
Encoding speed	Lower	Higher
Quality efficiency	Excellent	Good and improving
Parallel workloads	CPU-dependent	Encoder-dependent
Live streaming	Possible	Excellent fit
Large VOD libraries	Excellent	Excellent for throughput
Hardware requirement	High CPU core count	Supported GPU

Many production environments use both approaches.

For example, GPU encoding can handle live streams and fast-turnaround workloads, while CPU encoding can be used for quality-focused VOD processing.

Don't Ignore Network Bandwidth

A powerful rendering or transcoding server can still become a bottleneck if the network connection is too small.

For streaming workloads, a basic planning formula is:

Concurrent viewers ≈ (port speed × 0.8) ÷ average bitrate per viewer

The 0.8 factor leaves approximately 20% headroom.

For example, using approximately 6 Mbps per 1080p viewer:

Port	Approx. 1080p viewers
1 Gbps	130
10 Gbps	1,300
20 Gbps	2,600
40 Gbps	5,300

These are planning estimates rather than guaranteed capacities.

Actual capacity depends on your bitrate ladder, CDN configuration, traffic patterns and application architecture.

For larger streaming platforms, 10 Gbps or higher connectivity can become important.

Example Dedicated Server Configurations

Here are some starting points for different workloads:

Freelance 3D Artist

8–16 CPU cores
1 GPU with 16–24 GB VRAM
64 GB RAM
1–2 TB NVMe
1 Gbps network

Animation Render Node

64+ CPU cores
Optional GPU
256 GB RAM
2–4 TB NVMe
Additional HDD archive storage
1–10 Gbps network

Multi-GPU Render Server

16–32 CPU cores
2–4 GPUs
128–256 GB RAM
2 TB+ NVMe
1–10 Gbps network

Video Transcoding Server

32–64 CPU cores
NVENC-capable GPU if required
64–128 GB RAM
4 TB+ NVMe
10 Gbps+ network

Live Streaming Server

16–32 CPU cores
NVENC-capable GPU
32–64 GB RAM
1 TB NVMe
10 Gbps+ network
DDoS protection

These are starting points. Always benchmark the actual application and workload before deploying large-scale infrastructure.

Dedicated Server vs Cloud vs VPS

Each infrastructure model has a different use case.

Factor	Dedicated Server	Cloud	VPS
Performance consistency	High	Depends on instance	Variable
GPU access	Direct	Available on selected instances	Limited
24/7 workload cost	Often attractive	Can become expensive	Lower
Burst capacity	Limited	Excellent	Limited
Hardware control	High	Provider-dependent	Limited
Best use	Sustained workloads	Short projects and bursts	Testing and lighter workloads

For workloads running most days, dedicated hardware can provide predictable performance and monthly costs.

For occasional rendering jobs or temporary capacity requirements, cloud infrastructure can be more flexible.

A hybrid model is also possible: maintain baseline capacity on dedicated servers and use cloud resources for temporary demand spikes.

How to Choose the Right Server

Before ordering a server, answer these questions:

Does my application primarily use CPU or GPU?
How much VRAM does my largest scene require?
How much system RAM does my workload need?
Which codecs and resolutions do I need to process?
How many simultaneous video streams will I handle?
How much outbound bandwidth will I need?
Where are my users located?
Do I need DDoS protection?
Do I need NVMe for active project data?
Will the workload run continuously or only occasionally?

These questions are more useful than choosing a server based only on CPU or GPU model names.

Final Thoughts

There is no single "best" dedicated server for every rendering or transcoding workload.

CPU rendering benefits from high core counts and sufficient RAM. GPU rendering depends heavily on GPU compute performance and VRAM. Video transcoding requires the right balance between CPU resources, hardware encoders, storage and network capacity.

The best approach is to start with your actual workload, identify its bottleneck, and then choose hardware around that requirement.

For a deeper breakdown of CPU, GPU, RAM, NVMe, networking, server sizing and workload-specific configurations, see the complete guide:

Dedicated Server for 3D Rendering and Video Transcoding: The 2026 Buyer's Guide

You can also explore more dedicated server infrastructure and technical guides from KW Servers:

https://www.kwservers.com/