메일 도메인은 이메일을 받고 보내도록 설정한 일반 도메인 이름(yourcompany.com)입니다. 구성 요소는 MX, SPF, DKIM, DMARC라는 네 가지 DNS 레코드입니다. 각 레코드는 하나의 역할을 하며, 네 레코드가 함께 웹사이트만 있던 도메인을 메일을 안정적으로 처리할 수 있는 도메인으로 만듭니다.
대부분의 "메일 도메인" 설명은 레코드별 안내를 생략해 운영자가 DNS를 막연하고 어려운 것으로 느끼게 합니다. 실제로는 그렇지 않습니다. 네 레코드는 구문이 정해진 간단한 텍스트 항목이며 누구나 DNS 대시보드에서 게시할 수 있습니다. 각 레코드의 역할을 이해하면 나머지 설정도 명확해집니다.
이 가이드는 네 레코드의 역할과 구문을 차례로 설명합니다. 더 넓은 맥락은 사용자 지정 도메인 이메일을 참고하세요.
메일 도메인의 정확한 의미
기존 설정에 네 가지 DNS 레코드를 추가하면 모든 도메인 이름에서 이메일을 처리할 수 있습니다. MX는 메일 서버를 가리킵니다. SPF는 승인된 발신자를 나열합니다. DKIM은 외부 발송 메일에 암호화 서명을 합니다. DMARC는 인증 실패 시 수신 시스템이 취할 수 있는 조치를 알립니다. 네 레코드가 함께 아무 설정도 없는 도메인을 제대로 작동하는 메일 도메인으로 만듭니다.
같은 도메인의 루트에서 웹사이트를 호스팅하고 그 도메인의 주소로 메일을 제공할 수 있습니다. 네 레코드는 서로 다른 목적에 서로 다른 레코드 유형을 사용하므로 웹사이트 레코드와 충돌하지 않습니다. 실제로 운영되는 메일 도메인 대부분에는 웹사이트도 있습니다. 두 서비스는 서로 다른 제공업체에 있을 수 있으며 DNS를 통해 조정됩니다. 메일을 새 호스트로 옮길 때는 메일 관련 레코드만 업데이트하면 되고 웹사이트 레코드는 그대로 유지됩니다.
네 가지 DNS 레코드 한눈에 보기
네 가지 DNS 레코드가 작동하는 메일 도메인을 정의합니다. 각 레코드에는 구체적인 역할과 구문이 있습니다. 사서함 호스트가 정확한 값을 생성하면 이를 DNS 호스트에 게시합니다. 표는 각 레코드의 역할과 DNS 트리에서의 위치를 요약합니다.
| 레코드 | 역할 | 위치 | 필수 여부 |
|---|---|---|---|
| MX | 수신 메일을 사서함 호스트로 라우팅 | yourcompany.com (루트) | 예 - 없으면 수신 메일이 도착하지 않음 |
| SPF | 승인된 외부 발송자를 나열 | yourcompany.com (루트, TXT) | 예 - 없으면 스팸 판정 위험이 커짐 |
| DKIM | 외부 발송 메일에 암호화 서명 | selector._domainkey.yourcompany.com (TXT) | 예 - 없으면 정렬에 실패할 수 있음 |
| DMARC | 수신 시스템에 인증 실패 처리 방법을 알림 | _dmarc.yourcompany.com (TXT) | 강력 권장 - 없으면 스푸핑이 보고되지 않을 수 있음 |
네 레코드는 DNS 호스트 비용 외에는 별도 비용이 들지 않으며 Cloudflare에서는 무료로 사용할 수 있습니다. 사서함 호스트가 값을 생성한 뒤 설정에는 약 15분이 걸립니다. 올바른 설정은 받은편지함 도달, 스푸핑 보고서 확인, 최신 수신 시스템의 검사를 통과할 수 있는 인증을 지원합니다.
레코드 1: MX (메일이 가는 곳)
MX는 수신 메일을 받는 메일 서버를 가리킵니다. 레코드 형식은 우선순위 숫자와 서버 호스트 이름의 조합입니다. 우선순위가 다른 여러 MX 레코드는 장애 조치를 제공합니다. 수신 시스템은 가장 낮은 우선순위 값을 먼저 시도하고 필요하면 더 높은 숫자로 넘어갑니다.
TrekMail 호스팅 메일 도메인의 일반적인 값은 10 mx1.trekmail.net과 20 mx2.trekmail.net입니다. 사서함 호스트가 정확한 값을 제공하면 이를 모두 DNS 호스트에 게시하세요. 백업 없이 기본 레코드만 게시하면 드물게 기본 서버를 사용할 수 없을 때 메일이 재시도 대기열에 들어가지 않고 반송될 수 있습니다.
레코드 2: SPF (보낼 수 있는 주체)
SPF는 도메인에서 보낸다고 표시된 메일을 발송할 수 있는 서버를 선언합니다. 레코드는 도메인 루트의 단일 TXT 항목이며 v=spf1 include:_spf.trekmail.net ~all과 같은 구문을 사용합니다. 각 include: 지시문은 실제 발송 IP를 나열한 다른 SPF 레코드를 가리킵니다. 잘못 구성하면 합법적인 메일이 눈에 띄지 않게 실패할 수 있습니다.
마케팅 플랫폼, 거래 메일 발신자, 지원 티켓 도구처럼 도메인에서 메일을 보내는 모든 외부 서비스는 IP를 직접 지정하거나 include를 통해 SPF에 포함해야 합니다. 전체 확인 트리는 10번 미만의 DNS 조회를 유지해야 합니다. 분기마다 SPF 레코드를 감사해 합법적인 메일이 반송되기 전에 조회 한도 증가를 파악하세요. 더 자세한 과정은 SPF, DKIM, DMARC 이메일 인증을 참고하세요.
레코드 3: DKIM (암호화 서명)
DKIM은 수신 시스템이 외부 발송 메일의 서명을 확인할 때 사용하는 공개 키를 보관합니다. 사서함 호스트는 해당 개인 키로 모든 메시지에 서명하고, 수신 시스템은 DNS의 공개 키와 서명을 대조합니다. 서명이 유효하면 발신자가 도메인을 제어한다는 사실을 확인할 수 있습니다.
DKIM 레코드는 선택기별 하위 도메인에 게시됩니다. TrekMail 선택기는 trekmail._domainkey.yourcompany.com, Mailgun 선택기는 mailgun._domainkey.yourcompany.com과 같은 식입니다. 각 값은 줄바꿈 없이 하나의 연속된 TXT 값으로 붙여넣어야 하는 긴 base64 문자열입니다. 여러 선택기는 함께 존재할 수 있으며 메일 도메인에 서명하는 각 서비스가 자체 선택기를 가집니다. 자세한 내용은 DKIM 설정을 참고하세요.
많은 운영자는 처음에 발신자별 패턴을 놓칩니다. 최초 설정 후 여섯 달 뒤 추가한 새 마케팅 플랫폼에는 자체 선택기가 필요합니다. 일 년 뒤 추가한 거래 메일 발신자도 마찬가지입니다. 발신자별 적용이 없으면 메일 도메인 자체의 SPF/DKIM/DMARC 구성이 깨끗하더라도 정렬이 눈에 띄지 않게 실패하고 해당 서비스의 메일이 스팸으로 분류될 수 있습니다. 활성 발신자마다 DKIM 레코드 하나를 두는 것이 해결책입니다.
레코드 4: DMARC (정책과 보고서)
DMARC는 SPF 또는 DKIM 실패 시 수신 시스템이 취할 수 있는 조치를 알립니다. 레코드는 _dmarc.yourcompany.com의 TXT 항목이며 v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com과 같은 구문을 사용합니다. p= 값은 정책을 none, quarantine, reject 중 하나로 설정합니다. rua= 주소는 집계 보고서를 받습니다.
감사 기간 두 주 동안 p=none으로 시작하세요. 보고서는 메일 도메인에서 보낸다고 주장하는 모든 IP와 정렬 성공 여부를 보여 줍니다. 두 주 동안 보고서가 깨끗하면 p=quarantine으로 강화할 수 있습니다. 한 달이 더 지나면 p=reject로 강화할 수 있습니다. 단계적인 적용은 아직 인증하지 않은 발신자를 발견할 수 있는 감사 기간에 합법적인 메일이 반송될 위험을 줄입니다.
네 레코드가 함께 작동하는 방식
네 레코드는 하나의 스택으로 작동합니다. MX는 수신 메일을 올바른 서버로 보냅니다. SPF는 합법적인 외부 발송자를 선언합니다. DKIM을 통해 수신 시스템은 암호화 서명을 확인합니다. DMARC는 SPF와 DKIM을 연결하고 둘 중 하나가 실패할 때 취할 수 있는 조치를 알립니다.
스택이 작동하게 하는 것은 상호작용입니다. DKIM 없는 SPF는 많은 외부 발송 메일이 DMARC 정렬에 실패하게 할 수 있습니다. 정렬은 보통 SPF보다 DKIM을 확인하기 때문입니다. DMARC 없는 DKIM은 DKIM 실패 시 적용할 게시 정책을 제공하지 않습니다. SPF와 DKIM을 제대로 적용하지 않고 p=reject를 사용하는 DMARC는 합법적인 메일을 반송시킬 수 있습니다. 네 레코드는 함께 설정해야 하며 일부만 적용하면 전달 가능성을 점진적으로 높이기보다 해칠 수 있습니다.
TrekMail이 네 레코드를 생성하는 방식
TrekMail은 도메인 설정 중 네 레코드의 정확한 값을 생성합니다. 대시보드에 도메인을 추가하면 플랫폼이 TrekMail 메일 서버를 가리키는 MX 값, _spf.trekmail.net을 포함한 SPF, 새로 생성한 키와 TrekMail 전용 선택기를 사용하는 DKIM, 기본 보고 주소와 p=none을 사용하는 DMARC를 생성합니다. 각 값을 DNS 호스트의 대시보드에 복사해 붙여넣습니다.
플랫폼은 운영자별로 달라지지 않는 부분을 처리합니다. SPF include 경로, DKIM 키 생성, 키 순환 일정, DMARC 보고서 집계입니다. 운영자는 달라지는 부분을 처리합니다. 레코드를 게시할 DNS 호스트, DMARC 보고서를 받을 사서함, DMARC 정책을 강화할 시점입니다. 더 넓은 맥락은 도메인 이메일을 참고하세요.
다음 단계
작동하는 메일 도메인은 직접 관리하는 DNS 호스트에 올바르게 게시한 네 가지 DNS 레코드로 이루어집니다. MX는 수신 메일을 라우팅하고 SPF는 승인된 발신자를 선언합니다. DKIM은 외부 발송 메일에 서명하고 DMARC는 정책과 보고 기능으로 모두 연결합니다. 네 레코드를 게시하는 데는 약 15분이 걸리며 분기별 감사 원칙을 지키면 장기간 안정적인 받은편지함 도달을 지원할 수 있습니다.
trekmail.net/pricing에서 카드 없이, 체험 만료 없이 TrekMail Nano를 무료로 사용해 보세요. Nano 요금제는 10개 도메인 × 10개 사서함을 지원합니다. Starter는 발송량이 Nano 한도를 넘으면 $4/month에 50 × 100으로 확장합니다.
네 레코드에는 "한 번 설정하고 분기마다 감사"하는 원칙이 유용합니다. MX는 설정 후 거의 바뀌지 않습니다. SPF에는 운영 조직이 마케팅 플랫폼과 거래 서비스를 추가하면서 수개월에 걸쳐 새 발신자가 쌓입니다. 많은 플랫폼에서 DKIM 키는 자동으로 순환됩니다. DMARC 보고서는 계속 유입되어 합법적인 발신자의 변화와 스푸핑 시도를 모두 보여 줍니다. 분기별 감사는 부담이 적고 최초 설정 후 레코드를 방치할 때 발생할 수 있는 전달 가능성 문제를 예방하는 데 도움이 됩니다.
여러 브랜드 도메인을 보유한 운영자는 각 메일 도메인에 네 레코드를 개별적으로 설정합니다. MX 값은 같은 사서함 호스트를 가리키며 SPF, DKIM, DMARC 레코드는 도메인별로 게시합니다. TrekMail의 대량 도메인 엔드포인트는 한 번에 최대 500개 도메인을 처리해 에이전시 규모 운영의 도메인별 설정을 크게 줄일 수 있습니다.
네 레코드 체계는 문제가 생겼을 때 진단 순서로도 쓸 수 있습니다. 수신 메일이 오지 않나요? MX를 확인하세요. 외부 발송 메일이 스팸에 들어가나요? SPF와 DKIM을 확인하세요. 스푸핑 보고서가 몰려오나요? DMARC 정책을 확인하세요. 각 장애 유형이 하나의 구체적인 레코드를 가리키므로 문제를 빠르게 좁힐 수 있습니다.
