어려운 방식으로 메일 자체 호스팅하기: /24 IPv4 블록부터 SMTP 평판까지
오늘 올라온 글 중에 1997년부터 운영된 Recoil 메일 인프라를 전용 /24 IPv4 블록 위에서 Postfix, Dovecot, rspamd, Roundcube로 다시 짜는 이야기가 있었다. 솔직히 "메일 서버 직접 운영"은 인프라 엔지니어라면 한 번쯤 호기심에 손댔다가 데인 영역이다. 나도 그랬다. 이 글은 그 데임의 구조를 실무 관점에서 풀어본다.
왜 지금, 무슨 문제를 푸는가
요즘은 메일 보내고 싶으면 그냥 SES, SendGrid, Resend 쓰면 끝이다. 그런데도 굳이 자체 호스팅을 하는 이유는 두 가지다. 하나는 데이터 주권 — 내 메일 전문이 남의 서버를 거치지 않는다. 다른 하나는 학습 가치다. SMTP, IMAP, 스팸 필터링, 그리고 무엇보다 IP 평판(reputation)이 어떻게 돌아가는지 몸으로 알게 된다.
핵심은 원문 제목의 "어려운 방식(the hard way)"이라는 표현이다. 메일 수신/발신 자체는 데몬 몇 개 띄우면 된다. 진짜 어려운 건 다른 메일 서버들이 내 메일을 스팸 처리하지 않게 만드는 것이고, 이게 9할이다. 자체 라우팅 가능한 /24 블록에서 시작한다는 건, 임대 VPS의 오염된 IP 평판을 피하고 IP 통제권을 직접 쥐겠다는 의미로 보인다.
구조와 동작 원리
전형적인 자체 호스팅 스택은 역할이 깔끔하게 나뉜다.
- Postfix: SMTP. 메일을 받고(MX) 보내는(relay) 본체.
- Dovecot: IMAP/POP3. 사용자가 메일함을 읽는 부분. SASL 인증도 여기서 위임받는다.
- rspamd: 스팸 필터링 + DKIM 서명. 들어오는 메일 점수 매기고 나가는 메일에 서명한다.
- Roundcube: 웹메일 UI.
메일 한 통이 들어올 때 흐름을 비유하자면, Postfix는 건물 1층 로비(외부 연결을 받는 곳), rspamd는 보안 검색대(스팸 점수 채점), Dovecot은 각 호실 우편함(최종 저장과 조회)이다.
발신 쪽이 더 까다롭다. 받는 서버는 내 메일이 진짜인지 세 가지로 검증한다.
# SPF: "이 IP가 우리 도메인 메일을 보내도 되는가"
example.com. IN TXT "v=spf1 ip4:203.0.113.10 -all"
# DKIM: rspamd가 본문에 서명한 공개키
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
# DMARC: SPF/DKIM 실패 시 정책
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
여기에 더해 PTR(역방향 DNS)이 발신 IP에서 도메인으로 정확히 풀려야 한다. 이게 안 맞으면 Gmail 등이 바로 거부하거나 스팸함으로 보낸다. /24 블록을 직접 갖는 이유 중 하나가 이 PTR을 내 마음대로 설정할 수 있다는 점이다 — 일반 VPS는 PTR 설정을 못 하거나 제한적인 경우가 많다.
실무 관점: 트레이드오프와 함정
몇 년간 이쪽을 들여다본 입장에서 현실적인 얘기를 하면.
1. 발신은 평판 게임이다
가장 흔한 실수가 "설정 다 맞췄는데 왜 Gmail이 스팸 처리하지?"다. SPF/DKIM/DMARC 전부 통과해도 IP에 발신 이력이 없으면 신뢰가 0이다. 새 IP는 워밍업(소량부터 점진적 증량)이 필요하고, 25번 포트가 막힌 IP 대역이면 시작조차 못 한다. AWS, 많은 클라우드가 25번 아웃바운드를 기본 차단한다. 자체 /24 블록 + 라우팅 통제는 이 문제를 정면 돌파하려는 선택으로 보인다.
2. 블랙리스트는 한순간
Spamhaus 같은 RBL에 한 번 올라가면 회복이 느리고 피곤하다. 사용자 계정 하나가 털려서 스팸 송신지로 쓰이면 IP 전체 평판이 날아간다. 그래서 발신 레이트 리밋, 인증 강제, fail2ban 연동이 사실상 필수다.
3. 운영 부담이 진짜 부담이다
메일은 24/7 살아있어야 하고, 다운되면 송신측이 재시도하다 결국 바운스시킨다. TLS 인증서 갱신, rspamd 룰 업데이트, 디스크 풀로 인한 메일 유실 등 신경 쓸 게 많다. 이건 "주말 프로젝트"의 탈을 쓴 장기 운영 책임이다.
대안 정리
| 방식 | 적합한 경우 |
|---|---|
| SES / SendGrid 등 발신 전용 | 앱 알림/트랜잭션 메일만 필요. 평판 관리 위임. |
| Mailcow / Mail-in-a-Box (도커 올인원) | 자체 호스팅 원하지만 직접 설정은 부담스러울 때. |
| 이번 글 같은 풀 수동 스택 | 학습 목적이거나 IP·라우팅까지 완전 통제가 필요할 때. |
현실적으로 회사 업무 메일은 그냥 Google Workspace나 M365 쓰는 게 맞다. 자체 호스팅은 명확한 이유(주권, 학습, 특수 요건)가 있을 때만 손대자.
정리
한 줄 요약: 메일 자체 호스팅에서 데몬 설정은 쉽고, 발신 IP 평판과 24/7 운영이 어렵다. SMTP/스팸/평판의 작동 원리를 몸으로 배우고 싶거나 IP·라우팅 통제가 꼭 필요한 사람에게는 훌륭한 프로젝트다. 반대로 그냥 메일이 잘 가기만 하면 되는 상황이라면 관리형 서비스가 시간을 아껴준다. SPF/DKIM/DMARC/PTR은 자체 호스팅이든 발신 전용이든 어차피 알아야 하니, 거기서부터 익히는 걸 추천한다.