도메인을 구입했다면 이제 받은편지함을 만들 차례입니다.
내 도메인으로 이메일을 만드는 것은 사업 운영자로서 내릴 가장 중요한 인프라 결정 중 하나입니다. someone@gmail.com을 사용하는 것과 name@yourcompany.com으로 업무를 보는 것은 다릅니다. 전자는 임시 부업처럼 보이고, 후자는 제대로 운영되는 회사라는 인상을 줍니다.
하지만 겉모습만의 문제는 아닙니다. 핵심은 관리 권한입니다. 무료 제공업체의 도메인 주소는 그 업체의 주소 체계에 종속됩니다. 자체 도메인이 있으면 메일 경로를 관리하고 호스트를 바꿀 수 있습니다. 다만 데이터 접근과 내보내기, 비용과 계정 권한은 실제 계약, 관리자 권한, 복구 수단에 따라 달라집니다.
첫 메일함을 개설하는 창업자든 cPanel 호스트에서 고객사 쉰 곳을 이전하는 MSP든 도메인, 메일 호스트와 올바른 DNS 레코드라는 기본 요소는 같습니다. 다만 실제 이전 절차와 권한, 서버 구성은 환경마다 다릅니다. 이 가이드에서는 작업 순서를 설명합니다.
시작 전 실제로 필요한 것
다음 세 요소 없이 이메일을 설정하면 DNS가 서로 다르게 작동하거나 메시지가 유실될 수 있습니다. 모두 준비한 뒤 시작하십시오.
1. 도메인
yourcompany.com 같은 도메인을 적법한 권한으로 관리할 수 있어야 합니다. 아직 구입하지 않았다면 Namecheap, Cloudflare Registrar, Porkbun 같은 등록기관의 현재 조건을 비교하십시오. 등록기관과 웹 호스팅을 분리하면 공통 의존성을 줄이는 데 도움이 됩니다. 다만 실제 DNS 제공업체, 접근 권한과 복구 절차도 확인해야 하며 분리만으로 장애 대응이 보장되지는 않습니다.
2. DNS 접근 권한
권한 있는 DNS 영역의 레코드를 수정할 수 있어야 합니다. DNS 제공업체에서는 보통 DNS Management, Zone Editor, Advanced DNS 같은 메뉴를 사용합니다. TXT, MX, CNAME 레코드를 편집하게 되므로 이 권한을 먼저 확보하십시오.
3. 이메일 호스트
권한 있는 DNS 제공업체가 라우팅 레코드를 게시하고, 메일 호스트가 선택한 서비스에 따라 메시지를 처리하고 저장합니다. GoDaddy의 도메인 등록만으로 메일함이 구성되지는 않습니다. 이용 가능한 메일 호스팅이나 전달 서비스를 확인하십시오. 선택지의 예는 다음과 같습니다.
- 일반적인 선택: Google Workspace 또는 Microsoft 365. 사용자당 연간 $72-$144는 과거 가격을 이용한 예시입니다. info@, billing@ 같은 주소는 서비스에 따라 별칭, 그룹, 공유 메일함으로 운영할 수 있으므로 주소마다 별도 사용자 라이선스가 필요한 것은 아닙니다. 현재 가격과 조건을 확인하십시오.
- 운영 중심 선택: TrekMail. 공유 스토리지와 계정 단위 요금 모델을 검토할 수 있습니다. 현재 요금, 권한, 사용자와 저장 용량 한도를 실제 업무 요구와 비교하십시오.
10분 체크리스트
짧은 작업 순서를 정리한 체크리스트이며 완료 시간을 보장하지 않습니다. 생략한 단계 때문에 예를 들어 한 시간의 추가 조사가 필요할 수 있고 DNS 캐시와 검증 과정도 실제 소요 시간에 영향을 줍니다.
| 단계 | 작업 | 주의점 |
|---|---|---|
| 1. 도메인 확인 | 도메인 관리 권한을 검증할 TXT 레코드 추가 | MX 전환 전에 수행합니다. 이 검증은 관리 권한을 확인하지만 계정 보안을 대신하지는 않습니다. |
| 2. 메일함 만들기 | 호스트 패널에서 사용자 (info@, jane@) 개설 | 수신자가 없으면 전환 후 거부될 수 있으며 550은 그 예입니다. 전체 서버 응답을 확인하십시오. |
| 3. MX 레코드 설정 | 도메인의 메일 트래픽을 호스트로 연결 | 우선순위와 실제 경로를 검토하고 폐기하기로 확인된 항목만 제거합니다. 승인된 하이브리드나 장애 조치 구성은 여러 호스트를 사용할 수 있습니다. |
| 4. 인증 | SPF, DKIM, DMARC 레코드 추가 | 2026년에 적용되는 Gmail과 Yahoo의 발신자 요건과 실제 메시지 인증을 확인합니다. 레코드만으로 받은편지함 도착이 보장되지는 않습니다. |
| 5. 테스트 | 외부 Gmail로 보낸 뒤 답장 | 완료로 판단하기 전에 발신과 수신이 모두 되는지 확인합니다. |
1단계: 메일함부터 만들기
수신자 구성을 빠뜨리면 전환 뒤 업무용 메시지를 받지 못할 수 있습니다.
MX를 전환하면 발신 서버는 DNS 정보를 갱신한 뒤 새 경로를 사용합니다. 새 호스트에 contact@yourdomain.com이 구성되지 않았다면 550 User Not Found 같은 수신자 거부 응답이 나올 수 있습니다. 반송 알림 여부는 발신 시스템에 따라 달라지며 받는 사람은 거부 사실을 모를 수 있습니다. 로그와 실제 수신 테스트를 확인하십시오.
MX 경로를 전환하기 전에 필요한 메일함을 모두 구성하십시오. 도메인 검증용 DNS 변경은 그보다 먼저 필요할 수 있습니다.
TrekMail에서의 절차:
- TrekMail 대시보드에 로그인합니다.
- 도메인의 메일함 탭으로 이동합니다.
- 현재 사용하는 주소를 모두 만듭니다.
중소기업: 최소한 개인 주소 (yourname@) 와 기능별 주소 (hello@ 또는 info@) 를 만드십시오.
고객을 이전하는 대행사: 수신자, 별칭과 전달 경로를 모두 조사하십시오. 이전 호스트에 billing@이 있었다면 MX 전환 전에 새 호스트에도 billing@을 구성해야 합니다. 원본 접근 권한과 복사 가능한 폴더, 메시지 수를 검증하고 최종 동기화를 계획하십시오. 연락처와 일정은 별도로 확인해야 하며 주소 누락은 거부로 이어질 수 있습니다.
TrekMail에서는 메일함을 직접 만들거나 메일함 설정 초대를 보낼 수 있습니다. 유효 기간이 제한된 일회용 링크를 보호하고 확인된 수신자에게 전달하십시오. 사용자가 직접 비밀번호를 설정하면 관리자가 사용자의 지속적인 비밀번호를 주고받지 않아도 됩니다. 전체 절차는 메일함 설정 초대 문서를 참조하십시오.
2단계: MX 레코드 설정과 전환
MX (Mail Exchange) 레코드는 발신 서버에 도메인의 메일 호스트를 알려 줍니다. 명시적인 MX가 없으면 SMTP는 조건에 따라 도메인의 주소 레코드를 이용할 수 있지만, 이를 의도적으로 구성한 메일 경로의 대안으로 삼지는 마십시오.
MX 레코드 설정 방법:
- 권한 있는 DNS 영역을 관리하는 제공업체의 설정 페이지로 이동합니다. 등록기관과 다를 수 있습니다.
- 기존 MX 레코드를 검토합니다. 'GoDaddy Secure Mail', 'Google Workspace', cPanel 항목의 실제 역할을 담당 관리자와 확인하십시오. 폐기하기로 확인된 항목만 제거하고 의도된 게이트웨이, 하이브리드와 장애 조치 경로는 유지하십시오.
- 계정에 표시되는 현재 레코드를 사용합니다. 아래는 과거 예시이며 그대로 복사할 설정이 아닙니다. 현재 기본 MX 대상은 mail.trekmail.net입니다.
| 유형 | 호스트/이름 | 값 | 우선순위 |
|---|---|---|---|
| MX | @ (또는 빈칸) | mx1.trekmail.net | 10 |
| MX | @ (또는 빈칸) | mx2.trekmail.net | 20 |
TTL: 전환 전에 300초로 낮추는 것은 계획 예시이며 캐시 유효 기간으로는 5분입니다. 다른 서버가 주기적으로 조회한다는 뜻은 아니며, 이미 24시간처럼 긴 값으로 캐시된 레코드가 즉시 바뀌지도 않습니다. 이전 TTL의 만료와 권한 있는 영역, 캐시 결과를 확인한 뒤 적절한 값, 예를 들어 3600으로 조정하십시오.
등록기관별 화면과 필드 이름은 주요 제공업체 DNS 설정 가이드를 참조하십시오.
3단계: 첫 로그인과 송수신 테스트
15-30분이나 24시간은 계획용 예시이지 공통 완료 시간이나 최대 대기 시간이 아닙니다. 실제 반영은 TTL과 캐시 등에 따라 달라집니다. 권한 있는 레코드와 실제 수신을 확인하십시오. 2단계를 마쳤다고 모든 발신 서버가 새 경로를 사용한다고 단정할 수는 없습니다.
먼저 웹메일에 로그인해 메시지 흐름을 테스트한 다음 Outlook이나 iPhone을 설정하십시오. 웹메일의 HTTPS 로그인은 별도 클라이언트의 IMAP이나 SMTP 연결이 작동한다는 증거가 아니므로 각각 따로 테스트해야 합니다.
발신 테스트: 새 주소에서 개인 Gmail로 이메일을 작성해 보냅니다.
- 도착했습니까?
- 스팸함에 들어갔습니까? 인증뿐 아니라 내용, 평판과 수신 정책도 조사하십시오. 인증 확인은 아래 4단계를 참조하십시오.
수신 테스트: Gmail에서 새 업무용 주소로 답장합니다.
- 웹메일 받은편지함에 도착했습니까?
- 도착했다면 이 테스트의 수신 경로가 작동한 것입니다. 다른 수신자와 로그, 이전 경로의 캐시도 확인하십시오.
두 테스트를 통과하면 지원되는 메일 클라이언트를 설정하십시오. TrekMail IMAP 및 SMTP 설정 문서에서 TLS, 인증서와 허용된 인증 방식을 확인하십시오. Gmail 연결 가이드도 이용할 수 있지만 Gmail 앱과 계정에 따라 가능한 연결 기능은 다릅니다.
4단계: 전송 성공률의 핵심인 SPF, DKIM, DMARC
MX는 수신 경로를 지정하고 SPF, DKIM, DMARC는 발신 메시지 인증을 지원합니다. 2025-2026년에 적용되는 Google과 Yahoo의 발신자 요건, 특히 대량 발신자 요건을 확인하십시오. 올바른 인증은 중요하지만 받은편지함 도착을 보장하지는 않습니다.
SPF: 발신 허용 서버
SPF (Sender Policy Framework)는 SMTP 발신 식별자에 허용된 서버를 DNS에 게시합니다. yourcompany.com이 MAIL FROM 도메인이거나 해당되는 경우 HELO 식별자라면 수신 서버는 그 정책에 따라 발신 IP를 평가합니다. 화면에 보이는 From 주소 자체가 SPF의 검사 대상은 아닙니다.
다음은 과거 SPF 예시이며 그대로 복사할 설정이 아닙니다. 현재 기본 구성은 spf.trekmail.net을 사용합니다. 계정에 표시되는 전체 레코드를 확인하고 허용된 발신 서비스를 모두 반영하십시오.
v=spf1 include:_spf.trekmail.net -all
포함된 서비스의 정책을 평가하고 일치하지 않는 발신자에게 SPF Fail 결과를 부여하는 정책입니다. 이 결과만으로 수신 서버가 반드시 거부하는 것은 아니며 수신 정책과 다른 인증 결과도 작용합니다.
끝의 -all은 일치하지 않는 발신자에게 SPF Fail을 부여합니다. -all은 트랜잭션 메일과 CRM을 포함한 모든 허용된 발신 경로를 하나의 유효한 SPF 레코드에 반영한 뒤 선택하십시오. 10회 제한은 중첩된 평가까지 포함하여 DNS 조회를 유발하는 항목에 적용되며, 모든 DNS 패킷이나 include 개수만을 뜻하지 않습니다. 초과하면 SPF PermError가 발생할 수 있습니다.
DKIM: 변조 여부를 확인하는 봉인
DKIM (DomainKeys Identified Mail) 서명이 구성된 메시지에는 암호학적 서명이 붙습니다. 수신 서버는 DNS의 선택자에 해당하는 공개 키로 실제 서명을 검증합니다. 서명된 부분이 바뀌면 검증이 실패할 수 있지만 모든 수정이 서명 대상에 영향을 주는 것은 아닙니다. 키와 설정 문제도 실패 원인이 될 수 있으므로 실제 헤더를 확인하십시오.
TrekMail 대시보드의 키와 DNS 안내에 따라 공개 키를 권한 있는 DNS 제공업체에 게시하십시오. 선택자와 게시된 레코드를 확인하고 실제 메시지 서명의 암호학적 검증도 수행해야 합니다. TXT 문자열을 복사했다는 사실만으로 서명이 유효하다고 볼 수는 없습니다. 절차는 필수 DNS 레코드 문서를 참조하십시오.
DMARC: 정책 적용 체계
DMARC는 SPF나 DKIM 중 적어도 하나가 성공하면서 그 도메인이 표시되는 From 도메인과 정렬되면 통과합니다. 둘 중 어느 검사도 정렬된 상태로 성공하지 못할 때의 요청 정책을 게시합니다. 보고서는 설정과 수신 서버의 협조에 따라 제공되며 발신 경로 조사에 도움이 되지만 실제 발신자의 신원을 자동으로 입증하지는 않습니다.
처음에는 모니터링 전용 정책으로 시작합니다.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
제한적인 DMARC 처리를 요청하지 않고 보고서 수신 주소를 지정하는 설정입니다. 다른 필터는 여전히 거부나 스팸 분류를 할 수 있습니다. 허용된 모든 발신 경로의 정렬과 인증을 검증한 다음 필요에 따라 p=quarantine이나 p=reject로 조정하십시오.
각 레코드의 자세한 설명은 SPF 레코드 설정, DKIM 설정, DMARC 설정 문서를 참조하십시오. 전체 과정을 한곳에서 보려면 이메일 인증 설정 순서 가이드가 세 가지를 차례로 설명합니다.
Gmail만 사용하면 안 되는 이유
'mycompany@gmail.com만 사용하면 안 되나요?' 사용할 수는 있지만 업무용 접근 관리, 복구와 인수인계 요구를 개인 계정으로 충족할 수 있는지 검토하십시오.
개인 주소를 업무에 사용할 때는 다음과 같은 관리 위험을 고려하십시오.
데이터 소유권
계정 제한은 고객 기록, 청구서와 연락처 접근에 영향을 줄 수 있습니다. 복구, 이의 제기와 지원은 계정 및 서비스 조건에 따라 달라집니다. 자체 도메인으로 도메인 이메일을 만들고 호스트를 선택하면 이전할 선택권이 생기지만, 원본을 내보낼 권한과 독립적인 백업이 여전히 필요합니다. 원본과 대상의 지원 형식, 폴더와 메시지 수를 검증하십시오. IMAP 동기화는 전체 백업을 대신하지 않습니다.
특정 인력에 대한 의존
영업 담당자가 john.sales@gmail.com을 쓰면 퇴사 뒤 업무 기록 접근이 개인 계정에 의존할 수 있습니다. john@yourcompany.com처럼 관리되는 계정에서는 권한과 보존 정책에 따라 인수인계를 할 수 있습니다. 비밀번호 변경만으로 충분하다고 보지 말고 세션과 앱 권한의 회수를 검증하십시오. 허용된 전달과 후임자 접근도 확인해야 하며 중단 없는 인계가 자동으로 보장되지는 않습니다.
SaaS 계정 잠금
회계 소프트웨어, CRM과 광고 플랫폼이 개인 계정에 연결되어 있으면 퇴사 뒤 복구가 어려워질 수 있습니다. billing@yourcompany.com 같은 관리되는 주소를 사용하되 플랫폼의 역할, 복구 설정과 추가 신원 검증도 확인하십시오. 메일 주소 관리 권한만으로 모든 서비스의 접근 권한이 결정되지는 않습니다.
사용자 지정 도메인 이메일의 원리
사용자 지정 도메인 이메일 주소는 @ 뒤의 도메인이 웹사이트와 일치하는 이메일 ID입니다. 정의는 간단하지만 그 기반 인프라는 이메일의 지속성과 장애 범위를 크게 바꿉니다.
| 유형 | 예 | 위험 |
|---|---|---|
| 인터넷 서비스 제공업체 메일 | user@comcast.net | 주소 유지가 인터넷 제공업체의 조건에 따릅니다. 이사나 해지 전에 계속 이용할 수 있는지 확인하십시오. |
| 웹 호스트 메일 (cPanel) | cPanel을 통한 you@yoursite.com | 같은 인프라를 공유하는 구성이라면 장애나 공격이 웹사이트와 메일 모두에 영향을 줄 수 있습니다. 실제 배포 구성을 확인하십시오. |
| 전용 이메일 호스팅 | TrekMail을 통한 you@yourcompany.com | 분리된 호스팅은 공통 장애 위험을 줄일 수 있지만 DNS와 네트워크 같은 의존성까지 모두 분리되는 것은 아닙니다. |
관리 요구, 공통 의존성과 복구 계획에 맞는 구성을 선택하십시오. 전용 메일 호스팅은 유용한 선택지지만 유일한 업무용 구성은 아니며 완전한 장애 격리를 보장하지도 않습니다.
1-5개 메일함을 위한 가장 간단한 설정
Microsoft 365나 Google Workspace는 메일 외에 협업 기능도 제공합니다. 500명 조직도 사용하는 플랫폼이 세 사람 팀에 유용할 수 있지만, 협업 기능이 필요한지 아니면 메일함과 역할 주소가 주된 요구인지 비교하십시오.
기존 방식 (사용자별 과금의 함정)
과거 가격을 이용한 계산 예시는 Google Workspace Starter를 사용자당 월 $6로 잡습니다. 직원 세 명 외에 info@, sales@, billing@이 필요해도 모든 주소를 별도 유료 사용자로 만들 필요는 없습니다. 별칭과 그룹을 검토하십시오. 이 예시에서 유료 사용자 6명을 만들 경우에만 월 $36, 연 $432가 됩니다. 현재 가격과 라이선스 조건은 별도로 확인하십시오.
과거 스토리지 비교에는 사용자당 30GB가 제시됩니다. 실제 공유 조직 스토리지, 관리자별 사용자 한도와 초과 시 동작은 에디션과 조건에 따라 달라집니다. 먼저 실제 사용량과 관리 옵션을 검토하십시오. 사용자가 한도에 도달했다고 모두를 업그레이드해야 하는 것은 아닙니다. 사용자당 월 $12라는 금액도 과거 가격 참고치입니다.
새로운 방식 (TrekMail 공유 모델)
과거 TrekMail Starter 설명은 월 $3.50 (또는 연 $42)에 50개 도메인, 도메인당 100개 메일함과 15GB 공유 스토리지를 제시합니다. 현재 가격, 기능 권한과 한도를 확인하십시오. info@, billing@, support@ 같은 주소는 사용 가능한 기능에 따라 별칭으로 메일함에 연결할 수 있습니다.
2005년의 개별 저장 공간을 떠올리는 대신 계정 단위로 사용량을 검토할 수 있습니다. 임원 한 명의 첨부파일이 12GB라면 공유 용량에서도 그만큼을 차지합니다. 계정 한도와 적용되는 사용자 할당량은 여전히 유효하므로 보존 정책, 정리와 추가 용량 옵션을 비교한 뒤 요금제를 바꾸십시오.
설정이 비유적으로 500개나 되는 복잡한 콘솔을 선택할 필요는 없습니다. 도메인, 사용자와 메일 테스트부터 시작하되 접근 보안, 보존과 정기 점검도 관리하십시오.
전체 내용은 TrekMail 요금 페이지에서 확인하거나 요금제 개요에서 비교하십시오. 전체 시장을 나란히 비교하려면 소기업용 업무 이메일 선택지 분석을 참조하십시오.
전문 용어 없이 이해하는 MX 레코드
DNS는 추상적이므로 구체적인 비유로 설명하겠습니다.
도메인을 상업용 건물이라고 생각해 보십시오.
- A 레코드는 고객이 웹사이트로 들어오는 정문입니다.
- MX 레코드는 우편물이 도착하는 하역장입니다.
누군가 이메일을 보내면 발신 서버가 전 세계 DNS 디렉터리에서 도메인을 찾고 MX 레코드를 조회합니다.
- 명시적인 MX가 없으면 조건에 따라 도메인의 주소 레코드를 이용할 수 있습니다. 실제 SMTP 서비스 구성에 따라 결과가 달라집니다.
- MX가 이전 호스트를 가리키면 그 호스트가 여전히 의도된 활성 수신 경로인지 확인한 뒤 변경하십시오.
- MX가 올바르면 의도한 호스트를 찾을 수 있습니다. 이후 수신자 구성, 할당량과 필터도 메시지 처리에 영향을 줍니다.
웹사이트 (A 레코드)가 작동해도 메일 경로 (MX 레코드)에는 문제가 있을 수 있습니다. 레코드의 목적은 다르지만 DNS 인프라와 다른 의존성을 공유할 수 있습니다.
전송 성공률을 떨어뜨리는 DNS 실수 5가지
같은 오류가 계속 반복됩니다. 도메인 이메일 설정 후 문제가 있다면 먼저 다음을 확인하십시오.
1. '백업 MX'를 그대로 두기
우선순위 숫자가 더 큰 이전 MX를 검토 없이 '백업'으로 남겨 두지 마십시오. 필터가 약하거나 경로가 잘못된 호스트는 우회 수신 경로가 될 수 있습니다. 다만 승인된 백업이나 하이브리드 구성은 수신자, 필터, 큐와 전달 경로가 일관되게 설정되어 있다면 유효합니다. 폐기하기로 확인된 항목만 제거하십시오.
2. 루트 도메인의 CNAME 충돌
루트 도메인 (@)의 일반 CNAME은 필수 SOA, NS나 MX 레코드와 함께 존재할 수 없습니다. Wix나 Squarespace를 연결할 때는 DNS 제공업체가 지원하는 주소 레코드를 확인하십시오. ALIAS/ANAME이나 flattening은 제공업체별 기능이며 루트에 일반 CNAME을 게시하는 것과는 다릅니다.
3. 전파가 끝나기 전에 레코드 다시 변경
브라우저에서 확인한 결과가 모든 DNS 캐시를 대표하지는 않습니다. 24시간은 계획 예시이지 최대 시간이 아닙니다. 10분 뒤 다시 바꾸면 캐시마다 다른 버전이 남을 수 있지만 전 세계 전파 시계가 초기화되는 것은 아닙니다. 권한 있는 영역과 TTL을 먼저 확인하고 필요한 수정만 기록하며 진행하십시오.
4. SPF 레코드 누락
SPF가 없으면 SMTP 발신 식별자를 SPF로 확인할 수 없습니다. 임의의 예시 대신 실제 허용된 발신자를 반영한 유효한 레코드를 게시하십시오. DKIM과 도메인 정렬, 수신 정책도 확인해야 합니다. 아직 설정하지 않았다면 SPF 레코드 설정 가이드를 참조하십시오.
5. MX 레코드의 잘못된 호스트 이름
MX 레코드를 추가할 때 '호스트' 또는 '이름' 필드는 거의 항상 루트 도메인을 뜻하는 @여야 합니다. mail이나 www를 입력하면 user@mail.yourcompany.com의 메일 경로가 설정되고, user@yourcompany.com의 경로는 설정되지 않습니다. 추가하는 모든 레코드에서 확인하십시오.
먼저 만들 주소
메일함을 무작위로 추가하기 전에 각 주소의 운영 수명 주기를 생각하십시오. 누가 관리하며, 그 사람이 퇴사하면 어떻게 되는지 정해야 합니다.
1. 비상용 관리자 (ops@ 또는 admin@)
한 개인 계정에 모든 권한을 묶는 대신 담당자를 식별할 수 있는 관리자 계정과 보호된 비상 복구 절차를 계획하십시오. 관리 정책에 맞는 역할과 강력한 접근 보안을 적용하고 복구 정보를 안전하게 보관하십시오. 전용 관리자 주소가 도움이 될 수 있지만 인수인계를 위해 지속적인 비밀번호를 공유하지는 마십시오.
2. 기능별 별칭 (info@, support@, hello@)
받은편지함 다섯 개를 따로 확인하고 싶지 않다면 기능별 주소에 별칭을 사용할 수 있는지 검토하십시오. TrekMail에서 info@를 사용 가능한 권한에 따라 기본 메일함으로 전달하는 별칭으로 구성하십시오. info@로 발신하려면 승인된 발신 식별자와 지원되는 SMTP 및 클라이언트 설정이 필요합니다. 설명된 Nano 모델에서는 답장을 포함한 모든 발신에 자체 외부 SMTP 서비스가 필요합니다. 현재 조건과 전달 설정 문서를 확인하십시오.
3. 인프라용 역할 계정 (billing@, marketing@)
SaaS 구독, 광고 플랫폼과 금융 서비스에는 관리되는 역할 주소를 고려하십시오. Facebook Ads 계정이 sarah@yourcompany.com에 연결된 담당자가 퇴사하면 플랫폼 역할, 세션, 앱 권한과 복구 정보를 검토하고 승인된 인계를 진행하십시오. 비밀번호 변경과 메일 전달만으로 충분하지 않을 수 있습니다. 개인 Gmail에서는 복구가 더 오래 걸릴 수 있으며 세 주는 예시일 뿐 고정 지원 기간이 아닙니다.
이름 규칙과 형식 선택
직원이 20명이 되기 전에 이름 형식을 정하십시오. 나중에 이메일 형식을 바꾸면 주소록이 깨지고 수년간 연락한 고객이 혼란을 겪습니다.
| 형식 | 예 | 장점 | 단점 |
|---|---|---|---|
| 이름만 | john@ | 친근하고 기억하기 쉬움 | 이름이 같은 후임 사용자를 위한 추가 규칙 필요 |
| 이름 첫 글자 + 성 | jdoe@ | 일반적인 업무용 형식이며 중복 여부 확인 필요 | 전화로 말하기 불편함 |
| 이름 + 성 첫 글자 | johnd@ | 적절한 절충안 | 여전히 겹칠 수 있음 (John Davis와 John Doe) |
| 전체 이름 | john.doe@ | 전문적이고 식별하기 쉽지만 전체 이름도 중복 가능 | 입력이 길고 오타 가능성이 높음 |
실용적인 권장 사항: 규모가 작고 모두 서로를 안다면 firstname@으로 시작할 수 있습니다. first.last@ 형식도 검토하고 5-10명을 넘기 전에 중복 처리 규칙을 계획하십시오. 사용 가능한 별칭 기능으로 john@을 john.doe@에 연결할 수 있지만 실제 수신과 허용된 발신 설정을 확인해야 합니다. 전환 중 누락이 없다고 가정하지 마십시오.
문제가 생겼을 때 해결 방법
단계를 따랐는데도 작동하지 않을 때 흔히 나타나는 증상과 확인할 항목입니다.
'보낼 수 있지만 받을 수 없습니다.'
원인: MX 경로와 캐시 외에 수신자, 할당량, 큐와 필터도 조사하십시오.
해결: whatsmydns.net의 여러 지역 결과를 권한 있는 DNS 영역과 비교하십시오. 이전 호스트가 나오면 캐시인지 현재 게시된 설정인지 먼저 확인해야 합니다. 그 뒤 수신 서버 로그와 실제 수신 테스트를 조사하십시오.
'받을 수 있지만 보낸 메일이 스팸으로 갑니다.'
원인: 인증뿐 아니라 내용, 평판과 수신 정책도 영향을 줄 수 있습니다.
해결: mail-tester.com으로 대표적인 메시지를 보내고 헤더와 검사 결과를 분석하십시오. 하나의 점수가 모든 수신처의 처리를 입증하지는 않습니다. 이용 조건을 충족한다면 Google Postmaster Tools의 개인 Gmail 트래픽에 대한 집계 자료도 확인하십시오. 이는 모든 메시지의 전송 결과를 보여 주는 도구는 아닙니다. 더 넓은 진단 절차는 이메일의 스팸 분류를 막는 방법 가이드를 참조하십시오.
'Outlook이 계속 비밀번호를 묻습니다.'
원인: 잘못된 포트나 프로토콜, 인증 정보, 계정 정책 또는 레거시 인증과 최신 인증의 차이가 원인일 수 있습니다.
해결: 다음 설정을 확인하십시오.
- IMAP (수신): 포트 993, 암시적 TLS와 인증서 검증. 클라이언트에서는 SSL/TLS로 표시될 수 있습니다
- SMTP (발신): 포트 465 (암시적 TLS의 클라이언트 표기 SSL/TLS) 또는 587 (STARTTLS). 인증서를 검증하고 제공업체가 허용한 인증 방식을 사용하십시오
- 사용자 이름: @domain을 포함한 전체 이메일 주소이며 앞부분만 입력하면 안 됩니다
전체 클라이언트 설정은 Outlook 연결 또는 IMAP 및 SMTP 설정 문서를 참조하십시오.
'550 반송 오류가 발생합니다.'
원인: 영구적인 SMTP 거부이며 실제 이유는 전체 서버 응답에서 확인해야 합니다. 알 수 없는 수신자 외에 인증이나 다른 정책 문제도 가능합니다.
해결: 주소와 전체 응답을 확인하십시오. 직접 관리하는 수신자라면 설정을 검증하고, 다른 조직의 수신자라면 해당 담당 관리자와 조사하십시오. 평판 관련 응답에는 도메인 평판 가이드가 도움이 될 수 있지만 주소가 맞다는 이유만으로 평판이 원인이라고 단정할 수는 없습니다.
마무리
내 도메인으로 이메일을 만드는 것은 디지털 기반의 운영 책임을 직접 맡는 일입니다. 자체 도메인의 메일 식별자를 관리하는 것이지 제공업체의 인프라까지 소유하는 것은 아닙니다.
목표는 의도된 경로, 적절한 인증과 복구 계획을 갖춘 관리 가능한 시스템입니다. 변경 뒤에는 권한 있는 DNS와 실제 메시지를 확인하고 허용된 발신 경로를 관리하며 이용 가능한 DMARC 보고서를 검토하십시오. 초기 설정이 올바르더라도 정기 관리가 필요하고 전송 성공이 보장되지는 않습니다.
메일이 주된 요구이고 Google Calendar나 SharePoint를 쓰지 않는다면 TrekMail을 대안으로 비교하십시오. 현재 계정 요금, 공유 용량, 사용자 한도와 지원되는 IMAP 및 SMTP 클라이언트를 확인해야 합니다. 무료 모델은 현재 제공 조건에 따르며 설명된 Nano 모델의 모든 발신과 답장에는 자체 외부 SMTP가 필요합니다. 유료 관리형 발신도 실제 요금제 권한과 클라이언트 설정에 따라 이용하십시오.
도메인과 레코드, 데이터를 직접 관리하십시오.