2026년에는 이메일을 직접 호스팅할 수 있음

 (blog.haschek.at)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 이메일은 본래 개방형 시스템이며, 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가 권장되지만, 가정 인터넷이 다음 조건을 모두 충족하면 집에서도 메일 서버를 운영할 수 있음
    • 블록리스트에 등재되지 않은 고정 IPv4 주소
    • CGNAT 뒤에 있지 않은 회선
    • ISP 지원 등을 통해 IP의 PTR 레코드를 변경할 수 있는 권한
    • 일반적인 메일 서버 포트 25, 143, 465, 587, 993을 열 수 있는 환경
  • 서버가 잠시 내려가도 발신 측 메일 서버가 배달을 재시도하므로 곧바로 수신 메일을 잃지는 않음
    • 하루 중 인터넷 중단 시간이 40% 미만이면 정상적으로 작동할 수 있음

메일 서버 소프트웨어

도메인과 DNS 설정

  • IP와 마찬가지로 도메인도 먼저 스팸 블록리스트 등재 여부를 확인해야 함
  • 정상적인 발신과 수신에는 다음 DNS 레코드가 필요함
    • SPF: 도메인을 대신해 메일을 보낼 수 있는 서버를 지정하며, 일반적인 값으로 v=spf1 mx a ~all을 사용할 수 있음
    • DKIM: 발송 메일 헤더에 암호학적 서명을 추가하며, 서버가 안내한 이름과 공개 키 값을 도메인에 등록함
    • DMARC: SPF와 DKIM을 확장해 도메인 위조를 방지하며, 값이 불확실하면 DMARC 생성기를 이용할 수 있음
    • MX: 다른 서버가 메일을 배달할 위치를 지정함. mail.yourdomain.com의 A 레코드를 서버 IP로 연결하고 MX 우선순위 10의 값으로 해당 호스트명을 설정하는 방식이 일반적임
  • PTR 레코드는 ISP나 VPS 제공자만 설정할 수 있으며, 서버 IP가 mail.yourdomain.com 같은 실제 메일 서버 호스트명으로 역방향 해석돼야 함
  • 일부 서버는 자동 서비스 탐지용 레코드를 추가로 권장하지만, SPF·DKIM·DMARC·MX·PTR가 기본 구성임
  • 구축 후 mail-tester.com에서 레코드와 서버 동작, 메일 배달 상태를 검사하는 것이 권장됨

로컬 LLM을 이용한 스팸 차단

  • 기존 오픈소스 스팸 차단은 IP·도메인 블록리스트, Spamhaus 같은 외부 서비스, 키워드 검색에 의존했으며 효과가 낮아 자체 호스팅 이탈의 주요 원인이었음
  • 최근 2년 동안 로컬 LLM 분류가 자체 호스팅 환경의 스팸 문제를 해결할 수 있는 선택지로 등장함
  • Rspamd는 블록리스트, IP·DNS 검사, 키워드 탐지에 더해 GPT 플러그인으로 이메일의 스팸 여부를 LLM에 분류시킬 수 있음
  • 개인 메일을 외부 LLM API로 보내는 대신 Gemma 4 12B QAT를 로컬에서 실행함
    • GPU나 CPU에서 실행할 수 있으며 최소 7GB RAM 또는 VRAM이 필요함
    • 다국어를 지원해 이메일 분류에 활용할 수 있음

로컬 모델 실행과 Rspamd 연결

  • 로컬 LLM을 처음 구성한다면 Windows·Linux·macOS용 Unsloth의 llama.cpp 가이드를 참고할 수 있음
  • Linux와 macOS에서는 다음 명령으로 llama.cpp를 설치함
curl -LsSf https://llama.app/install.sh | sh
  • Windows에서는 다음 명령을 사용함
winget install llama.cpp
  • 모델 서버는 다음과 같이 실행하며, localhost:8080에서 채팅 인터페이스를 확인할 수 있음
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가 Outlook을 대체할 수 있는 기능성 높은 오픈소스 클라이언트임
    • 필요한 기본 기능과 충분한 검색 기능을 제공함
    • Android 앱도 제공함
    • 3년간 사용하면서 문제가 없었음
  • 웹메일이 필요하면 다음 선택지를 사용할 수 있음

유지보수와 운영 책임

  • docker-mailserver 같은 현대적 메일 서버 솔루션은 보안 수정과 프로덕션 환경을 깨뜨리지 않는 자동 업데이트를 고려해 설계됨
  • 자체 호스팅은 데이터 통제권을 제공하는 대신 백업, 복구, 원격 접근, 업데이트 책임을 운영자에게 돌려줌
  • 백업이 없으면 모든 데이터를 잃을 수 있으므로 충분한 백업 계획을 마련하고 복구 절차를 최소 한 번 시험해야 함
  • 조건과 운영 책임을 감당할 수 있다면 짧은 서버 중단에도 메일을 운영할 수 있으며, 데이터 주권을 중시하는 사용자는 자체 호스팅을 시도할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 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 같은 서비스로 중계하면 설정도 쉽고 전달 문제도 사라질 수 있음. 정치적 이유나 데이터 주권 때문에 직접 운영한다면 받아들이기 어려운 해법일 수 있음

  • 자체 메일 서버의 가장 좋은 점은 스팸 필터링을 하지 않아도 된다는 것임. 가끔 정크 메일이 오지만 누구나 내게 메일을 보낼 수 있다는 확신이 더 좋음
    스팸함을 확인하는 것만으로는 부족함. 대형 기술 기업은 별다른 이유 없이 메일을 조용히 폐기하기도 하며, Gmail의 수신 성공률은 약 90%여서 다른 대형 사업자가 보낸 메일조차 10%가 사라짐. 자체 운영 메일은 한 번도 수신에 실패하지 않았음
    반대로 다른 대형 서비스 계정에 메일을 보내려면 그쪽 계정이 여전히 필요하지만, 연락처로는 항상 자체 운영 주소를 제공함. 대형 사업자는 발신에만 쓰고 MX는 자체 서버로 지정할 수 있을지 시험해보고 싶음

    • 내 서버는 하루에 수천 건의 스팸을 차단함. 스팸 전송을 시도하기도 전에 차단되는 연결 수천 건은 제외한 수치임

  • https://xmox.nl 은 설정하기 매우 쉬웠음

    • 1년 넘게 운영한 듯하지만 개발이 중단된 것으로 보이고 필요한 필터링 기능도 부족함. xmox 단일 구성에서 벗어나 Postfix 기반 구성요소 묶음으로 돌아갈지 고민 중임

  • 웹사이트의 메일링 리스트를 직접 운영 중임. 구독자는 몇 명뿐이지만 메일은 정상적으로 전달됨
    개인 메일까지 직접 운영할 의향은 없음

  • 몇 년 전 Hetzner VPS에 https://modoboa.org/ 를 설치했지만 업그레이드에 여러 번 실패한 뒤 사실상 포기했음. 지금도 대부분 작동한다는 이유만으로 유지 중이지만 장기적으로 지속 가능한 구성은 아니며, 다음 선택은 아직 정하지 못했음
    Steam 같은 일부 2단계 인증 코드는 받은편지함에 너무 늦게 도착함. 원인을 찾지 못해 그럴 때는 거의 쓰지 않는 Gmail 계정을 사용함
    스팸도 어느 정도 통과하지만 수신 스팸에는 완벽한 해결책이 없음. 자연어 처리를 위해 설계된 LLM이 이 작업에는 잘 맞을 수도 있어 실제 성능이 궁금하지만, 자원 사용량이 터무니없이 커질 가능성도 있어 보임

답변달기