네트워크
DNS 레코드 유형 참고 가이드
메일·웹사이트 운영에 필요한 DNS 레코드 유형(A, MX, TXT, SPF, DKIM, DMARC 등)의 목적·서식 예시·주의점을 정리한 레퍼런스입니다.
DNS 레코드 유형 목록
| 유형 | 목적 | 서식 예시 | 주의점 |
|---|---|---|---|
| A 레코드 | 도메인 이름을 IPv4 주소에 연결하는 가장 기본적인 레코드입니다. 웹 서버나 메일 서버가 실제로 위치한 IP 주소를 가리킵니다. | example.com. 3600 IN A 192.0.2.1 |
TTL(이 예시에서는 3600초 = 1시간)을 너무 짧게 하면 권한 있는 DNS 서버에 대한 조회가 늘어 부하가 커지고, 너무 길게 하면 IP 주소 변경 시 반영이 늦어집니다. |
| AAAA 레코드 | 도메인 이름을 IPv6 주소에 연결하는 레코드로, A 레코드의 IPv6 버전에 해당합니다. | example.com. 3600 IN AAAA 2001:db8::1 |
A 레코드를 함께 두면 IPv6를 지원하지 않는 네트워크에서도 IPv4 연결로 대체(폴백)할 수 있습니다(듀얼 스택 운영). |
| CNAME 레코드 | 특정 호스트 이름을 다른 정식 호스트 이름의 별칭(alias)으로 취급하는 레코드입니다. 예를 들어 www.example.com을 example.com의 별칭으로 지정할 때 사용합니다. | www.example.com. 3600 IN CNAME example.com. |
CNAME이 설정된 호스트 이름에는 MX나 TXT 같은 다른 레코드를 함께 둘 수 없습니다(RFC 1034의 제약). 또한 존(zone)의 루트(@)에는 CNAME을 설정할 수 없습니다. |
| MX 레코드 | 해당 도메인으로 오는 메일을 어느 메일 서버가 받을지 지정하는 레코드입니다. 우선순위(preference 값)와 함께 여러 대를 지정할 수 있습니다. | example.com. 3600 IN MX 10 mail.example.com. |
값이 작을수록 우선순위가 높습니다. 이중화를 위해 서로 다른 우선순위로 여러 서버를 지정하는 것이 일반적입니다. MX가 가리키는 대상은 CNAME이 아니라 A 레코드를 가진 호스트 이름이어야 합니다. |
| TXT 레코드 | 도메인에 임의의 텍스트 정보를 담는 범용 레코드입니다. SPF·DKIM·DMARC는 물론 도메인 소유권 확인 등 다양한 용도로 사용됩니다. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
하나의 도메인에 여러 개의 TXT 레코드를 둘 수 있지만, 같은 용도(예: SPF)의 레코드를 여러 개 두면 해석 오류가 발생하므로 하나로 통합해야 합니다. |
| SPF 레코드(TXT 레코드의 일종) | 해당 도메인 명의로 메일을 보낼 수 있도록 허용된 발신 서버(IP 주소)를 나열하여 스푸핑(발신자 위조) 메일을 방지하는 발신 도메인 인증 방식입니다. TXT 레코드로 설정합니다. | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
SPF 레코드는 도메인당 하나만 유효합니다. DNS 조회 횟수 제한(10회)을 초과하면 영구 오류가 발생하므로 include 연쇄에 주의해야 합니다. 전용 레코드 유형(RRTYPE 99)은 2014년에 폐지되어 현재는 TXT 레코드만으로 SPF를 표현합니다. |
| DKIM 레코드(TXT 레코드의 일종) | 메일에 전자 서명을 첨부하여 전송 중 변조되지 않았음과 정당한 발신자로부터 왔음을 검증하는 방식입니다. 공개 키를 TXT 레코드로 공개합니다. | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
호스트 이름 앞부분(셀렉터)은 메일 서비스마다 다른 문자열이 할당됩니다. 개인 키는 발신 서버 쪽에서 보관하고, DNS에는 공개 키만 공개합니다. |
| DMARC 레코드(TXT 레코드의 일종) | SPF·DKIM 검증 결과를 바탕으로 인증에 실패한 메일을 어떻게 처리할지(그대로 전달·격리·거부)를 정책으로 선언하고, 결과 보고서를 받는 방식입니다. | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
p=none으로 시작해 모니터링만 하다가 문제가 없음을 확인한 뒤 quarantine·reject로 단계적으로 정책을 강화하는 것이 안전한 도입 절차입니다. |
| NS 레코드 | 해당 도메인(존)의 권한 있는 DNS 서버가 어디인지 나타내는 레코드입니다. 도메인 전체 이름 해석의 출발점이 됩니다. | example.com. 86400 IN NS ns1.example-dns.com. |
등록기관(레지스트라)에 등록된 네임서버와 존 내부의 NS 레코드가 일치하지 않으면 이름 해석이 불안정해집니다(레임 위임, lame delegation). |
| SOA 레코드 | 존의 관리 정보(기본 서버, 관리자 이메일, 일련번호, 재시도 간격 등)를 담는, 존마다 반드시 하나 존재해야 하는 필수 레코드입니다. | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
존 파일을 업데이트하면 반드시 일련번호를 증가시켜야 하며, 그렇지 않으면 보조 서버에 변경 사항이 존 전송을 통해 반영되지 않습니다. |
| CAA 레코드 | 해당 도메인에 대해 인증서를 발급할 수 있는 인증 기관(CA)을 제한하여, 의도하지 않은 CA가 부정한 인증서를 발급하는 것을 방지하는 레코드입니다. | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
CAA 레코드가 하나도 없으면 어떤 CA든 발급 가능한 것으로 간주됩니다. 와일드카드 인증서에는 issuewild 태그를 별도로 지정해야 합니다. |
| PTR 레코드 | IP 주소로부터 호스트 이름을 역방향으로 조회하는 레코드입니다(A 레코드의 반대 방향). 역방향 존(in-addr.arpa / ip6.arpa)에 설정합니다. | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
많은 메일 서버가 역방향 PTR이 설정되지 않았거나 A 레코드와 일치하지 않는 발신지의 메일을 스팸으로 판정하거나 거부하기 때문에, 메일 발신 서버에는 사실상 필수적인 설정입니다. |
Tips
- SPF·DKIM·DMARC 설정이 헷갈린다면 먼저 "SPF/DKIM/DMARC 레코드 확인" 도구로 현재 레코드를 진단한 뒤 이 페이지의 서식 예시와 비교하면 효율적입니다.
- 일반적인 레코드의 TTL은 1시간(3600초) 정도가 무난하며, DNS 이전 작업 직전에만 300초 정도로 줄여두면 전환 후 반영이 빨라집니다.
- TXT 레코드 값이 255자를 넘으면 여러 문자열로 자동 분할되는 경우가 있으므로, 복사 붙여넣기 시 따옴표 개수가 어긋나지 않았는지 확인하세요.
- 이메일 주소 자체의 형식을 확인하고 싶다면 "이메일 주소 형식 검사" 도구를 함께 사용하면 놓치는 부분을 줄일 수 있습니다.
- 새로운 메일 발송 서비스를 도입할 때는 먼저 DMARC를 p=none으로 운영하며 1~2주간 보고서를 확인한 뒤, 문제가 없음을 확인하고 나서 실제 정책으로 전환하는 것이 안전합니다.
자주 묻는 질문
SPF는 "어느 서버에서 발송되었는가"라는 IP 주소의 정당성을 검증하는 방식이고, DKIM은 "메일 내용이 변조되지 않았는가"를 전자 서명으로 검증하는 방식입니다. 둘 다 통과해야 비로소 발신 도메인 인증으로서 충분한 효과를 발휘합니다.
법적으로 의무 사항은 아니지만, Gmail이나 야후 메일 등 주요 수신 서버는 대량 발송자에 대해 사실상 DMARC 설정을 필수화하고 있어, 설정하지 않으면 스팸 판정이나 전송 거부 위험이 커집니다.
MX가 가리키는 대상이 CNAME으로 되어 있거나, 우선순위 값이 잘못 설정되어 있거나, 메일 서버 쪽에서 해당 도메인 앞으로 오는 메일을 받도록 설정되어 있지 않은 것이 주요 원인일 수 있습니다.
IP 주소가 고정되어 있고 도메인 루트(@)에 설정하고 싶다면 A/AAAA 레코드를, 다른 호스트 이름의 별칭으로 다루고 싶다면(CDN 주소를 가리키는 경우 등) CNAME을 사용하는 것이 기본입니다.
평소 운영 시에는 1시간(3600초) 정도가 일반적입니다. 서버 이전이나 DNS 전환 직전에만 300초 정도로 줄여두면 전환 후 반영이 빨라집니다.
여담 ― DNS 레코드와 메일 인증의 역사
DNS는 도메인 이름을 IP 주소에 연결하는 구조로 잘 알려져 있지만, 실제로는 A·AAAA 레코드 외에도 다양한 유형이 정의되어 있으며 각각 다른 역할을 담당합니다. 특히 메일 전송의 세계에서는 MX·TXT(SPF/DKIM/DMARC를 담는)·PTR 등 여러 레코드가 함께 작동해야 비로소 "위조되지 않은 정당한 메일"로 판정되며, 하나라도 빠지면 스팸함으로 분류되거나 전송이 거부될 위험이 커집니다.
발신 도메인 인증의 역사를 되짚어 보면, SPF는 2000년대 초반 스팸 대책으로 제안되었고, 이후 메일 본문의 변조 탐지를 목적으로 한 DKIM이 2007년경 표준화되었습니다. 그러나 둘 다 각각만으로는 "인증에 실패했을 때 어떻게 처리할지"를 정하지 않았고, 그 공백을 메우기 위해 2012년 DMARC가 등장했습니다. DMARC는 SPF·DKIM의 결과를 종합적으로 평가하고 실패 시 정책과 결과 보고 체계를 제공하는, 말하자면 "인증의 사령탑" 역할을 합니다.
DNS 레코드 중에는 역사적 경위로 사양이 바뀐 것도 있습니다. 예를 들어 SPF 전용 레코드 유형(RRTYPE 99)은 2006년 RFC에서 한 차례 정의되었지만 구현상 혼란을 일으켜 2014년 RFC 7208에 의해 공식적으로 폐지되었고, 현재는 TXT 레코드만으로 SPF를 표현하는 것이 표준입니다. 마찬가지로 DKIM과 DMARC도 전용 레코드 유형을 갖지 않으며, 모두 특정 서식(v=DKIM1, v=DMARC1로 시작하는 문자열)을 TXT 레코드 안에 담는 형태로 구현되어 있다는 점도 DNS의 확장성이 얼마나 높은지를 보여줍니다.