메일 서버를 직접 호스팅하기
셀프 호스팅이나 데이터 주권 커뮤니티에서 며칠만 지내 보면 늘 등장하는 조언이 하나 있다.
무엇이든 직접 호스팅할 수 있지만 이메일 서버만큼은 안 된다!
그런 말이 나오는 이유는 이해한다. 차단 목록과 메일 전송 문제를 둘러싼 끔찍한 경험담이 많기 때문이다. 하지만 2026년인 지금은 실제로 가능하며, 심지어 집에서도 호스팅할 수 있다는 사실을 보여주고 싶다. 이메일은 애초에 개방형 시스템으로 설계됐다. 소수의 대기업이 우리의 모든 메일을 보유하고, 그 과정에서 인터넷이 점점 중앙화되는 현실을 당연하게 받아들여서는 안 된다.
내가 운영하는 소규모 MSP 회사는 개인과 기업이 Gmail과 Microsoft에서 벗어나 다른 클라우드 서비스나 셀프 호스팅 솔루션으로 이전하도록 매일 돕고 있다. 말뿐이어서는 안 된다고 생각해 나도 Google Workspace를 떠나기로 했다.
집에서 호스팅할까, VPS를 사용할까?
메일 서버까지 직접 운영하려는 소수의 셀프 호스팅 사용자도 다시 두 부류로 나뉜다. 집에서 메일 서버를 운영할 만큼 과감한 사람과 VPS만 사용하려는 사람이다. 일반적으로는 VPS를 권하지만, 가정용 인터넷이 다음 조건을 충족한다면 집에서도 메일 서버를 운영할 수 있다.
[ ] 고정 IPv4 주소(차단 목록에 올라 있지 않은지 확인)
[ ] CGNAT 뒤에 있지 않을 것
[ ] IP의 PTR 레코드를 변경할 수 있을 것(일반적으로 ISP 고객 지원을 통해 변경)
[ ] 일반적인 메일 서버 포트(
25,143,465,587,993)를 열 수 있을 것
모든 항목을 확인했다면 집에서 호스팅할 준비가 된 것이다.
하지만 인터넷이 끊기면 어떻게 하나? 모뎀이 다운되면 수신 메일을 잃지 않을까?
장애가 얼마나 오래 지속되는지에 따라 다르지만, 일반적으로는 잃지 않는다. 이메일은 복원력이 매우 높은 시스템이다. 메일 서버가 다운되면 발신 측에서 다시 전송을 시도한다. 초기 인터넷에서는 장애가 자주 발생했기 때문이다.
하루 중 인터넷이 끊기는 시간이 40% 미만이라면 여전히 문제없이 작동한다.
어떤 메일 서버 소프트웨어를 사용해야 할까?
필요에 따라 달라진다. 여러 메일 서버 솔루션이 있으며 호스팅 방식도 제각각이다.
좋은 출발점은 docker-mailserver다. 합리적인 기본 설정을 갖춘 완전한 메일 서버 제품군으로, Docker를 이용해 배포할 수 있다.
다른 선택지도 있다.
모든 것을 직접 구성하고 싶은 순수주의자라면 서버 전체를 직접 설정할 수도 있다.
내 메일은 오랫동안 레거시 환경 때문에 유지해 온 ISPConfig Server에 있다. 지금 처음부터 메일 서버를 구축한다면 docker-mailserver를 선택할 것이다.
도메인은 어떻게 설정해야 할까?
IP와 마찬가지로 도메인이 스팸 목록에 올라 있는지 확인해야 한다. 메일 전송 문제를 피하려면 DNS 레코드도 몇 가지 설정해야 한다.
메일 서버 소프트웨어가 대부분 이 과정을 안내하겠지만, 빠짐없이 정리하면 다음 레코드가 필요하다.
SPF - Sender Policy Framework는 어떤 서버가 해당 도메인으로 메일을 보낼 수 있는지 정의한다. 일반적으로
v=spf1 mx a ~all정도면 충분하다.DKIM - 이메일 서버가 보내는 모든 메일의 헤더에 추가하는 암호화 서명이다. 도메인에 특정 레코드를 등록해야 하며, 레코드 이름과 값은 메일 서버에서 알려 준다. 일반적으로
v=DKIM1; t=s; h=sha256; p=MIGf[..]B;같은 형태다.DMARC - SPF와 DKIM을 확장하는 레코드로, 다른 사람이 해당 도메인을 사칭해 이메일을 보내는 것을 막는다. 어떤 값을 넣어야 할지 모르겠다면 DMARC 생성기를 사용하면 된다.
MX - 다른 메일 서버가 해당 도메인의 이메일을 어디로 전달해야 하는지 알려 주는 레코드다. 일반적으로 IP를 가리키는
mail.yourdomain.comA 레코드를 만든 뒤, MX 레코드에는 우선순위 10과 값mail.yourdomain.com을 입력한다.
앞서 언급했듯 메일 서버가 사용하는 IP 주소에는 PTR 레코드도 있어야 한다. 이 레코드는 ISP나 VPS 제공업체만 설정할 수 있다. 일반적인 DNS 조회와 반대로 서버 IP를 도메인으로 변환하며, 메일 서버에서 사용하는 호스트 이름(예: mail.yourdomain.com)을 가리켜야 한다.
일부 메일 서버는 자동 서비스 검색을 위해 몇 가지 레코드를 더 추가하도록 권장하지만, 위 항목이 운영을 시작하는 데 필요한 핵심 설정이다.
도메인과 서버 설정을 마쳤다면 https://www.mail-tester.com/에서 메일 전송을 테스트해 보기를 강력히 권한다. 모든 레코드가 올바른지, 서버가 정상적으로 동작하는지 확인해 주는 도구다. 나도 이 도구의 도움을 여러 번 받았다.
스팸은 어떻게 막을까?
이제 재미있는 부분이다. 과거에는 스팸이 셀프 호스팅 메일 서버의 가장 큰 문제였다. 웹 공간이나 도메인을 구매하면 보통 무료로 제공되던 셀프 호스팅 또는 외부 호스팅 웹메일을 사람들이 떠난 가장 큰 이유도 스팸이었다고 생각한다.
오픈소스 스팸 방지 솔루션은 IP 차단 목록, 도메인 목록, Spamhaus 같은 외부 스팸 방지 서비스, 키워드 검색에 의존했다. 모두 효과가 떨어져 매일 받은편지함이 스팸으로 가득 찼다.
스팸을 피하려면 매일 수백만 고객의 메일을 처리해 스팸을 판별할 수 있는 Gmail이나 다른 대형 클라우드 사업자를 사용해야 한다는 말이 널리 퍼져 있었다.
하지만 지난 2년 사이 상황이 달라졌다. 셀프 호스팅 사용자의 스팸 문제를 해결할 방법이 생겼고, 매일 스팸에 파묻히지 않으면서 다시 자체 메일 서버를 운영할 수 있게 됐다.
로컬 LLM으로 스팸 차단하기
내가 선택한 셀프 호스팅 스팸 방지 서비스는 rspamd다. 다른 스팸 방지 시스템처럼 차단 목록, IP 검사, DNS 검사, 키워드 탐지 기능을 제공하지만, 내 스팸 문제를 완전히 해결해 준 플러그인이 하나 있다. 바로 GPT 플러그인이다.
이 작은 플러그인은 대규모 언어 모델로 이메일을 분류해 스팸인지 판별한다.
LLM이 스팸 메일을 분류하는 모습을 온종일 지켜봐도 재미있다.
셀프 호스팅을 선택하는 이유에는 개인정보 보호도 있다. 외부 LLM API에 개인 이메일을 모두 보내 분석하게 하는 것은 앞뒤가 맞지 않는다. 이때 로컬 모델을 활용할 수 있다.
이메일 분류에는 Gemma 4 12B QAT를 선택했다. GPU나 CPU에서 실행할 수 있고 RAM 또는 VRAM이 7GB만 있어도 구동된다. 성능이 뛰어난 다국어 모델이라 이 프로젝트에 잘 맞는다.
로컬 LLM을 한 번도 설정해 본 적이 없다면 Windows, Linux, Mac에서 사용할 수 있는 Unsloth의 이 가이드를 권한다. 간단히 말해 Linux나 MacOS에서는 curl -LsSf https://llama.app/install.sh | sh를 실행하고, Windows에서는 winget install llama.cpp를 실행하면 된다.
설치가 끝나면 llama serve -hf unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL --reasoning off -fa on -c 16000 --temp 0.7을 실행해 LLM을 외부에 제공할 수 있다. 그런 다음 브라우저에서 http://localhost:8080에 접속하면 채팅 인터페이스가 나타난다.
이것이 나만의 로컬 AI다. 여기서 직접 대화할 수도 있지만, 우리는 모든 수신 메일을 판정하도록 rspamd 인스턴스에 연결할 것이다.
정상적으로 실행됐다면 이제 rspamd가 로컬 LLM으로 이메일을 판정하도록 설정하면 된다. 예를 들어 내 메일 서버의 /etc/rspamd/local.d/gpt.conf는 다음과 같다.
allow_ham = true;
allow_passthrough = true;
enabled = true;
type = "openai";
url = "http://192.168.1.5/v1";
model = "unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL";
api_key = "this-is-ignored-on-llama.cpp";
max_tokens = 100;
temperature = 0.1;
# if your llm server doesn't have a GPU, you might want to increase the timeout
timeout = 30.0;
# Parse LLM reply as JSON (module expects key "probability", not "spam")
json = true;
prompt = "You are an expert email spam classifier. Analyze the following email headers, subject, and body. Respond with a JSON object containing two keys: 'probability' (a floating point number between 0.0 and 1.0 indicating spam probability) and 'reason' (a short sentence explaining why). Output only the raw JSON object, no markdown code fences.";
# Per-recipient conversation context: keeps a compact digest of recent mail
# (labels, top senders, 512-char summaries) in redis and injects it into the
# LLM prompt once 5+ messages are collected, so classification can use the
# recipient's mail history. Local feature, redis-backed, no external calls.
context {
enabled = true;
level = "user"; # scope digest per recipient mailbox
min_messages = 5; # warm-up before injection starts
message_ttl = 1209600; # 14d message digests
ttl = 2592000; # 30d redis key lifetime
}
이 설정만으로 Gmail급 로컬 스팸 방지 엔진을 만들 수 있다. 수신 메일을 LLM에 보내 평가하며, 스팸이라면 다음과 비슷하게 응답한다.
{
"probability": 0.85,
"reason": "The email uses fear-based marketing tactics, unsolicited commercial content for a product (window cleaning robot), and contains a suspicious international Punycode URL."
}정상 메일에는 다음과 같이 응답한다.
{
"probability": 0.1,
"reason": "The content appears to be a technical test message regarding DNS resolution with no suspicious links or promotional language."
}스팸 판정 확인하기
Rspamd에는 그래프와 데이터를 보여 주는 웹 인터페이스도 포함돼 있다. 이메일을 붙여 넣어 시스템이 어떻게 분류하는지도 확인할 수 있다.
어떤 메일 클라이언트를 사용해야 할까?
Google Workspace에서 셀프 호스팅 메일로 옮길 때 가장 걱정한 부분 중 하나가 UI였다. Gmail 외에는 Outlook만 알고 있었지만, 선택권이 있다면 기업 환경 밖에서 Outlook을 사용할 이유는 없다.
노트북과 PC에서는 Outlook의 오픈소스 경쟁 제품 가운데 기능이 가장 풍부한 Thunderbird를 사용한다. 필요한 기능을 모두 갖췄고 Android 모바일 앱도 제공한다. 검색 기능도 충분히 쓸 만하며 지난 3년 동안 문제가 없었다.
웹메일을 선호한다면 다음과 같은 선택지가 있다.
유지보수는 어떻게 해야 할까?
앞서 소개한 docker-mailserver 같은 최신 메일 서버 솔루션은 보안 패치를 고려해 만들어졌으며, 일반적으로 운영 환경을 망가뜨리지 않는 자동 업데이트 기능을 제공한다. 하지만 모든 셀프 호스팅 솔루션이 그렇듯 데이터를 직접 통제하는 만큼 직접 책임져야 한다.
백업, 복구, 원격 접근, 업데이트를 모두 고려해야 한다. 최소한 백업이라도 갖추지 않으면 모든 데이터를 잃을 수 있다. 확실한 백업 계획을 세우고 복구 절차도 적어도 한 번은 테스트해야 한다.
결론
직접 운영할 수 있고 실제로도 잘 작동한다. 서버가 잠시 다운돼도 괜찮다. 데이터 주권을 중요하게 생각한다면 한 번 시도해 볼 만하다.
source https://blog.haschek.at/2026/you-should-selfhost-your-mail.html
HN에서는 메일 서버를 직접 운영할 수 있느냐보다, 발송 신뢰성까지 개인이 책임질 만한 가치가 있느냐를 두고 판단이 갈렸다. 오랫동안 별문제 없이 운영한 사례도 적지 않았다. 그러나 설정을 제대로 마쳐도 보낸 메일이 스팸함으로 가거나 아무 통보 없이 사라졌다는 경험이 반복됐다. 수신과 스팸 차단은 비교적 관리할 수 있지만, 상대 서버가 메일을 받아 주는지는 별개의 문제라는 지적이다.
안정적으로 운영한 사람들은 평판이 깨끗한 고정 IP를 오래 유지하고, 역방향 DNS와 SPF·DKIM·DMARC를 갖췄다. 보안 패치와 인증서 갱신, 모니터링도 꾸준히 맡았다. 통합 패키지는 초기 설정 부담을 줄여 주지만 IP 평판과 대형 사업자의 필터링까지 해결하지는 못한다. 특히 주거용 회선이나 이전 사용자가 평판을 망친 VPS 주소는 올바른 설정만으로 만회하기 어렵다는 경험이 여러 차례 나왔다.
현실적인 절충안으로는 수신 서버만 직접 운영하고 발송은 외부 SMTP 릴레이에 맡기는 구성이 자주 제시됐다. 받은 메일과 계정, 별칭은 직접 관리하면서 발송 실패 위험은 전문 사업자에게 넘기는 방식이다. 학습이 목적이거나 가족 등 여러 사용자와 많은 별칭이 필요하다면 직접 운영의 수고를 감수할 이유가 있다. 고유 도메인과 서비스 이전의 자유만 원한다면, 도메인은 직접 소유하고 메일 운영은 전문 업체에 맡기는 편이 간단하다.
결국 설치 가능 여부보다 중요한 것은 장애의 대가다. 중요한 메일의 지연이나 누락을 감당할 수 있는지, IP 평판이 나빠졌을 때 즉시 우회할 수 있는지, 문제가 생긴 순간 직접 대응할 시간과 의지가 있는지부터 따져야 한다. 프라이버시도 상대 서버와 전송 경로까지 포함하면 완전한 통제를 기대하기 어렵다. 따라서 무엇을 직접 보관하고 어느 구간을 외부에 맡길지 구체적으로 정하는 것이 현실적인 판단 기준이다.
