통합 받은편지함: 전달 없이 모든 계정 확인하기

통합 받은편지함은 여러 계정의 메일을 수신 시간순으로 모아 보여 주고, 각 행에 어느 계정에서 왔는지 표시하는 목록입니다. 메일 전달로 계정을 모으려다 한계를 겪은 뒤 이런 기능을 찾는 경우가 많습니다.

설정이 적절하지 않으면 보낸 사람 표시가 달라지거나 일부 메일이 스팸으로 분류되고, 답장이 상대가 모르는 주소에서 나갈 수 있습니다. 결국 두 번째 계정은 별도의 브라우저 탭으로 돌아가고, 하루에도 여러 번 확인해야 합니다.

규칙을 바꾸는 것만으로는 해결되지 않을 때가 있습니다. 전달은 메일의 배송 경로를 바꾸므로 인증에 영향을 줄 수 있습니다. SRS, 유지된 DKIM 서명, 수신 측이 신뢰하는 ARC 체인은 도움이 될 수 있지만, 전달을 완전한 다중 계정 메일 클라이언트로 만들어 주지는 않습니다.

다른 방법은 클라이언트가 각 사서함을 직접 읽는 것입니다. 데스크톱 메일 프로그램은 오래전부터 이렇게 작동했습니다. 서버 측 통합 받은편지함도 같은 원리지만, 휴대폰과 노트북에서 같은 통합 목록을 볼 수 있습니다.

전달이 메일 클라이언트를 대신할 수 없는 이유

전달은 원래 발신자가 보통 SPF에서 허용하지 않은 서버를 통해 메일을 다시 보냅니다. 따라서 SPF 검증이 실패할 수 있습니다. 서명된 부분이 바뀌지 않으면 DKIM은 유효한 상태로 남는 경우가 많습니다. DMARC는 SPF 또는 DKIM 검증 성공과 From 주소와의 정렬을 요구합니다. 둘 다 이 조건을 충족하지 못하면 p=reject 정책은 수신 서버에 메일 거부를 권고합니다. 최종 처리는 수신 측이 결정합니다. 전달로 인한 배송 문제가 이렇게 발생할 수 있습니다.

Sender Rewriting Scheme은 봉투 발신자를 전달 서버를 허용하는 도메인으로 바꿉니다. 여기서 설명하는 시스템은 SRS를 자동 적용해 새 봉투 발신자의 SPF 검증을 돕습니다. 하지만 그 도메인을 원래 From과 정렬하거나 손상된 DKIM 서명을 복구하지는 않으며, 예전 주소로 답장할 수 있게 해 주지도 않습니다.

마지막 문제는 쉽게 놓칩니다. 전달은 한 방향으로만 작동합니다. you@oldcompany.com으로 온 메일이 새 받은편지함에 도착해도, 예전 주소의 발송을 따로 설정하지 않았다면 답장은 you@newcompany.com에서 나갑니다. 고객과 대화할 때 혼란을 줄 수 있습니다. 전달 규칙만으로는 예전 주소를 사용해 발송할 권한이 생기지 않습니다.

저장 공간도 고려해야 합니다. 전달된 복사본은 대상 계정의 용량을 쓰고, 원본도 출발 계정에 남을 수 있습니다. 전달 후 원본을 삭제하도록 설정하면 그곳에서 복구할 수 있는 원본이 없어집니다. 잘못된 규칙이 복구를 더 어렵게 만들 수 있습니다. 백업은 전달과 별개로 마련해야 합니다.

전달은 별도 사서함이 없는 주소에 유용합니다. 예를 들어 invoices@로 받은 청구서를 담당자에게 보내는 용도입니다. 하지만 자주 쓰는 여러 계정에서 읽고 보내는 기능을 대신하지는 않습니다. 자세한 내용은 별칭, 사서함, 전달의 차이와 전달 메일의 SRS를 참고하세요.

POP 가져오기와 기존 기능의 종료

또 다른 전통적인 방식은 외부 계정에 POP3로 주기적으로 로그인해 새 메일을 내려받고 로컬에 저장하는 것입니다. Gmail Mail Fetcher가 이 방식으로 작동했습니다. Outlook.com의 연결된 계정도 비슷한 목적의 기능이었습니다.

원문은 이런 기능의 종료를 설명합니다. Microsoft는 Outlook.com에서 연결된 계정을 제거했고, Google도 Gmail Mail Fetcher와 Gmailify 종료를 발표했습니다. 현재 일정과 제공 여부는 각 서비스에서 확인하세요. 특정 기능의 변경이지, 여러 계정에 접근하는 모든 방법이 사라진다는 뜻은 아닙니다.

주기적으로 가져오는 방식에는 기술적인 한계가 있습니다. 메일은 다음 확인 때까지 나타나지 않습니다. 원본을 유지하면 두 서비스에서 모두 저장 공간을 사용합니다. 상태도 달라질 수 있습니다. 한쪽에서는 읽음이고 다른 쪽에서는 읽지 않음이거나, 한쪽에서 삭제해도 다른 쪽에는 남습니다. POP3는 기존 폴더 구조를 가져오지 않습니다.

받은편지함을 통합하는 세 가지 방식

각 방식에는 제약이 있습니다. 전달은 메일을 다시 보내므로 인증에 영향을 줄 수 있습니다. 복사본 가져오기는 확인 주기와 저장 조건에 좌우됩니다. 실시간 IMAP 프록시는 각 계정에서 인증하고 필요할 때 읽으며, 영구적인 복사본 보관소를 만들지 않습니다. 유효하지 않은 인증 정보는 연결을 시도할 때 발견됩니다.

TrekMail은 세 번째 방식을 사용하며 영구 메일 복사본을 만들지 않습니다. 통합 화면을 열면 서버가 각 계정에 IMAP으로 연결하고 필요한 헤더를 가져와 내부 날짜순으로 합친 뒤 결과를 잠시 캐시에 저장합니다. 메일을 읽으면 권한과 설정이 변경을 허용하는 경우 원본 서버에서도 읽음으로 표시됩니다.

계정을 연결해도 호스팅 위치는 바뀌지 않습니다. Gmail은 Google에 그대로 있고 저장 공간, 필터, 웹 화면도 유지됩니다. 연결은 MX나 수신 경로를 바꾸지 않습니다. 연결을 끊어도 정리할 복사본 보관소는 없지만, 클라이언트에서 이미 수행한 작업은 원본 서버에 남습니다.

실제 사용 모습

화면은 두 종류입니다. 하나는 전체를 확인하는 통합 목록이고, 다른 하나는 특정 계정에 집중하는 화면입니다. 작업에 맞춰 전환할 수 있습니다.

모든 받은편지함은 사서함과 연결된 계정의 메일을 수신 시간순으로 합칩니다. 각 행에는 서비스 로고 또는 TrekMail 사서함의 색상 머리글자가 표시됩니다. 답장할 때는 해당 발신자가 미리 선택되지만, 실제 사용은 권한과 발송 설정에 따라 달라집니다.

계정별 화면은 사이드바에서 선택합니다. 계정을 클릭하면 해당 계정의 폴더, 임시보관함, 보낸편지함이 표시됩니다.

원본 계정은 병렬로 확인합니다. 여덟 개의 IMAP 서버에 차례로 접근하면 페이지가 눈에 띄게 느려지기 때문입니다. 인증 정보가 취소됐거나 서비스에 장애가 생겨 접근할 수 없는 계정은 건너뛰고 화면에 표시합니다. 다른 계정의 메일은 계속 볼 수 있습니다.

올바른 주소로 메일 보내기

연결된 Gmail 계정의 메일에 답장하면 본인 계정으로 인증한 뒤 Google의 SMTP 서버에 답장을 제출합니다. 연결과 발송 권한이 올바르게 설정돼 있으면 당사의 발송 서버가 아니라 Google의 인프라에서 메일을 보냅니다.

이는 메일 인증과 관련이 있습니다. Gmail의 SPF는 Google 서버를 허용합니다. 허용되지 않은 외부 인프라에서 @gmail.com으로 보내면 유효하고 정렬된 SPF 또는 DKIM을 기대할 수 없습니다. 계정의 허용된 서버를 사용하면 올바른 검증에 도움이 됩니다. DMARC는 From과 정렬된 유효한 SPF 또는 DKIM을 요구하며, 둘 다 성공해야 하는 것은 아니고 받은편지함 도착도 보장하지 않습니다.

다른 계정도 같습니다. Fastmail 주소는 Fastmail을 통해, 자체 서버의 주소는 해당 SMTP를 통해 보냅니다. 보낸 사람 메뉴에는 사서함 주소, 발송이 활성화된 별칭, 답장 권한이 있는 공유 사서함, 연결된 계정만 나타납니다. 주소가 없다면 권한이나 설정이 부족할 수 있으며, 앞으로 인증이 반드시 실패한다는 뜻은 아닙니다. 발송 후 두 분 뒤 반송 메일로 알게 되기보다 먼저 확인하세요.

앱 비밀번호와 OAuth

대형 서비스는 일반 비밀번호를 이용한 IMAP 접근을 점점 더 제한하고 있습니다. 연결에는 앱 비밀번호, OAuth 또는 다른 지원 방식이 사용됩니다. 절차는 서비스마다 다르므로 현재 규칙과 조직 정책도 확인해야 합니다.

앱 비밀번호는 별도의 무작위 문자열로, 대개 기본 비밀번호를 바꾸지 않고 개별적으로 취소할 수 있습니다. 권한이 한 프로토콜로만 제한되는 것은 아니며 서비스에 따라 다릅니다. 앱에 기본 비밀번호를 제공하지 않아도 됩니다. 설정 마법사는 식별된 서비스의 생성 페이지로 연결합니다.

서비스는 자동으로 식별합니다. 도메인을 알려진 서비스와 비교하고, 자체 도메인이라면 MX 레코드를 확인합니다. 이 덕분에 @gmail.com으로 끝나지 않는 Google Workspace와 Microsoft 365 계정도 식별할 수 있습니다. 인식하지 못하면 서버 정보를 직접 입력합니다. 이 확인은 DNS를 변경하지 않습니다.

수동 연결은 IMAP 포트 993의 암시적 TLS 또는 143의 STARTTLS와 SMTP 포트 465, 587, 2525를 지원합니다. TLS 인증서 검증은 필수입니다. 신뢰되지 않는 자체 서명 인증서나 이름 불일치가 있으면 연결할 수 없습니다. 메일에 접근하는 연결이므로 신뢰 체인, 유효 기간, 서버 이름을 확인하세요.

계정 연결하기

1. 웹메일을 열고 설정 → 연결된 계정으로 이동합니다.
2. 계정 연결을 클릭하고 주소를 입력합니다.
3. 서비스가 식별되면 앱 비밀번호 생성 안내를 따릅니다. Outlook.com은 Microsoft 로그인으로 진행합니다. 식별되지 않으면 서비스 문서에 따라 IMAP과 SMTP 서버, 포트, 암호화 방식을 입력합니다.
4. 연결 테스트를 클릭합니다. 읽기와 발송을 따로 검사하므로 어느 부분이 실패했는지 알 수 있습니다.
5. 저장합니다. 계정이 사이드바에 나타나고 메일이 모든 받은편지함에 추가됩니다.

폴더는 처음 연결할 때 매핑합니다. 서비스마다 [Gmail]/Sent Mail, Sent Items, Sent처럼 이름이 다르므로 특수 용도 플래그가 있으면 이를 사용하고, 없으면 이름을 비교합니다. Gmail의 전체보관함 같은 가상 화면은 같은 메일의 중복 표시를 막기 위해 숨깁니다. 라벨이 있다고 해서 각 메일이 물리적으로 여러 번 저장된다는 뜻은 아닙니다.

서비스별 안내는 Gmail, Outlook과 Microsoft, iCloud, Yahoo와 AOL, 기타 IMAP 서버 문서에서 확인하세요.

자주 발생하는 문제와 증상

앱 비밀번호 취소. 자주 발생하는 원인입니다. Google의 기본 비밀번호를 바꾸면 앱 비밀번호가 취소될 수 있습니다. 화면은 계정을 숨기지 않고 다시 연결하라고 안내합니다. 새 앱 비밀번호를 만들고 설정을 업데이트하세요.

서비스에서 IMAP 비활성화. Google Workspace 또는 Microsoft 365 정책이 접근을 제한할 수 있습니다. 클라이언트에서는 이를 우회할 수 없습니다. 관리자가 권한을 확인해야 합니다.

OAuth 승인 무효화. Microsoft 토큰은 허용되는 동안 갱신됩니다. 동의 취소나 보안 및 정책 변경으로 재승인이 필요할 수 있습니다. 안내가 나타나면 다시 로그인하세요.

원본 서버의 느린 응답. 각 서버에는 제한 시간이 있습니다. 응답이 너무 늦으면 해당 페이지 로딩에서는 건너뛰고 안내합니다. 다른 사서함을 지연시키면서 끝없이 재시도하지 않습니다.

자세한 내용은 연결된 계정 문제 해결을 참고하세요.

제한

원문 설명에 따르면 외부 계정 연결은 Starter 이상 요금제에서 제공됩니다.

통합 화면은 최대 25개의 원본 계정을 동시에 확인합니다. 그보다 많으면 계정별 화면이 더 실용적입니다. 연결된 메일의 영구 복사본은 요금제의 저장 용량을 사용하지 않으며, 메일은 원래 위치에 남습니다. 다만 화면 데이터의 임시 캐시까지 없다는 뜻은 아닙니다.

자주 묻는 질문

통합 받은편지함이 내 메일을 옮기나요?

아니요. 영구 보관소를 복사하거나 이동하지 않고, 원래 서비스의 메일을 IMAP으로 읽습니다. 연결을 끊어도 원본 사서함은 삭제되지 않지만, 읽음 표시처럼 이미 수행한 작업이 되돌려지지는 않습니다.

메일 이전과는 무엇이 다른가요?

이전은 기존 서비스를 떠나기 위해 메일을 TrekMail로 복사하는 작업입니다. 통합 받은편지함은 저장 위치를 유지하고 공통 화면만 제공합니다. 완전히 옮기려면 일괄 이전을 사용하세요.

답장은 올바른 주소에서 나가나요?

권한과 설정이 올바르면 연결된 주소의 SMTP를 통해 보내므로 상대는 기존 주소를 보게 됩니다. 유효하고 정렬된 SPF 또는 DKIM은 서비스 설정에 달려 있습니다. 연결만으로 인증이나 배송이 보장되지는 않습니다.

Gmail은 왜 로그인 버튼 대신 앱 비밀번호를 사용하나요?

이 연동은 앱 비밀번호로 IMAP을 사용합니다. Gmail API는 제한된 권한 심사와 데이터 처리 방식에 따른 외부 보안 평가가 필요할 수 있습니다. 앱 비밀번호는 다른 접근 방식이며, 계정 정책이 생성을 허용하면 Google에서 개별적으로 취소할 수 있습니다. IMAP과 API가 반드시 같은 권한을 제공하는 것은 아닙니다.

내 서버의 사서함도 추가할 수 있나요?

네. IMAP과 SMTP 서버, 포트, 암호화 방식을 직접 입력하면 됩니다. 인증서는 신뢰 및 이름 검증을 통과해야 합니다. 신뢰되지 않는 자체 서명 인증서는 교체하세요. 공인 인증기관의 인증서는 체인, 유효 기간, 이름이 올바르면 사용할 수 있습니다.

휴대폰에서도 통합 받은편지함을 쓸 수 있나요?

네. 연결 설정은 로컬 프로필이 아니라 서버에 저장됩니다. 지원되는 기기에서 로그인하면 다시 연결할 필요 없이 같은 계정과 목록을 볼 수 있습니다.

연결된 계정을 지원하지 않는 요금제로 바꾸면 어떻게 되나요?

가져오기가 중단되고 계정은 사용 불가로 표시됩니다. 요금제 변경으로 원본 데이터가 삭제되지는 않습니다. 지원 요금제로 돌아왔을 때 인증 정보와 권한이 유효하면 다시 접근할 수 있습니다.