DNS 레코드 설정 완벽 가이드 MX SPF DKIM DMARC

이메일 서버 운영에 필수적인 DNS 레코드 설정을 다룹니다. MX, SPF, DKIM, DMARC 등 이메일 인증 레코드의 개념과 설정 방법을 초급 개발자도 이해할 수 있도록 쉽게 설명합니다.

---

목차

1. MX_레코드_설정_및_우선순위
2. SPF_레코드로_발신_서버_인증
3. DKIM_키_생성_및_DNS_등록
4. DMARC_정책_설정
5. PTR_역방향_DNS_레코드
6. DNS_설정_검증_도구_활용

---

1. MX 레코드 설정 및 우선순위

어느 날 김개발 씨는 회사에서 새로운 업무를 맡게 되었습니다. 바로 회사 도메인으로 이메일을 주고받을 수 있도록 설정하는 일이었습니다.

"도메인은 샀는데, 이메일은 어떻게 연결하지?" 막막해하던 김개발 씨에게 선배 박시니어 씨가 다가왔습니다. "MX 레코드부터 설정해야 해요."

MX 레코드는 Mail Exchanger의 약자로, 해당 도메인으로 오는 이메일을 어떤 메일 서버가 처리할지 알려주는 DNS 레코드입니다. 마치 우체국에서 편지를 배달할 때 수신자의 주소를 보고 어느 집으로 가야 할지 결정하는 것과 같습니다.

MX 레코드가 없으면 아무도 여러분의 도메인으로 이메일을 보낼 수 없습니다.

다음 코드를 살펴봅시다.

; MX 레코드 설정 예시 (DNS Zone 파일 형식)
; 호스트명    TTL    클래스   타입   우선순위   메일서버
@            3600   IN       MX     10         mail1.example.com.
@            3600   IN       MX     20         mail2.example.com.
@            3600   IN       MX     30         mail3.example.com.

; A 레코드로 메일 서버 IP 지정
mail1        3600   IN       A      203.0.113.10
mail2        3600   IN       A      203.0.113.20
mail3        3600   IN       A      203.0.113.30

; Google Workspace 사용 시
@            3600   IN       MX     1          aspmx.l.google.com.
@            3600   IN       MX     5          alt1.aspmx.l.google.com.

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 이번에 회사에서 새로운 서비스를 런칭하면서 info@newservice.com 같은 회사 이메일 주소가 필요해졌습니다.

도메인은 이미 구매했지만, 이메일이 어디로 가야 하는지 설정하는 방법을 전혀 몰랐습니다. 선배 개발자 박시니어 씨가 화이트보드 앞으로 김개발 씨를 불렀습니다.

"이메일 시스템을 이해하려면 먼저 우체국을 생각해보세요." 그렇다면 MX 레코드란 정확히 무엇일까요? 쉽게 비유하자면, MX 레코드는 마치 아파트 경비실과 같습니다.

택배 기사가 물건을 배달하러 왔을 때, 경비실에서 "이 택배는 몇 동 몇 호로 가세요"라고 안내해주는 것처럼, MX 레코드는 이메일이 도착했을 때 "이 메일은 이 서버로 가세요"라고 안내해줍니다. MX 레코드가 없던 시절에는 어땠을까요?

사실 MX 레코드는 이메일 시스템의 핵심이기 때문에, 이것이 없으면 이메일 자체가 동작하지 않습니다. 누군가 여러분의 도메인으로 이메일을 보내면, 상대방의 메일 서버는 먼저 DNS에 MX 레코드를 질의합니다.

MX 레코드가 없다면 메일은 그냥 사라지거나 발송 실패 메시지가 반환됩니다. MX 레코드에서 가장 중요한 개념은 우선순위입니다.

위의 코드를 보면 10, 20, 30이라는 숫자가 보입니다. 이 숫자가 바로 우선순위입니다.

숫자가 낮을수록 우선순위가 높습니다. 즉, 이메일이 오면 먼저 우선순위 10인 mail1.example.com으로 전송을 시도합니다.

만약 mail1 서버가 다운되어 있다면 어떻게 될까요? 그때 우선순위 20인 mail2 서버로 자동으로 넘어갑니다.

이것이 바로 장애 대응 메커니즘입니다. 마치 주 출입구가 막혔을 때 비상구로 나가는 것과 같습니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 회사는 Google Workspace나 Microsoft 365 같은 클라우드 이메일 서비스를 사용합니다.

이 경우 해당 서비스에서 제공하는 MX 레코드 값을 그대로 입력하면 됩니다. Google Workspace를 사용한다면 aspmx.l.google.com 같은 구글의 메일 서버를 MX 레코드로 지정합니다.

주의할 점도 있습니다. MX 레코드의 값 끝에는 반드시 마침표(.)를 붙여야 합니다.

mail1.example.com. 처럼요.

이 마침표는 해당 주소가 **완전한 도메인 이름(FQDN)**임을 나타냅니다. 마침표를 빼먹으면 현재 도메인이 뒤에 붙어서 mail1.example.com.example.com 같은 잘못된 주소가 될 수 있습니다.

또한 MX 레코드는 반드시 호스트명을 가리켜야 하며, IP 주소를 직접 지정할 수 없습니다. 따라서 MX 레코드가 가리키는 호스트명에 대한 A 레코드도 함께 설정해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 DNS 관리 페이지에 들어가 MX 레코드를 설정했습니다.

몇 분 후, 테스트 이메일을 보내보니 정상적으로 수신되었습니다. "생각보다 간단하네요!" 김개발 씨가 활짝 웃었습니다.

실전 팁

💡 - 우선순위 값은 보통 10 단위로 설정합니다. 나중에 중간에 서버를 추가할 여유를 두기 위함입니다.

• TTL(Time To Live)은 처음 설정할 때 짧게(300초 정도) 설정하고, 안정화되면 늘리세요.
• 클라우드 이메일 서비스 사용 시, 공식 문서의 MX 레코드 값을 정확히 복사하세요.

---

2. SPF 레코드로 발신 서버 인증

MX 레코드를 설정한 김개발 씨는 이메일 수신은 잘 되는데, 보낸 이메일이 자꾸 스팸함으로 들어간다는 보고를 받았습니다. "분명 정상적으로 보낸 건데 왜 스팸으로 처리되지?" 박시니어 씨가 웃으며 말했습니다.

"SPF 레코드를 안 설정해서 그래요. 받는 쪽에서 우리 메일을 의심하는 거예요."

SPF(Sender Policy Framework) 레코드는 "이 도메인에서 이메일을 보낼 수 있는 서버는 이것들이다"라고 공식적으로 선언하는 DNS 레코드입니다. 마치 회사에서 공식 직인을 등록해두고, 그 직인이 찍힌 문서만 진짜로 인정하는 것과 같습니다.

SPF가 없으면 누구나 여러분의 도메인을 사칭해서 이메일을 보낼 수 있습니다.

다음 코드를 살펴봅시다.

; SPF 레코드 기본 형식 (TXT 레코드로 설정)
; v=spf1: SPF 버전 1 사용
; ip4: 허용할 IPv4 주소
; include: 다른 도메인의 SPF 정책 포함
; -all: 나머지는 모두 거부

; 기본 SPF 설정
@    3600    IN    TXT    "v=spf1 ip4:203.0.113.0/24 -all"

; Google Workspace 사용 시
@    3600    IN    TXT    "v=spf1 include:_spf.google.com -all"

; 여러 서비스 조합 시
@    3600    IN    TXT    "v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all"

; 복잡한 실무 예시
@    3600    IN    TXT    "v=spf1 mx a ip4:203.0.113.0/24 include:_spf.google.com include:amazonses.com -all"

김개발 씨는 고민에 빠졌습니다. 고객에게 보낸 중요한 안내 메일이 스팸으로 분류되어 고객이 못 봤다는 클레임이 들어온 것입니다.

분명 회사 메일 서버에서 정상적으로 발송했는데 왜 이런 일이 생긴 걸까요? 박시니어 씨가 설명을 시작했습니다.

"인터넷 세상에서 이메일은 기본적으로 누구나 보낼 수 있어요. 내가 보낸 메일의 발신자 주소를 ceo@대기업.com으로 위조하는 것도 가능하죠." 그렇다면 SPF란 정확히 무엇일까요?

쉽게 비유하자면, SPF는 마치 회사의 공식 명함 인쇄소 목록과 같습니다. "우리 회사의 진짜 명함은 A인쇄소와 B인쇄소에서만 만들어집니다"라고 공지하는 것입니다.

다른 곳에서 만든 명함은 위조된 것으로 간주합니다. SPF도 마찬가지로 "우리 도메인의 진짜 이메일은 이 서버들에서만 발송됩니다"라고 DNS에 공개적으로 선언합니다.

SPF가 없던 시절에는 이메일 사기가 정말 심각했습니다. 피싱 메일은 은행이나 대기업을 사칭해서 "귀하의 계정이 정지되었습니다" 같은 메일을 보내 개인정보를 탈취했습니다.

받는 사람은 발신자 주소만 보고는 진짜인지 가짜인지 구분할 방법이 없었습니다. SPF 레코드의 핵심 구성 요소를 살펴보겠습니다.

먼저 v=spf1은 SPF 버전 1을 사용한다는 선언입니다. 현재는 버전 1만 존재합니다.

**ip4:**는 특정 IP 주소나 대역을 허용합니다. **include:**는 다른 도메인의 SPF 정책을 가져옵니다.

Google Workspace를 쓴다면 include:_spf.google.com을 추가하면 구글의 메일 서버들이 자동으로 허용됩니다. 가장 중요한 것은 마지막의 all 처리 방식입니다.

-all은 "목록에 없는 서버에서 온 메일은 무조건 거부하라"는 엄격한 정책입니다. ~all은 "의심스럽게 취급하되 완전히 거부하지는 말라"는 부드러운 정책입니다.

?all은 "신경 쓰지 말라"는 중립 정책인데, 이건 SPF를 안 쓰는 것과 다름없어서 권장하지 않습니다. 실제 현업에서는 여러 서비스를 조합해서 사용합니다.

회사 메일은 Google Workspace로, 마케팅 메일은 SendGrid로, 거래 알림 메일은 Amazon SES로 보내는 식입니다. 이 경우 SPF 레코드에 모든 서비스를 include 해야 합니다.

주의할 점이 있습니다. SPF 레코드에서 DNS 조회 횟수는 최대 10회로 제한됩니다.

include를 너무 많이 사용하면 이 한도를 초과해서 SPF 검증이 실패할 수 있습니다. 또한 SPF 레코드는 도메인당 하나만 존재해야 합니다.

여러 개의 TXT 레코드에 나눠서 쓰면 안 됩니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

SPF 레코드를 설정한 후, 며칠간 모니터링해보니 스팸으로 분류되는 비율이 크게 줄었습니다. 하지만 박시니어 씨가 말했습니다.

"SPF만으로는 완벽하지 않아요. DKIM도 설정해야 해요."

실전 팁

💡 - 처음에는 ~all(소프트 실패)로 시작해서 문제가 없으면 -all(하드 실패)로 변경하세요.

• SPF 레코드 검증 도구로 DNS 조회 횟수가 10회를 넘지 않는지 확인하세요.
• 새로운 이메일 서비스를 추가할 때마다 SPF 레코드를 업데이트해야 합니다.

---

3. DKIM 키 생성 및 DNS 등록

김개발 씨는 SPF를 설정했지만, 박시니어 씨는 아직 만족하지 않았습니다. "SPF는 발신 서버만 검증해요.

하지만 메일 내용이 중간에 변조되었는지는 알 수 없죠. DKIM을 설정하면 메일에 디지털 서명을 할 수 있어요." 김개발 씨는 "디지털 서명이요?

뭔가 어려워 보이는데요..."라고 걱정했습니다.

**DKIM(DomainKeys Identified Mail)**은 이메일에 디지털 서명을 추가하는 인증 방식입니다. 마치 중요한 서류에 직인을 찍고 봉인 스티커를 붙이는 것과 같습니다.

서명이 유효하면 메일이 진짜이고 중간에 변조되지 않았음을 증명할 수 있습니다. 공개키 암호화 방식을 사용하며, 개인키는 메일 서버에, 공개키는 DNS에 등록합니다.

다음 코드를 살펴봅시다.

; DKIM 공개키 DNS 레코드 (TXT 레코드)
; selector._domainkey.도메인 형식으로 등록

; 기본 DKIM 레코드
google._domainkey    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

; 실제 형식 설명
; v=DKIM1  : DKIM 버전
; k=rsa    : 암호화 알고리즘 (RSA)
; p=...    : 공개키 (Base64 인코딩)

; 긴 키는 여러 문자열로 분할
selector1._domainkey    3600    IN    TXT    ("v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
    "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")

; OpenSSL로 DKIM 키 쌍 생성 (Bash)
; openssl genrsa -out dkim_private.pem 2048
; openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

김개발 씨는 DKIM이라는 단어를 듣고 조금 긴장했습니다. 암호화니 디지털 서명이니 하는 말이 어렵게 느껴졌기 때문입니다.

하지만 박시니어 씨는 쉽게 설명해주었습니다. "편지를 보낼 때 봉투에 밀랍으로 봉인을 찍어서 보낸 적 있나요?" 박시니어 씨가 물었습니다.

김개발 씨는 영화에서 본 적이 있다고 대답했습니다. "DKIM이 바로 그 디지털 버전이에요." 그렇다면 DKIM이란 정확히 무엇일까요?

쉽게 비유하자면, DKIM은 마치 공증된 서류와 같습니다. 중요한 계약서를 보낼 때 공증 사무소에서 도장을 받아 보내면, 받는 사람은 이 서류가 진짜이고 위조되지 않았음을 확인할 수 있습니다.

DKIM도 마찬가지로 메일 서버가 메일을 보낼 때 디지털 도장을 찍어주고, 받는 쪽에서는 DNS에 등록된 공개키로 이 도장이 진짜인지 확인합니다. DKIM은 공개키 암호화 방식을 사용합니다.

먼저 키 쌍을 생성합니다. 개인키(비밀키)와 공개키가 한 쌍입니다.

개인키는 메일 서버에 안전하게 보관하고, 공개키는 DNS에 TXT 레코드로 공개합니다. 메일을 보낼 때 개인키로 서명하고, 받는 쪽에서는 DNS의 공개키로 서명을 검증합니다.

DNS에 등록하는 DKIM 레코드의 이름은 selector._domainkey.도메인 형식입니다. 여기서 selector는 키를 구분하는 이름입니다.

왜 selector가 필요할까요? 키를 주기적으로 교체할 때 유용합니다.

새 키를 selector2로 등록하고, 기존 selector1은 나중에 삭제하면 됩니다. 또한 여러 메일 서버가 각자 다른 키를 사용할 수도 있습니다.

Google Workspace나 Microsoft 365 같은 서비스를 사용한다면 DKIM 설정이 간단합니다. 관리 콘솔에서 DKIM을 활성화하면 공개키 값을 알려줍니다.

이 값을 DNS에 TXT 레코드로 등록하기만 하면 됩니다. 직접 메일 서버를 운영한다면 키를 직접 생성해야 합니다.

OpenSSL 명령어로 2048비트 RSA 키 쌍을 만들고, 공개키를 DNS에 등록합니다. 개인키는 메일 서버의 DKIM 서명 모듈에 설정합니다.

주의할 점이 있습니다. DKIM 공개키는 매우 깁니다.

DNS TXT 레코드에는 문자열 길이 제한(255자)이 있어서, 긴 키는 여러 문자열로 나눠서 등록해야 합니다. 대부분의 DNS 관리 도구는 자동으로 처리해주지만, 직접 존 파일을 편집한다면 주의해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. Google Workspace 관리 콘솔에서 DKIM 공개키를 복사해 DNS에 등록한 김개발 씨는 48시간 후 DKIM이 활성화되었다는 확인을 받았습니다.

"이제 우리 메일에 디지털 서명이 찍히는 거죠?" "맞아요. 이제 DMARC만 설정하면 완성이에요."

실전 팁

💡 - 키 길이는 최소 1024비트, 권장 2048비트입니다. 보안상 2048비트를 사용하세요.

• DKIM 키는 1년에 한 번 정도 교체하는 것이 좋습니다.
• DNS 전파에 최대 48시간이 걸릴 수 있으니 여유를 두고 설정하세요.

---

4. DMARC 정책 설정

SPF와 DKIM을 모두 설정한 김개발 씨에게 박시니어 씨가 마지막 단계를 안내했습니다. "SPF와 DKIM은 각각 검증은 하지만, 검증에 실패했을 때 어떻게 처리할지는 정하지 않아요.

DMARC가 바로 그 정책을 결정합니다. 게다가 누가 우리 도메인을 사칭하는지 보고서까지 받을 수 있어요."

**DMARC(Domain-based Message Authentication, Reporting and Conformance)**는 SPF와 DKIM의 검증 결과를 바탕으로 이메일 처리 정책을 정의하는 표준입니다. 마치 회사 보안 규정과 같습니다.

"신분증 검사에 실패한 방문자는 입장 불가"처럼, "SPF/DKIM 검증에 실패한 메일은 이렇게 처리하라"고 정책을 선언합니다. 또한 검증 결과 보고서를 받아 모니터링할 수 있습니다.

다음 코드를 살펴봅시다.

; DMARC 레코드 (TXT 레코드로 설정)
; _dmarc.도메인 형식으로 등록

; 모니터링 모드 (처음 시작할 때 권장)
_dmarc    3600    IN    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

; 격리 정책 (스팸으로 분류)
_dmarc    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; 거부 정책 (가장 엄격)
_dmarc    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com"

; 상세 설정 예시
_dmarc    3600    IN    TXT    "v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; fo=1"

; p: 정책 (none/quarantine/reject)
; sp: 서브도메인 정책
; rua: 집계 보고서 수신 이메일
; ruf: 포렌식 보고서 수신 이메일
; pct: 정책 적용 비율 (0-100)

김개발 씨는 SPF와 DKIM을 설정했지만, 한 가지 의문이 들었습니다. "검증에 실패하면 메일이 어떻게 되는 거예요?" 박시니어 씨가 대답했습니다.

"그건 받는 쪽 메일 서버 마음이에요. 어떤 곳은 스팸함으로 보내고, 어떤 곳은 그냥 통과시키죠.

DMARC를 설정하면 우리가 그 정책을 정할 수 있어요." 그렇다면 DMARC란 정확히 무엇일까요? 쉽게 비유하자면, DMARC는 마치 회사의 보안 매뉴얼과 같습니다.

SPF는 "이 사람이 우리 회사 소속인가?"를 확인하고, DKIM은 "이 서류가 위조되지 않았는가?"를 확인합니다. DMARC는 "확인에 실패하면 어떻게 처리할 것인가?"를 정의합니다.

그리고 매일 보안 보고서를 받아서 누가 회사를 사칭했는지 파악할 수 있습니다. DMARC 정책에는 세 가지 레벨이 있습니다.

p=none은 아무 조치도 하지 말라는 의미입니다. 검증에 실패해도 메일은 정상 전달됩니다.

하지만 보고서는 계속 받을 수 있어서 모니터링 용도로 사용합니다. 처음 DMARC를 도입할 때는 이 모드로 시작하는 것이 좋습니다.

p=quarantine은 검증 실패 시 메일을 격리하라는 의미입니다. 대부분 스팸함으로 들어갑니다.

받는 사람이 스팸함을 확인하면 볼 수 있지만, 기본적으로는 숨겨집니다. 어느 정도 안정화되면 이 정책을 사용합니다.

p=reject는 가장 엄격한 정책입니다. 검증 실패 시 메일을 완전히 거부합니다.

받는 사람의 메일함에 도달조차 하지 않습니다. 완전히 안정화된 후에만 사용해야 합니다.

설정이 잘못되면 정상 메일도 거부될 수 있기 때문입니다. DMARC의 또 다른 강력한 기능은 보고서입니다.

rua에 이메일 주소를 지정하면 매일 집계 보고서를 받습니다. 이 보고서에는 여러분의 도메인으로 발송된 모든 이메일의 SPF/DKIM 검증 결과가 담겨 있습니다.

누군가 도메인을 사칭하고 있다면 여기서 발견할 수 있습니다. ruf는 포렌식 보고서 주소입니다.

검증에 실패한 개별 메일의 상세 정보를 받습니다. 다만 개인정보 문제로 모든 메일 서버가 포렌식 보고서를 보내주지는 않습니다.

실무에서 DMARC를 도입할 때는 단계적으로 진행합니다. 먼저 p=none으로 시작해서 2-4주간 보고서를 분석합니다.

정상적인 메일이 모두 검증을 통과하는지 확인한 후, pct=10으로 10%에만 quarantine을 적용해봅니다. 문제가 없으면 pct를 점차 높여서 최종적으로 p=reject까지 도달합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. DMARC까지 설정을 완료한 김개발 씨는 일주일간 보고서를 받아봤습니다.

놀랍게도 회사 도메인을 사칭한 메일이 하루에 수십 통씩 발송되고 있었습니다. "이렇게 많은 사기 메일이..." DMARC 덕분에 이 사실을 알게 되었고, p=reject 정책으로 전환한 후에는 사칭 메일이 모두 차단되었습니다.

실전 팁

💡 - 반드시 p=none부터 시작해서 보고서로 현황을 파악한 후 정책을 강화하세요.

• DMARC 보고서는 XML 형식이라 읽기 어렵습니다. DMARC 분석 서비스 사용을 권장합니다.
• 서브도메인도 보호하려면 sp 태그를 함께 설정하세요.

---

5. PTR 역방향 DNS 레코드

이메일 설정이 거의 완료되었다고 생각한 김개발 씨에게 박시니어 씨가 한 가지를 더 언급했습니다. "PTR 레코드는 확인해봤어요?" 김개발 씨는 처음 듣는 용어에 고개를 갸웃했습니다.

"역방향 DNS라고도 하는데, 메일 서버 신뢰도에 중요해요. 특히 직접 메일 서버를 운영한다면 필수입니다."

PTR(Pointer) 레코드는 IP 주소를 도메인 이름으로 역으로 변환하는 DNS 레코드입니다. 일반적인 DNS 조회가 "example.com의 IP가 뭐야?"라면, 역방향 DNS는 "203.0.113.10은 어떤 도메인이야?"입니다.

마치 전화번호부를 거꾸로 찾는 것과 같습니다. 메일 서버들은 이 PTR 레코드를 확인해서 발신 서버의 신뢰도를 검증합니다.

다음 코드를 살펴봅시다.

; PTR 레코드는 역방향 DNS 존에 설정
; IP 203.0.113.10의 PTR 레코드
; in-addr.arpa 형식 사용 (IP를 거꾸로)

; IPv4 PTR 레코드 예시
10.113.0.203.in-addr.arpa.    3600    IN    PTR    mail.example.com.

; IPv6 PTR 레코드 예시 (각 16진수 자릿수를 역순으로)
; 2001:db8::1의 경우
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.    PTR    mail.example.com.

; Linux에서 PTR 레코드 확인 명령어
; dig -x 203.0.113.10
; nslookup 203.0.113.10
; host 203.0.113.10

; 결과 예시:
; 10.113.0.203.in-addr.arpa domain name pointer mail.example.com.

김개발 씨는 PTR 레코드가 왜 필요한지 이해하지 못했습니다. "SPF, DKIM, DMARC도 다 설정했는데 또 뭐가 필요한 거예요?" 박시니어 씨가 차근차근 설명했습니다.

"인터넷에서 스팸 발송자들은 주로 임시 IP를 사용해요. ISP에서 동적으로 할당받은 IP나, 해킹된 서버의 IP 같은 거죠.

이런 IP들은 대부분 PTR 레코드가 없거나 엉뚱한 도메인으로 설정되어 있어요." 그렇다면 PTR 레코드란 정확히 무엇일까요? 쉽게 비유하자면, PTR 레코드는 마치 발신자 번호 확인 서비스와 같습니다.

전화가 오면 번호만 보이는 게 아니라 "홍길동"이라는 이름도 함께 뜨죠. PTR 레코드도 마찬가지입니다.

이메일이 203.0.113.10에서 왔을 때, 이 IP가 정말 mail.example.com인지 역으로 확인할 수 있습니다. 일반적인 DNS 조회를 정방향 조회라고 합니다.

도메인 이름으로 IP 주소를 찾습니다. 반대로 IP 주소로 도메인 이름을 찾는 것을 역방향 조회라고 합니다.

PTR 레코드는 이 역방향 조회에 사용됩니다. PTR 레코드의 특이한 점은 설정 권한이 IP 소유자에게 있다는 것입니다.

일반 DNS 레코드는 도메인 소유자가 설정하지만, PTR 레코드는 IP 주소를 할당해준 ISP나 호스팅 업체가 설정 권한을 가집니다. 따라서 PTR 레코드를 설정하려면 호스팅 업체의 제어판을 사용하거나 고객 지원에 요청해야 합니다.

메일 서버들이 PTR을 확인하는 방식은 이렇습니다. 이메일이 도착하면 발신 IP의 PTR 레코드를 조회합니다.

PTR이 없거나, PTR로 얻은 도메인의 A 레코드가 원래 IP와 일치하지 않으면 스팸 점수가 올라갑니다. **FCrDNS(Forward-confirmed reverse DNS)**라고 해서, 정방향과 역방향이 서로 일치하는지 확인하는 것이 표준 관행입니다.

클라우드 이메일 서비스(Google Workspace, Microsoft 365 등)를 사용한다면 PTR 레코드 걱정은 필요 없습니다. 해당 서비스의 메일 서버들은 이미 적절한 PTR 레코드가 설정되어 있습니다.

하지만 AWS EC2나 자체 서버에서 메일 서버를 직접 운영한다면 반드시 PTR 레코드를 설정해야 합니다. 주의할 점이 있습니다.

AWS, GCP 같은 클라우드에서는 PTR 레코드 설정에 추가 절차가 필요할 수 있습니다. AWS의 경우 Elastic IP에 대해 PTR 설정을 별도로 요청해야 합니다.

또한 일부 ISP 대역의 IP는 PTR 설정이 불가능해서 메일 서버용으로 적합하지 않습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

다행히 회사는 Google Workspace를 사용하고 있어서 PTR 레코드는 신경 쓸 필요가 없었습니다. 하지만 김개발 씨는 중요한 교훈을 얻었습니다.

"만약 나중에 자체 메일 서버를 구축하게 되면 PTR 레코드를 꼭 확인해야겠어요."

실전 팁

💡 - dig -x IP주소 명령어로 PTR 레코드가 제대로 설정되어 있는지 확인하세요.

• PTR 레코드의 도메인과 HELO/EHLO에서 사용하는 호스트명을 일치시키세요.
• 클라우드 환경에서 메일 서버 운영 시, 해당 업체의 PTR 설정 가이드를 확인하세요.

---

6. DNS 설정 검증 도구 활용

모든 설정을 마친 김개발 씨는 뿌듯했지만, 동시에 걱정도 되었습니다. "제가 설정을 제대로 한 건지 어떻게 확인하죠?" 박시니어 씨가 웃으며 여러 검증 도구들을 알려주었습니다.

"직접 눈으로 확인해보는 게 제일 확실하죠. 이 도구들을 사용하면 모든 설정이 올바른지 한눈에 볼 수 있어요."

DNS 레코드 설정은 복잡하고 실수하기 쉽습니다. 다행히 설정을 검증하고 문제를 진단해주는 다양한 온라인 도구들이 있습니다.

마치 자동차 정비소의 종합 점검 서비스처럼, 이 도구들은 MX, SPF, DKIM, DMARC 설정을 모두 검사하고 문제가 있으면 알려줍니다. 설정 후에는 반드시 이런 도구로 확인하는 습관을 들이세요.

다음 코드를 살펴봅시다.

# 명령줄에서 DNS 레코드 확인하기

# MX 레코드 확인
dig example.com MX +short
# 결과: 10 mail.example.com.

# SPF 레코드 확인 (TXT 레코드)
dig example.com TXT +short | grep spf
# 결과: "v=spf1 include:_spf.google.com -all"

# DKIM 레코드 확인
dig selector._domainkey.example.com TXT +short
# 결과: "v=DKIM1; k=rsa; p=MIIBIj..."

# DMARC 레코드 확인
dig _dmarc.example.com TXT +short
# 결과: "v=DMARC1; p=reject; rua=mailto:..."

# PTR 레코드 확인 (역방향 DNS)
dig -x 203.0.113.10 +short
# 결과: mail.example.com.

# 온라인 검증 도구 목록
# - MXToolbox: https://mxtoolbox.com
# - Mail-tester: https://mail-tester.com
# - DMARC Analyzer: https://dmarcian.com/dmarc-tools/

김개발 씨는 설정을 마치고 나서 "잘 된 건가?"라는 불안감이 들었습니다. DNS 설정은 눈에 보이지 않고, 문제가 있어도 바로 에러가 나지 않습니다.

며칠 뒤에 "메일이 안 간다"는 보고를 받고서야 문제를 알게 되는 경우도 많습니다. 박시니어 씨가 컴퓨터 앞에 앉으며 말했습니다.

"걱정 마세요. 설정을 검증해주는 좋은 도구들이 있어요." 가장 널리 쓰이는 도구는 MXToolbox입니다.

웹사이트에 도메인만 입력하면 MX, SPF, DKIM, DMARC를 한 번에 검사해줍니다. 문제가 있으면 빨간색으로 경고를 표시하고, 어떻게 고쳐야 하는지도 알려줍니다.

무료로 사용할 수 있어서 실무에서 정말 많이 씁니다. Mail-tester는 조금 다른 방식으로 동작합니다.

사이트에서 임시 이메일 주소를 받은 다음, 그 주소로 테스트 메일을 보냅니다. 그러면 해당 메일의 SPF, DKIM, DMARC 검증 결과를 점수로 보여줍니다.

10점 만점에 몇 점인지 확인할 수 있어서 직관적입니다. 스팸 점수도 함께 분석해주어서 메일이 스팸으로 분류될 가능성도 알 수 있습니다.

명령줄에서 직접 확인하고 싶다면 dig 명령어를 사용합니다. dig example.com MX로 MX 레코드를, dig example.com TXT로 SPF 레코드를 확인할 수 있습니다.

DKIM은 selector._domainkey.example.com을 조회하고, DMARC는 _dmarc.example.com을 조회합니다. DNS 전파 시간을 고려해야 합니다.

DNS 레코드를 변경하면 전 세계의 DNS 서버에 퍼지는 데 시간이 걸립니다. TTL(Time To Live) 값에 따라 다르지만, 보통 몇 분에서 최대 48시간까지 걸릴 수 있습니다.

설정 직후에 검증이 실패해도 당황하지 마세요. 시간을 두고 다시 확인해보면 됩니다.

whatsmydns.net 같은 사이트를 사용하면 전 세계 여러 지역에서 DNS 레코드가 어떻게 보이는지 확인할 수 있습니다. 한국에서는 변경이 반영되었는데 미국에서는 아직 이전 값이 보일 수도 있습니다.

글로벌 서비스를 운영한다면 이런 도구로 전파 상태를 확인하는 것이 좋습니다. 문제가 발견되면 당황하지 말고 차근차근 해결합니다.

가장 흔한 실수는 오타입니다. SPF의 v=spf1을 v-spf1로 쓴다거나, DKIM selector 이름을 잘못 입력하는 경우가 많습니다.

또한 따옴표 처리, 공백, 마침표 등 사소한 문법 오류도 자주 발생합니다. 정기적인 모니터링도 중요합니다.

한 번 설정했다고 끝이 아닙니다. 새로운 이메일 서비스를 추가하면 SPF를 업데이트해야 하고, DKIM 키는 주기적으로 교체해야 합니다.

MXToolbox에서 모니터링 알림을 설정하면 문제가 생겼을 때 이메일로 알려줍니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

MXToolbox로 검증해본 결과, 모든 항목이 초록색 체크 표시였습니다. Mail-tester에서는 10점 만점을 받았습니다.

김개발 씨는 안도의 한숨을 쉬었습니다. "이제 우리 회사 이메일은 안전하고 신뢰할 수 있게 되었네요!" 박시니어 씨가 마지막으로 덧붙였습니다.

"매달 한 번씩은 검증 도구로 확인하는 습관을 들이세요. DNS 설정은 한 번 하면 잊기 쉬운데, 문제가 생기면 비즈니스에 큰 영향을 줄 수 있으니까요."

실전 팁

💡 - 설정 변경 후 최소 1시간은 기다린 뒤에 검증 도구로 확인하세요.

• MXToolbox의 무료 모니터링 기능을 활용해서 문제 발생 시 알림을 받으세요.
• Mail-tester로 실제 메일 발송 테스트를 해보면 스팸 점수까지 확인할 수 있습니다.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!