
메일 서버를 직접 호스팅(Self-host)해야 하는 이유
요약
데이터 주권 확보를 위해 메일 서버를 직접 호스팅하는 방법과 필요 조건을 설명합니다. 가정용 인터넷 환경에서의 구축 가능성과 Docker 기반의 솔루션 등 실질적인 가이드를 제공합니다.
핵심 포인트
- 데이터 주권과 탈중앙화를 위한 셀프 호스팅의 가치
- 가정 내 호스팅을 위한 고정 IP 및 포트 개방 등 필수 조건
- 인터넷 장애 시에도 이메일 프로토콜의 재시도 메커니즘 덕분에 안정성 유지 가능
- docker-mailserver, Stalwart, Mailcow 등 다양한 소프트웨어 솔루션 추천
- SPF 등 올바른 메일 전달을 위한 DNS 레코드 설정의 중요성
셀프 호스팅(self-hosting)이나 데이터 주권(data-sovereignty) 커뮤니티에서 며칠 동안 온라인 활동을 해보셨다면, 항상 등장하는 조언이 하나 있습니다.
무엇이든 셀프 호스팅할 수 있지만, 메일 서버만은 안 됩니다!
블랙리스트(blocklists)와 메일 전달 문제에 관한 무시무시한 이야기들이 있기 때문에 그들이 왜 그렇게 말하는지는 이해합니다. 하지만 오늘 저는 2026년 현재 이것이 실제로 가능하다는 것을 보여드리고 싶으며, 심지어 집에서도 호스팅할 수 있을지도 모릅니다! 설계상 이메일은 개방형 시스템(open system)이며, 몇몇 거대 기업들이 우리의 모든 메일을 보유하고 그 과정에서 인터넷이 덜 탈중앙화(decentralized)되는 상황을 우리는 받아들여서는 안 됩니다.
저의 작은 MSP(Managed Service Provider) 회사는 사람들이나 기업들이 Gmail과 Microsoft에서 클라우드 대안이나 셀프 호스팅 솔루션으로 전환하는 것을 매일 돕고 있기 때문에, 저 또한 말한 대로 실천하기 위해 Google Workspace에서 벗어나기로 했습니다.
집에서 할 것인가, VPS에서 할 것인가?
메일 서버를 셀프 호스팅할 의사가 있는 소수의 셀프 호스터(self-hosters)들은 다시 집에서 메일 서버를 호스팅할 용기가 있는 사람들과 VPS(Virtual Private Server)만을 사용하려는 사람들로 나뉩니다. 보통은 VPS 사용을 권장하겠지만, 만약 여러분의 가정용 인터넷이 다음 조건들을 충족한다면, 100% 집에서 직접 메일 서버를 호스팅할 수 있습니다:
- 고정 IPv4 주소 (블랙리스트에 등록되어 있지 않은지 확인하세요)
- CGNAT(Carrier-Grade NAT) 뒤에 있지 않을 것
- IP의 PTR 레코드(PTR record)를 변경할 수 있는 능력 (보통 ISP의 지원을 통해 가능)
- 일반적인 메일 서버 포트(
25,143,465,587,993)를 개방할 수 있는 능력
이 모든 항목을 체크했다면, 집에서 호스팅할 준비가 되었습니다!
하지만 인터넷 장애는 어떡하죠? 모뎀이 다운되면 수신 메일을 놓치게 되지 않을까요?
장애가 얼마나 오래 지속되느냐에 따라 다르지만, 보통은: 아닙! 이메일은 매우 견고합니다. 즉, 메일 서버가 다운되어 있더라도 발신자는 메일 전달을 재시도할 것입니다. 초기 인터넷 시절에는 장애가 빈번했기 때문입니다.
어느 날 특정 시점에 인터넷이 끊겨 있는 시간이 40% 미만이라면, 여전히 잘 작동할 것입니다.
어떤 메일 서버 소프트웨어를 사용해야 할까요?
이는 정말로 여러분의 필요에 따라 달라집니다. 호스팅 방식이 서로 다른 여러 가지 메일 서버 (mailserver) 솔루션들이 존재합니다.
좋은 시작점은 합리적인 기본값(sane defaults)과 함께 Docker를 통해 배포할 수 있는 전체 메일 서버 제품군인 docker-mailserver가 될 것입니다.
하지만 다음과 같은 다른 솔루션들도 있습니다:
- Stalwart
- Mailcow
- 또는 만약 여러분이 순수주의자(purist)라면 서버 전체를 직접 설정할 수도 있습니다.
개인적으로 제 메일은 레거시(legacy) 문제로 인해 수년간 유지해 온 ISPConfig 서버에 있습니다. 만약 제가 오늘 처음부터 메일 서버를 구축한다면 docker-mailserver를 선택할 것입니다.
내 도메인은 어떻게 해야 하나요?
IP와 마찬가지로, 여러분의 도메인이 스팸 리스트(spam list)에 등록되어 있는지 확인해야 하지만, 배달 문제에 직면하지 않으려면 몇 가지 DNS 레코드(DNS records)도 필요합니다.
사용 중인 메일 서버 소프트웨어가 아마 이 모든 과정을 안내해 주겠지만, 완전성을 위해 다음과 같은 레코드들이 필요합니다:
-
SPF - 발신자 정책 프레임워크 (Sender Policy framework)는 어떤 서버가 여러분의 도메인(Domain)에서 메일을 보낼 수 있는지 정의합니다. 보통 다음과 같은 형식이면 충분합니다:
v=spf1 mx a ~all -
DKIM - 이것은 이메일 서버가 발송되는 모든 메일의 헤더(headers)에 추가하는 암호화 서명(cryptographic signature)입니다. 여러분의 도메인에 특정 항목이 있어야 하지만, 이름과 값은 메일 서버를 통해 전달됩니다. 보통 다음과 같이 보입니다:
v=DKIM1; t=s; h=sha256; p=MIGf[..]B; -
DMARC - 이 항목은 기본적으로 SPF와 DKIM의 확장이며, 여러분의 도메인에 대한 이메일 스푸핑(email spoofing)을 방지해야 합니다. 여기에 무엇을 넣어야 할지 확실하지 않다면, DMARC 생성기(DMARC generator)를 사용하세요.
-
MX - MX 레코드는 다른 메일 서버들에게 여러분의 도메인에 있는 이메일을 어디로 배달해야 하는지 알려줍니다. 보통 여러분의 IP를 가리키는
mail.yourdomain.com에 대한 A-레코드 (A-Record)를 만들고, MX 레코드의 값으로 우선순위(Priority) 10과mail.yourdomain.com을 입력합니다.
또한 앞서 언급했듯이, 메일 서버에 사용하는 IP 주소에는 PTR 레코드 (PTR Record)가 있어야 하며, 이는 ISP(인터넷 서비스 제공업체) 또는 VPS 제공업체를 통해서만 설정할 수 있습니다. 이는 서버의 IP가 도메인으로 해석되도록 허용하며 (보통은 그 반대 방향이지만), 반드시 메일 서버에 사용하는 호스트 이름(예: mail.yourdomain.com)을 나타내야 합니다.
일부 메일 서버는 자동 서비스 탐지를 위해 몇 가지 레코드를 더 추가할 것을 권장하기도 하지만, 위 설정들이 서비스를 시작하는 데 필요한 핵심 설정입니다.
도메인과 서버 설정을 마친 후에는 https://www.mail-tester.com/을 사용하여 메일 전송을 테스트해 보기를 강력히 권장합니다. 이 사이트는 모든 레코드가 올바른지, 그리고 서버가 의도한 대로 작동하는지 확인해 줍니다. 이 도구 덕분에 저는 많은 시간을 아낄 수 있었습니다.
스팸은 어떻게 하나요?
이제 재미있는 부분이 나옵니다! 스팸은 과거 셀프 호스팅 (Self-hosted) 메일 서버의 가장 큰 문제였습니다. 상황이 너무 심각해서, 사람들이 셀프 호스팅을 포기하거나 웹 공간 또는 도메인을 구매할 때 보통 무료로 제공되는 (외부) 호스팅 웹메일조차 사용하지 않게 된 가장 큰 이유라고 말할 수 있을 정도였습니다.
오픈 소스 스팸 방지 솔루션들은 IP 블랙리스트 (IP blacklists), 도메인 리스트 (domainlists), Spamhaus와 같은 외부 스팸 방지 서비스 또는 키워드 검색에 의존했습니다. 하지만 이들은 모두 매우 비효율적이었고, 그 결과 여러분의 편지함은 매일 다음과 같은 모습이 되곤 했습니다:

세간의 말에 따르면, 스팸을 피하고 싶다면 매일 수백만 명의 클라이언트 메일을 처리하며 스팸을 탐지할 수 있는 Gmail이나 다른 대형 클라우드 제공업체를 사용해야만 한다고 했습니다.
하지만 지난 2년 동안 무언가가 변했고, 이로 인해 셀프 호스팅 사용자들의 스팸 문제가 해결되었으며, 매일 스팸에 휩쓸리지 않고도 다시 우리만의 메일 서버를 호스팅할 수 있게 되었습니다:
스팸과 싸우기 위한 로컬 LLM (Local LLMs) 사용
제가 선택한 셀프 호스팅 스팸 방지 서비스는 rspamd입니다. 이 시스템은 블랙리스트, IP 체크, DNS 체크 및 키워드 감시를 수행하는 여타 스팸 방지 시스템과 동일하게 시작하지만, 제 스팸 문제를 완전히 해결해 준 특별한 플러그인이 하나 있습니다. 바로 GPT 플러그인입니다.
이 작은 플러그인을 사용하면 거대 언어 모델 (Large Language Model, LLM)을 사용하여 이메일을 분류하고, 해당 메일이 스팸인지 여부를 판단할 수 있습니다.

우리는 셀프 호스팅 (Self-hosting)을 하고 있으며 프라이버시를 위해서도 이 방식을 사용하기 때문에, 우리의 모든 개인적인 이메일을 분석하기 위해 외부 LLM API를 사용하는 것은 의미가 없습니다. 바로 이 지점에서 로컬 모델 (Local Model)이 필요합니다.
이메일 분류를 위해 제가 선택한 모델은 Gemma 4 12B QAT입니다. 이 모델은 GPU 또는 CPU에서 7GB 정도의 RAM 또는 VRAM만으로도 실행할 수 있으며, 이 프로젝트에 완벽하게 부합하는 매우 유능한 다국어 모델입니다.
로컬 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으로 이동하면 채팅 인터페이스가 나타날 것입니다.

이것이 작동하면, rspamd가 이메일을 판단할 때 로컬 LLM을 사용하도록 설정하기만 하면 됩니다. 예를 들어, 제 메일 서버의 /etc/rspamd/local.d/gpt.conf 설정은 다음과 같습니다.
allow_ham = true;
allow_passthrough = true;
enabled = true;
...
Gmail 수준의 로컬 안티스팸 (Antispam) 엔진을 갖추기 위해 필요한 것은 이것뿐입니다. 수신된 메일은 평가를 위해 LLM으로 전송되며, 스팸의 경우 다음과 같이 답변합니다.
{
"probability": 0.85,
"reason": "이 이메일은 공포 기반의 마케팅 전술, 제품(창문 청소 로봇)에 대한 요청되지 않은 상업적 콘텐츠를 사용하며, 의심스러운 국제 Punycode URL을 포함하고 있습니다."
...
}
정상적인 메일의 경우 다음과 같습니다.
{
"probability": 0.1,
"reason": "콘텐츠는 의심스러운 링크나 홍보 문구 없이 DNS 확인에 관한 기술적 테스트 메시지로 보입니다."
...
}
스팸 감시하기
스팸 감시하기
Rspamd는 몇 가지 그래프와 데이터를 보여주는 웹 인터페이스 (web interface)도 함께 제공하며, 메일을 붙여넣어 해당 메일이 어떻게 분류되었을지 확인할 수도 있습니다.
어떤 메일 클라이언트(mail client)를 사용해야 할까요?
Google Workspace에서 셀프 호스팅 (self-hosted) 메일로 전환할 때 가장 큰 걱정 중 하나는 UI였습니다. Gmail 외에는 Outlook만 알고 있었지만, 기업 환경이 아닌 이상 선택권이 있다면 누구도 Outlook을 사용해서는 안 됩니다.
제 노트북과 PC에서는 Outlook에 대응하는 가장 유능한 오픈 소스 (open-source) 경쟁자인 Thunderbird를 사용하고 있습니다. 필요한 모든 기능이 갖춰져 있으며, Android용 모바일 앱도 제공합니다. 검색 기능은 (충분히) 훌륭하며, 지난 3년 동안 사용하면서 아무런 문제가 없었습니다.
웹메일 (webmail) 방식을 더 선호하신다면 몇 가지 다른 옵션들도 있습니다.
유지보수는 어떻게 하나요?
앞서 언급한 docker-mailserver와 같은 오늘날의 메일 서버 솔루션들은 보안 패치 (security fixes)를 염두에 두고 구축되었으며, 일반적으로 운영 환경 (production)에서 문제를 일으키지 않는 자동 업데이트 (auto update) 기능을 갖추고 있습니다. 하지만 모든 셀프 호스팅 솔루션과 마찬가지로, 사용자가 제어권을 갖는 만큼 자신의 데이터에 대해서도 책임을 져야 합니다.
이는 또한 백업 (backups), 복구 (recovery), 원격 접속 (remote access) 및 업데이트와 같은 사항들을 고려해야 함을 의미하며, 최소한 백업이라도 되어 있지 않다면 모든 데이터를 잃을 수 있다는 뜻입니다. 제대로 된 백업 계획을 세우고, 최소한 한 번은 복구 테스트를 진행하십시오.
결론
충분히 가능하며, 매우 잘 작동합니다. 서버가 잠시 다운되더라도 큰 문제가 없으며, 데이터 주권 (data sovereignty)을 중요하게 생각한다면 아마도 한 번 시도해 볼 가치가 있습니다.
SSH를 사용하여 댓글을 남겨주세요! 정보
ssh selfhostmail@ssh.blog.haschek.at
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Posts의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기