# 2026년에는 이메일을 직접 호스팅할 수 있음 > Clean Markdown view of GeekNews topic #31767. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31767](https://news.hada.io/topic?id=31767) - GeekNews Markdown: [https://news.hada.io/topic/31767.md](https://news.hada.io/topic/31767.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-24T19:02:20+09:00 - Updated: 2026-07-24T19:02:20+09:00 - Original source: [blog.haschek.at](https://blog.haschek.at/2026/you-should-selfhost-your-mail.html) - Points: 2 - Comments: 1 ## Topic Body - 이메일은 본래 **개방형 시스템**이며, 2026년에는 배달 문제와 스팸을 관리하면서 집이나 VPS에서 운영해 소수 대기업에 메일을 맡기지 않을 수 있음 - 가정에서 운영하려면 블록리스트에 없는 **고정 IPv4**, CGNAT 미사용, PTR 레코드 변경 권한, `25·143·465·587·993` 포트 개방이 필요하며, 조건이 맞지 않으면 VPS가 적합함 - **SPF·DKIM·DMARC·MX·PTR**를 올바르게 설정하고 mail-tester.com으로 배달 상태를 검사해야 하며, 짧은 인터넷 장애가 발생해도 발신 서버가 배달을 재시도함 - Rspamd의 **GPT 플러그인**과 로컬 `Gemma 4 12B QAT` 모델을 결합하면 외부 LLM API에 개인 메일을 보내지 않고도 스팸 확률과 판정 이유를 생성할 수 있음 - docker-mailserver와 Thunderbird·웹메일 클라이언트로 구축 장벽을 낮출 수 있지만, 운영자는 **백업·복구·원격 접근·업데이트**를 직접 책임지고 복구 절차를 최소 한 번 시험해야 함 --- ### 집과 VPS 중 선택 - 일반적으로는 **VPS**가 권장되지만, 가정 인터넷이 다음 조건을 모두 충족하면 집에서도 메일 서버를 운영할 수 있음 - [블록리스트](https://mxtoolbox.com/blacklists.aspx)에 등재되지 않은 고정 IPv4 주소 - CGNAT 뒤에 있지 않은 회선 - ISP 지원 등을 통해 IP의 **PTR 레코드**를 변경할 수 있는 권한 - 일반적인 메일 서버 포트 `25`, `143`, `465`, `587`, `993`을 열 수 있는 환경 - 서버가 잠시 내려가도 발신 측 메일 서버가 배달을 재시도하므로 곧바로 수신 메일을 잃지는 않음 - 하루 중 인터넷 중단 시간이 **40% 미만**이면 정상적으로 작동할 수 있음 ### 메일 서버 소프트웨어 - [docker-mailserver](https://github.com/docker-mailserver/docker-mailserver)는 합리적인 기본 설정을 갖춘 전체 메일 서버 제품군을 Docker로 배포할 수 있어 출발점으로 적합함 - 다른 선택지로 [Stalwart](https://stalw.art/), [Mailcow](https://github.com/mailcow/mailcow-dockerized), [Postfix·Dovecot·Rspamd를 직접 구성하는 방식](https://www.dchost.com/blog/en/i-built-my-own-mail-server-postfix-dovecot-rspamd-and-the-calm-path-to-deliverability-with-ip-warm%E2%80%91up/)이 있음 - 기존 메일은 레거시 사유로 수년간 [ISPConfig](https://www.ispconfig.org/)에서 운영 중이지만, 새로 구축한다면 **docker-mailserver**가 적합한 선택임 ### 도메인과 DNS 설정 - IP와 마찬가지로 도메인도 먼저 [스팸 블록리스트](https://mxtoolbox.com/blacklists.aspx) 등재 여부를 확인해야 함 - 정상적인 발신과 수신에는 다음 **DNS 레코드**가 필요함 - [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework): 도메인을 대신해 메일을 보낼 수 있는 서버를 지정하며, 일반적인 값으로 `v=spf1 mx a ~all`을 사용할 수 있음 - [DKIM](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail): 발송 메일 헤더에 암호학적 서명을 추가하며, 서버가 안내한 이름과 공개 키 값을 도메인에 등록함 - [DMARC](https://dmarc.org/): SPF와 DKIM을 확장해 도메인 위조를 방지하며, 값이 불확실하면 [DMARC 생성기](https://mxtoolbox.com/DMARCRecordGenerator.aspx)를 이용할 수 있음 - MX: 다른 서버가 메일을 배달할 위치를 지정함. `mail.yourdomain.com`의 A 레코드를 서버 IP로 연결하고 MX 우선순위 `10`의 값으로 해당 호스트명을 설정하는 방식이 일반적임 - **PTR 레코드**는 ISP나 VPS 제공자만 설정할 수 있으며, 서버 IP가 `mail.yourdomain.com` 같은 실제 메일 서버 호스트명으로 역방향 해석돼야 함 - 일부 서버는 자동 서비스 탐지용 레코드를 추가로 권장하지만, SPF·DKIM·DMARC·MX·PTR가 기본 구성임 - 구축 후 [mail-tester.com](https://www.mail-tester.com/)에서 레코드와 서버 동작, 메일 배달 상태를 검사하는 것이 권장됨 ### 로컬 LLM을 이용한 스팸 차단 - 기존 오픈소스 스팸 차단은 IP·도메인 블록리스트, Spamhaus 같은 외부 서비스, 키워드 검색에 의존했으며 효과가 낮아 자체 호스팅 이탈의 주요 원인이었음 - 최근 2년 동안 **로컬 LLM 분류**가 자체 호스팅 환경의 스팸 문제를 해결할 수 있는 선택지로 등장함 - [Rspamd](https://rspamd.com/)는 블록리스트, IP·DNS 검사, 키워드 탐지에 더해 [GPT 플러그인](https://docs.rspamd.com/modules/gpt/)으로 이메일의 스팸 여부를 LLM에 분류시킬 수 있음 - 개인 메일을 외부 LLM API로 보내는 대신 [Gemma 4 12B QAT](https://huggingface.co/unsloth/gemma-4-12B-it-qat-GGUF)를 로컬에서 실행함 - GPU나 CPU에서 실행할 수 있으며 최소 **7GB RAM 또는 VRAM**이 필요함 - 다국어를 지원해 이메일 분류에 활용할 수 있음 ### 로컬 모델 실행과 Rspamd 연결 - 로컬 LLM을 처음 구성한다면 Windows·Linux·macOS용 [Unsloth의 llama.cpp 가이드](https://unsloth.ai/docs/models/gemma-4/qat#llama.cpp-guide)를 참고할 수 있음 - Linux와 macOS에서는 다음 명령으로 `llama.cpp`를 설치함 ```bash curl -LsSf https://llama.app/install.sh | sh ``` - Windows에서는 다음 명령을 사용함 ```powershell winget install llama.cpp ``` - 모델 서버는 다음과 같이 실행하며, `localhost:8080`에서 채팅 인터페이스를 확인할 수 있음 ```bash llama serve -hf unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL --reasoning off -fa on -c 16000 --temp 0.7 ``` - Rspamd의 `/etc/rspamd/local.d/gpt.conf`에서 `type = "openai"`와 로컬 `/v1` 엔드포인트를 지정하면 **OpenAI 호환 인터페이스**로 모델을 연결할 수 있음 - 모델은 `unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL`로 설정함 - 최대 출력 토큰은 `100`, 온도는 `0.1`, 시간 제한은 `30초`로 구성함 - GPU가 없는 LLM 서버에서는 시간 제한을 늘릴 수 있음 - 응답은 JSON으로 해석하며 `spam`이 아닌 `probability` 키를 요구함 - 프롬프트는 헤더·제목·본문을 분석해 `0.0~1.0` 사이의 **스팸 확률**과 짧은 판정 이유만 JSON으로 반환하도록 지시함 - 수신자별 대화 맥락 기능은 Redis에 최근 메일의 레이블, 주요 발신자, 512자 요약을 저장하고 5개 이상이 모이면 분류 프롬프트에 포함함 - 범위는 수신자별 메일함인 `user` - 메시지 요약 보존 기간은 `14일`, Redis 키 수명은 `30일` - 외부 호출 없이 로컬에서 동작함 - 스팸 메일에는 공포 기반 마케팅, 원치 않는 상업 콘텐츠, 의심스러운 국제화 도메인 등을 근거로 높은 확률을 반환할 수 있음 - 정상적인 기술 테스트 메일에는 의심스러운 링크나 홍보 문구가 없다는 이유로 낮은 확률을 반환할 수 있음 - Rspamd의 **웹 인터페이스**에서는 그래프와 데이터를 확인하고, 메일을 붙여 넣어 예상 분류 결과를 시험할 수 있음 ### 메일 클라이언트 선택 - 데스크톱에서는 [Thunderbird](https://www.thunderbird.net/en-US/thunderbird/all/)가 Outlook을 대체할 수 있는 기능성 높은 오픈소스 클라이언트임 - 필요한 기본 기능과 충분한 검색 기능을 제공함 - [Android 앱](https://play.google.com/store/apps/details?id=net.thunderbird.android)도 제공함 - 3년간 사용하면서 문제가 없었음 - 웹메일이 필요하면 다음 선택지를 사용할 수 있음 - [MailFlow](https://mailflow.sh/) - [Kurrier](https://github.com/kurrier-org/kurrier) - [SnappyMail](https://snappymail.eu/) - [Roundcube](https://roundcube.net/) ### 유지보수와 운영 책임 - docker-mailserver 같은 현대적 메일 서버 솔루션은 **보안 수정**과 프로덕션 환경을 깨뜨리지 않는 자동 업데이트를 고려해 설계됨 - 자체 호스팅은 데이터 통제권을 제공하는 대신 백업, 복구, 원격 접근, 업데이트 책임을 운영자에게 돌려줌 - 백업이 없으면 모든 데이터를 잃을 수 있으므로 충분한 **백업 계획**을 마련하고 복구 절차를 최소 한 번 시험해야 함 - 조건과 운영 책임을 감당할 수 있다면 짧은 서버 중단에도 메일을 운영할 수 있으며, 데이터 주권을 중시하는 사용자는 자체 호스팅을 시도할 수 있음 ## Comments ### Comment 62332 - Author: neo - Created: 2026-07-24T19:02:21+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/x3x2aw/you_should_selfhost_your_mail_2026) * **Fastmail**을 쓰면서 골칫거리를 모두 피하고 있음. 어떤 골칫거리를 피하고 있는지 읽어보는 재미는 있었음 * 중요한 받은편지함이라면 Migadu, Simplymail, Fastmail 같은 훌륭한 **호스팅 메일함 서비스**가 있어 직접 운영할 생각은 들지 않음. 재미나 중요하지 않은 용도라면 가능함 * Gmail 의존의 문제를 입증하듯, 현재 Gmail이 **Lobsters 비밀번호 재설정 메일**을 스팸으로 차단하고 있음 로그에는 “Gmail has detected that this message is likely 550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this 550-5.7.1 message has been blocked.”라고 나오는데, 이를 Google에 알릴 방법이 궁금함 * Gmail만의 문제는 아닌 듯함. mailbox.org에서도 몇 주 전부터 **lobste.rs 메일**이 받은편지함에 도착하지 않았음 메일링 리스트 게이트웨이가 lobste.rs 쪽에서 고장 난 줄 알고 구독을 해지했는데, 어차피 자주 읽지 않았고 지금은 웹사이트를 선호함 * 집에서 메일을 직접 운영한다는 발상은 좋지만, 이사할 때가 문제임. 이사 중에도 중요한 메일이 오므로 **백업 MX**만으로는 충분하지 않음 구현은 가능하겠지만 이사 자체로도 스트레스가 큰데, 이사 점검표에 메일 이전 절차까지 넣고 싶지는 않음. 그동안 블로그나 숨겨진 DNS 마스터가 중단되는 것은 괜찮음 * 예전에는 집에서 메일을 운영했지만, 요즘 일반 가정용 ISP 환경에서는 실용적이지 않음. 이사, ISP의 포트 차단, **가정용 IP 대역 차단 목록** 같은 문제가 있음 약 15년 전 저렴한 VM으로 메일 서버를 옮긴 뒤로는 계속 안정적으로 운영 중임. 정착한 곳에서 차단 목록에 없는 고정 IP와 기업용 수준의 회선을 쓸 수 있다면 괜찮을 것임 * **여러 MX 레코드**를 설정하고, 장애 시 그중 하나가 메일을 전달하게 만들 수 있음 또한 SMTP에는 재시도가 프로토콜 자체에 포함돼 있어, 서버가 24시간 전에 재시도를 중단하면 관련 명세를 준수하지 않는 것임. 메일함이 없거나 용량을 초과했을 때처럼 서버가 명시적으로 거부하는 경우와 달리, SMTP는 생각보다 견고함 * 직접 메일을 운영할 때 어려운 부분은 수신 스팸이 아니라, 발신에 필요한 조치를 모두 해도 대형 메일 사업자가 보낸 메일을 스팸으로 분류하는 것임 개인이나 가정에서 보내는 정도의 물량으로는 IP에 **긍정적인 평판**이 쌓이지 않으므로, Gmail 등의 받은편지함에 들어가지 못하기 시작하면 사실상 해결하기 어려움 다만 Amazon SES 같은 서비스로 중계하면 설정도 쉽고 전달 문제도 사라질 수 있음. 정치적 이유나 데이터 주권 때문에 직접 운영한다면 받아들이기 어려운 해법일 수 있음 * 메일 중계 업체 후보로 https://forwardemail.net/ 을 살펴보고 있음 * 자체 메일 서버의 가장 좋은 점은 **스팸 필터링을 하지 않아도 된다**는 것임. 가끔 정크 메일이 오지만 누구나 내게 메일을 보낼 수 있다는 확신이 더 좋음 스팸함을 확인하는 것만으로는 부족함. 대형 기술 기업은 별다른 이유 없이 메일을 조용히 폐기하기도 하며, Gmail의 수신 성공률은 약 90%여서 다른 대형 사업자가 보낸 메일조차 10%가 사라짐. 자체 운영 메일은 한 번도 수신에 실패하지 않았음 반대로 다른 대형 서비스 계정에 메일을 보내려면 그쪽 계정이 여전히 필요하지만, 연락처로는 항상 자체 운영 주소를 제공함. 대형 사업자는 발신에만 쓰고 MX는 자체 서버로 지정할 수 있을지 시험해보고 싶음 * 내 서버는 하루에 **수천 건의 스팸**을 차단함. 스팸 전송을 시도하기도 전에 차단되는 연결 수천 건은 제외한 수치임 * https://xmox.nl 은 설정하기 매우 쉬웠음 * 1년 넘게 운영한 듯하지만 개발이 중단된 것으로 보이고 필요한 필터링 기능도 부족함. **xmox 단일 구성**에서 벗어나 Postfix 기반 구성요소 묶음으로 돌아갈지 고민 중임 * 웹사이트의 **메일링 리스트**를 직접 운영 중임. 구독자는 몇 명뿐이지만 메일은 정상적으로 전달됨 개인 메일까지 직접 운영할 의향은 없음 * 몇 년 전 Hetzner VPS에 https://modoboa.org/ 를 설치했지만 업그레이드에 여러 번 실패한 뒤 사실상 포기했음. 지금도 대부분 작동한다는 이유만으로 유지 중이지만 **장기적으로 지속 가능한 구성**은 아니며, 다음 선택은 아직 정하지 못했음 Steam 같은 일부 2단계 인증 코드는 받은편지함에 너무 늦게 도착함. 원인을 찾지 못해 그럴 때는 거의 쓰지 않는 Gmail 계정을 사용함 스팸도 어느 정도 통과하지만 수신 스팸에는 [완벽한 해결책이 없음](https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wont-work-checklist/). 자연어 처리를 위해 설계된 **LLM**이 이 작업에는 잘 맞을 수도 있어 실제 성능이 궁금하지만, 자원 사용량이 터무니없이 커질 가능성도 있어 보임