"내 도메인을 이메일에 사용"하는 작업은 yourcompany.com을 웹사이트 주소에서 실제로 작동하는 이메일 목적지로 바꿉니다. 전체 설정 과정에는 DNS 레코드, 사서함 프로비저닝, 인증, 검증이 포함됩니다. 서버를 관리할 필요 없이 대시보드에서 조작하고 DNS 레코드를 복사해 붙여 넣는 다섯 가지 구체적인 단계로 구성되며, 운영자라면 오후 한 번에 마칠 수 있습니다.
대부분의 설정 안내서는 특정 서비스의 대시보드 하나만 다룹니다. 아래 다섯 단계는 서비스에 종속되지 않으며 TrekMail, Workspace, Zoho 또는 신뢰할 수 있는 모든 사서함 호스트에 적용됩니다. 단계를 구분해 설명하면 의존 관계를 명확히 알 수 있습니다.
이 안내서에서는 각 단계의 구체적인 확인 사항과 함께 전체 설정 과정을 설명합니다. 더 폭넓은 안내는 도메인으로 이메일을 만드는 방법을 참고하십시오.
"내 도메인을 이메일에 사용"한다는 말의 실제 의미
내 도메인을 이메일에 사용하려면 수신 메일을 사서함 호스트로 전달하는 DNS 레코드를 설정하고, 수신자가 신뢰할 수 있도록 발신 메일을 인증해야 합니다. 설정에는 MX, SPF, DKIM, DMARC와 도메인 검증용 TXT까지 다섯 개의 DNS 레코드가 필요합니다. 각 레코드는 역할과 형식이 다릅니다.
사서함 호스트가 값을 제공하면 사용자가 DNS 호스트에 게시합니다. 전체 설정은 서비스에 종속되지 않습니다. 메일이 TrekMail, Workspace 또는 다른 신뢰할 수 있는 호스트에 도착하더라도 같은 다섯 레코드를 사용합니다. 나중에 사서함 호스트를 바꿀 때도 같은 다섯 레코드가 새 호스트를 가리키도록 업데이트하면 됩니다.
다섯 가지 설정 단계
내 도메인을 이메일에 사용하는 데 필요한 모든 작업은 다섯 단계로 이루어집니다. 순서가 중요합니다. 인증보다 MX가 먼저이고, 테스트보다 인증이 먼저이며, DMARC 강화보다 테스트가 먼저입니다. 각 단계의 결과는 다음 단계에 쓰입니다. 하나라도 건너뛰면 그 단계 자체보다 해결하는 데 오래 걸리는 후속 장애가 생깁니다.
- MX 레코드를 사서함 호스트로 연결합니다. 우선순위 값이 있는 MX 레코드 두 개 또는 세 개입니다.
- SPF 레코드를 게시합니다. 승인된 발신자를 나열하는 TXT 레코드 한 개입니다.
- 발신자별 DKIM을 게시합니다. 메일 서명 서비스마다 TXT 레코드 한 개입니다.
- p=none으로 DMARC를 게시합니다. 보고서 수신 주소가 포함된 TXT 레코드 한 개입니다.
- 왕복 테스트 후 DMARC를 강화합니다. 수신처 세 곳에서 PASS를 확인한 뒤 두 주 후 DMARC를 p=quarantine으로 변경합니다.
내 도메인을 이메일에 사용하는 규모가 사서함 1개이든 1,000개이든 다섯 단계의 순서는 같습니다. 레코드는 사서함 수가 아니라 발신자 수에 따라 늘어납니다. 사서함을 추가할 때는 새 DNS 레코드가 필요하지 않지만 마케팅 플랫폼, 트랜잭션 서비스, CRM 같은 외부 발신자를 추가할 때는 필요합니다. 새 발신자마다 자체 DKIM selector가 있어야 합니다.
단계 1: MX 레코드를 사서함 호스트로 연결
내 도메인을 이메일에 사용하는 첫 단계는 사서함 호스트의 메일 서버를 가리키는 MX 레코드를 게시하는 것입니다. 사서함 호스트는 장애 조치 순서를 나타내는 우선순위 번호 (10, 20, 30)가 지정된 MX 값 두 개 또는 세 개를 제공합니다. 수신 서버는 우선순위 값이 가장 낮은 서버부터 시도하고, 해당 서버를 사용할 수 없으면 더 높은 번호로 넘어갑니다.
사서함 호스트가 제공하는 MX 값을 모두 게시하십시오. 우선순위가 가장 낮은 값만 게시해서는 안 됩니다. 기본 메일 서버가 오프라인이 되는 드문 사고가 발생할 때 이중화가 중요합니다. 예비 MX 레코드가 없으면 장애 중 수신 메일이 재시도 대기열에 들어가지 않고 반송됩니다.
단계 2: SPF 레코드 게시
내 도메인을 이메일에 사용하는 두 번째 단계는 SPF 레코드입니다. SPF는 어떤 서버가 귀하의 도메인에서 보낸 것으로 표시되는 메일을 발송할 수 있는지 선언합니다. TrekMail로 호스팅하고 발송에도 TrekMail만 사용하는 설정이라면 도메인 루트에 v=spf1 include:_spf.trekmail.net ~all과 같은 구문의 TXT 항목 하나를 둡니다.
마케팅 플랫폼이나 트랜잭션 서비스 등 다른 발신자가 있다면 해당 SPF 레코드도 포함하십시오. 각 include: 지시어는 DNS 조회 한 번으로 계산되며 전체 조회 트리의 합계는 10회 미만이어야 합니다. 분기마다 SPF 레코드를 감사하여 조회 한도가 서서히 초과되는 상황을 파악하고 정상 메일이 반송되기 전에 조치하십시오.
단계 3: 발신자별 DKIM 게시
내 도메인을 이메일에 사용하는 세 번째 단계는 DKIM입니다. 이는 발신 메일에 암호화 서명을 추가하여 수신자가 검증할 수 있게 합니다. 귀하의 도메인을 "발신" 주소로 사용하는 모든 서비스에는 고유한 selector 아래에 자체 DKIM 레코드가 필요합니다. 사서함 호스트는 자체 DKIM 레코드를 생성하며 마케팅 플랫폼과 트랜잭션 발신자는 각자의 레코드를 제공합니다.
레코드는 selector별 하위 도메인 아래에 TXT 항목으로 게시합니다. TrekMail selector에는 trekmail._domainkey.yourcompany.com, Mailgun selector에는 mailgun._domainkey.yourcompany.com을 사용하는 식입니다. 각 항목은 줄바꿈 없이 하나로 이어진 TXT 값으로 붙여 넣어야 하는 긴 base64 문자열입니다. 인증에 관한 자세한 설명은 SPF, DKIM, DMARC 이메일 인증을 참고하십시오.
단계 4: p=none으로 DMARC 게시
내 도메인을 이메일에 사용하는 네 번째 단계는 DMARC입니다. 이는 SPF 또는 DKIM이 실패할 때 무엇을 해야 하는지 수신자에게 알립니다. 두 주 동안 p=none으로 시작하십시오. 보고서에는 귀하의 도메인을 주장하는 모든 IP, SPF/DKIM 결과, alignment 충족 여부가 나타납니다. 이 감사로 두 번째 단계에서 빠뜨린 정상 발신자를 찾아낼 수 있습니다.
DMARC 레코드 형식은 v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com입니다. rua 주소는 실제로 보고서를 읽을 사서함으로 바꾸십시오. p=none에서 문제가 없는 보고서를 두 주 동안 확인한 뒤 p=quarantine으로 강화하십시오. 그 후에도 한 달간 보고서가 정상이면 p=reject로 강화하십시오. 이렇게 단계적으로 정책을 적용하면 감사 기간에 정상 메일이 반송되는 일을 막을 수 있습니다.
단계 5: 왕복 테스트 후 DMARC 강화
내 도메인을 이메일에 사용하는 다섯 번째 단계는 왕복 테스트입니다. 새 사서함에서 Gmail, Outlook.com, Yahoo 주소로 메일을 보내십시오. 받은 메시지를 각각 열고 헤더를 확인합니다. 세 곳 모두 SPF=PASS, DKIM=PASS, DMARC=PASS로 표시되어야 합니다. FAIL이 하나라도 있으면 실제 트래픽을 처리하기 전에 레코드를 수정해야 합니다.
모든 항목이 통과하고 p=none 상태의 DMARC 보고서가 두 주 동안 정상이면 p=quarantine으로 강화하십시오. 격리 상태에서도 한 달간 보고서가 정상이면 p=reject로 강화하십시오. 안정된 설정에 적합한 DMARC 정책은 p=reject를 유지하며 매달 보고서를 검토하는 것입니다. 다른 관점의 안내는 내 도메인에 이메일 설정하기를 참고하십시오.
정책을 단계적으로 적용하는 이유는 첫 주부터 p=reject를 사용하면 아직 인증하지 않은 발신자의 정상 메일까지 반송될 수 있기 때문입니다. p=none으로 진행하는 두 주간의 감사에서 보고서를 통해 모든 정상 발신자를 확인할 수 있습니다. p=quarantine으로 보내는 한 달 동안 수정 사항이 유지되는지 확인합니다. 그 이후에야 p=reject를 안전하게 적용할 수 있습니다. 단계를 건너뛰면 정상 메일이 중단되고, 잘못 설정된 발신자가 아니라 귀하에게 고객 불만이 향하게 됩니다.
내 도메인을 이메일에 사용하면서 이 단계를 건너뛴 운영자는 며칠 안에 대가를 치르는 경우가 많습니다. DMARC 보고서 대기열이 격리된 메시지로 넘쳐나고 수신 답장이 더 이상 들어오지 않습니다. 해결하려면 p=none으로 되돌리고 감사 기간을 다시 시작해야 합니다. 처음에 건너뛰어 아낀 시간보다 더 많은 시간을 잃을 수 있습니다.
다중 발신자 설정
내 도메인을 이메일에 사용할 때 여러 발신자 때문에 생기는 문제는 귀하의 도메인으로 메일에 서명하는 외부 서비스마다 DNS 호스트에 자체 DKIM selector가 필요하다는 점입니다. 마케팅 플랫폼, 트랜잭션 서비스, CRM 도구, 지원 티켓 시스템은 모두 귀하의 도메인에 alignment되도록 각자의 selector가 필요합니다.
이 문제가 가장 흔히 발생하는 상황은 사서함 호스트 하나로 시작한 소규모 조직이 여섯 달 뒤 마케팅 플랫폼을 추가하고, 이어 트랜잭션 발신자와 이메일 기능이 내장된 CRM을 차례로 도입하는 경우입니다. 추가할 때마다 자체 DKIM selector를 설정해야 합니다. 이를 모르는 운영자는 적절한 인증 없이 서비스가 늘어날수록 받은편지함 도달률이 서서히 떨어지는 상황을 겪습니다.
발신자별 DKIM이 없으면 해당 서비스의 메일은 DKIM 자체는 기술적으로 통과하더라도 alignment에는 실패합니다. 귀하의 도메인이 아니라 서비스 자체 도메인으로 서명하기 때문입니다. DMARC 집계 보고서는 활성화 후 며칠 안에 이 불일치를 보여 줍니다. 각 서비스가 귀하의 도메인으로 서명하도록 selector를 설정하면 해결됩니다. 번거롭지만 발신자마다 한 번만 하면 되는 작업입니다.
다음 단계
내 도메인을 이메일에 사용하는 전체 설정은 총 두 시간 정도 걸리며, 메일이 받은편지함에 안정적으로 도착할 수 있는 기반을 만듭니다. MX, SPF, DKIM, DMARC라는 다섯 DNS 레코드를 설정하고 왕복 테스트를 진행합니다. 사서함이 1개이든 1,000개이든 같은 순서를 적용합니다.
trekmail.net/pricing에서 카드 없이 TrekMail Nano를 무료로 사용해 보십시오. Nano 요금제는 10개 도메인 × 10개 사서함을 제공하며, 발송량이 늘어나면 Starter에서 50 × 100으로 확장할 수 있습니다. 개념적인 설명은 사용자 지정 도메인 이메일을 참고하십시오.
최초 다섯 단계를 마친 뒤 설정을 유지하는 데 필요한 작업은 많지 않습니다. 매달 DMARC 보고서를 읽어 승인되지 않은 발신자가 귀하의 도메인을 사용하고 있지 않은지 확인하십시오. 분기마다 SPF를 감사하여 조회 한도가 서서히 초과되는 상황을 파악하고 정상 메일이 반송되기 전에 조치하십시오. 매년 DKIM rotation을 확인하십시오. TrekMail은 모든 요금제에서 이를 자동으로 처리하지만 실제 실행 여부를 확인하는 것이 좋습니다. 연간 유지 관리 시간은 대체로 30분 미만이므로 전담 인프라 인력 없이도 여러 브랜드에서 도메인을 이메일에 실용적으로 사용할 수 있습니다.
여러 도메인을 운영하는 경우 도메인 간에 공유되는 상태 없이 도메인마다 다섯 단계를 반복합니다. 각 도메인은 자체 MX, SPF, DKIM, DMARC 레코드를 가집니다. TrekMail의 bulk-domain endpoint는 한 번에 최대 500개 도메인을 처리하므로 에이전시 규모의 운영에서 도메인별 프로비저닝 작업을 며칠에서 몇 시간으로 줄일 수 있습니다.
