DNS를 더 이상 추측하지 마세요: 개발자를 위한 MX, SPF, DKIM, DMARC 안내

지금 이메일 DNS 레코드가 중요한 이유

이메일 인증은 한때 선택 사항이었습니다. 2026년에는 기본 요건입니다. Gmail과 Outlook은 대량 발송자에게 SPF와 DKIM을 모두 적용하고 있으며, DMARC는 트랜잭션 이메일을 보내는 모든 도메인에 빠르게 필수가 되고 있습니다. DNS 레코드가 잘못되어 있으면 이메일은 도착하지 않습니다. 반송도, 경고도 없이 그저 조용히 사라집니다.

문제는 이러한 레코드가 도구처럼이 아니라 RFC처럼 문서화되어 있다는 점입니다. 대부분의 개발자는 이메일 제공업체의 설정 가이드에서 예제를 복사해 붙여 넣고 잘 되기를 바랍니다. 이는 문제를 해결해야 하거나, 두 번째 발송 서비스를 추가해야 하거나, 클라이언트에게 문의 양식 이메일이 왜 스팸함에 들어가는지 설명해야 하는 순간까지는 통합니다.

이 가이드는 실제로 마주치게 되는 순서대로 MX, SPF, DKIM, DMARC를 살펴봅니다. 올바르게 구성할 수 있을 만큼의 세부 정보와, 문제가 생겼을 때 디버깅할 수 있을 만큼의 맥락을 함께 제공합니다.

MX 레코드: 수신 이메일이 가는 곳

MX 레코드는 인터넷에 어떤 메일 서버가 해당 도메인의 이메일을 받을 수 있는지 알려줍니다. 네 가지 중 가장 단순하지만, 잘못 구성하기도 가장 쉽습니다.

MX 레코드는 두 부분으로 구성됩니다. 우선순위 번호와 호스트 이름입니다. 우선순위 번호가 낮을수록 먼저 시도됩니다. Google Workspace를 사용한다면 MX 레코드는 다음과 비슷할 수 있습니다:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

끝의 점은 중요합니다. 호스트 이름이 완전한 형식의 이름임을 나타냅니다. 대부분의 DNS 제공업체는 이를 자동으로 추가하지만, 모두가 그런 것은 아닙니다.

흔한 실수로는 MX 레코드를 호스트 이름이 아니라 A 레코드로 지정하는 것, 모든 우선순위를 같은 숫자로 설정해 백업을 두는 의미를 없애는 것, 제공업체를 이전할 때 오래된 MX 레코드를 제거하지 않는 것이 있습니다. 오래된 MX 레코드는 그저 harmless하게 남아 있는 것이 아닙니다. 메일 루프를 만들거나 두 개의 받은편지함으로 전달을 분산시킬 수 있습니다.

자체 문의 양식을 운영하면서 타사 서비스에 의존하지 않고 스팸을 피하고 싶다면, 양식이 어떻게 스팸 벡터가 되는지 이해하기가 좋은 출발점입니다.

SPF: 어떤 서버가 당신을 대신해 보낼 수 있는가

SPF (Sender Policy Framework)는 도메인을 대신해 이메일을 보낼 권한이 있는 IP 주소와 도메인을 나열하는 TXT 레코드입니다. 대부분의 메일 서버가 당신에게서 온 것처럼 보이는 메시지를 받을 때 가장 먼저 수행하는 검사입니다.

기본 SPF 레코드는 다음과 같습니다:

v=spf1 include:_spf.google.com ~all

나누어 보면 다음과 같습니다:

• v=spf1은 SPF 버전을 선언합니다
• include:_spf.google.com은 Google의 SPF 레코드에 위임합니다
• ~all은 소프트 실패입니다. 목록에 없는 출처의 메일을 거부하되, 너무 엄격하게 처리하지는 않습니다

특정 주소를 허용 목록에 넣기 위해 ip4: 또는 ip6:를 사용할 수도 있고, 도메인의 A 및 MX 레코드를 참조하기 위해 a와 mx를 사용할 수도 있습니다. 끝의 all 메커니즘은 목록에 없는 출처에서 온 메일을 어떻게 처리할지 제어합니다. -all은 하드 실패(거부), ~all은 소프트 실패(의심스러운 것으로 표시), ?all은 중립(의견 없음), +all은 누구나 허용(사용하지 마세요)입니다.

SPF에는 두 가지 날카로운 모서리가 있습니다. 첫째, 이메일이 전달될 때 깨집니다. 전달 서버가 SPF 레코드에 없기 때문입니다. 둘째, SPF 레코드에는 DNS 조회 10회 제한이 있습니다. 타사 서비스를 너무 많이 포함하면 제한을 초과하게 되고 SPF는 동작을 멈춥니다. 해결책은 SPF 레코드를 평탄화하는 것입니다. 즉 include: 지시문을 실제 IP 범위로 대체하는 방식입니다. 하지만 이는 제공업체가 IP를 변경할 때 유지보수가 필요합니다.

DKIM: 발신자 신원의 암호학적 증명

DKIM (DomainKeys Identified Mail)은 발신 이메일에 디지털 서명을 추가합니다. 수신 서버는 DNS에 게시된 공개 키로 서명을 확인합니다. 서명이 유효하고 메시지가 변조되지 않았다면 DKIM은 통과합니다.

SPF와 달리 DKIM은 전달되어도 살아남습니다. 서명이 메시지와 함께 이동하기 때문입니다. 또한 더 유연합니다. 서로 다른 발송 서비스마다 자체 selector를 가진 여러 DKIM 키를 둘 수 있습니다.

DKIM DNS 레코드는 다음과 같습니다:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

selector(이 예에서는 default)는 임의의 값입니다. 이메일 제공업체가 선택합니다. p= 값은 공개 키이며, 보통 긴 base64 인코딩 문자열입니다. 이메일 제공업체는 개인 키를 생성하고 이를 사용해 발신 메시지에 서명합니다.

DKIM 설정은 거의 항상 이메일 제공업체가 처리합니다. 당신의 역할은 제공업체가 준 TXT 레코드를 복사해 DNS에 붙여 넣는 것입니다. 까다로운 부분은 일부 DNS 제공업체가 긴 TXT 레코드를 잘 처리하지 못한다는 점입니다. 값을 잘라 버리거나, 여러 개의 따옴표 문자열로 나누도록 요구할 수 있습니다.

DKIM이 동작하는지 확인하려면 Gmail 주소로 테스트 이메일을 보내고 헤더를 확인하세요. Authentication-Results 헤더에서 dkim=pass를 찾으면 됩니다.

DMARC: 정책 적용과 보고

DMARC (Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM을 묶고, 인증이 실패했을 때 수신 서버가 무엇을 해야 하는지 알려줍니다. 또한 보고를 활성화해, 누가 당신의 도메인으로 이메일을 보내고 있는지 확인할 수 있게 합니다. 정상 발송과 위조 발송을 모두 볼 수 있습니다.

최소 DMARC 레코드는 다음과 같습니다:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none은 모니터링만 한다는 뜻입니다. 실패한 메시지를 거부하거나 격리하지 않습니다
• rua=mailto:[email protected]은 집계 보고서를 보낼 위치를 지정합니다

SPF와 DKIM이 동작한다고 확신하면 정책을 p=quarantine(실패 메시지를 스팸으로 보냄) 또는 p=reject(즉시 반송)로 강화할 수 있습니다. sp=로 하위 도메인 정책을 설정할 수도 있고, pct=로 정책을 적용할 메시지 비율을 지정할 수도 있습니다.

DMARC 보고서는 주요 수신자가 매일 보내는 XML 파일입니다. 원문은 장황하고 읽기 어렵지만, 어떤 메시지가 인증을 통과했거나 실패했는지와 그 이유를 정확히 알려줍니다. 정상 메일이 거부되는 상황이라면, 보고서가 어떤 SPF 또는 DKIM 검사가 실패하는지 보여줄 것입니다.

주의할 점 하나: DMARC는 정렬(alignment)을 요구합니다. SPF의 경우 Return-Path 헤더의 도메인이 From 헤더의 도메인과 일치해야 합니다(또는 하위 도메인이어야 합니다). DKIM의 경우 DKIM 서명의 d= 도메인이 From 도메인과 일치해야 합니다. 타사 발송 서비스를 사용한다면, 그 서비스는 자신들의 도메인이 아니라 당신의 도메인으로 custom return path 또는 DKIM 서명을 지원해야 합니다.

현재 설정을 감사하는 방법

대부분의 DNS 문제는 문제를 일으키기 전까지 보이지 않습니다. 무언가 깨지기 전에 레코드를 확인하는 방법은 다음과 같습니다:

1. MX 레코드 조회: dig MX example.com은 메일 서버 호스트 이름과 우선순위를 반환해야 합니다. 이메일 제공업체의 문서와 일치하는지 확인하세요.

1. SPF 구문 확인: dig TXT example.com을 실행하고 v=spf1 레코드를 찾으세요. SPF validator에 넣어 구문 오류와 조회 제한 위반을 잡아내세요.

1. DKIM 키 검증: 테스트 이메일을 보내고 DKIM-Signature 헤더를 검사하세요. selector와 도메인을 추출한 다음 dig TXT selector._domainkey.example.com을 조회해 공개 키가 존재하는지 확인하세요.

1. DMARC 정책 검증: dig TXT _dmarc.example.com은 DMARC 레코드를 반환해야 합니다. rua=가 실제로 모니터링하는 주소를 가리키는지 확인하세요.

1. 엔드투엔드 테스트: mail-tester.com 같은 서비스를 사용하거나 Gmail 주소로 보내 전체 헤더를 확인하세요. Authentication-Results 헤더에서 spf=pass, dkim=pass, dmarc=pass를 찾으세요.

이메일이 도착하지 않는 이유를 디버깅하고 있다면 헤더가 최고의 도구입니다. 대부분의 메일 클라이언트는 원시 헤더 보기를 제공합니다. Gmail에서는 메시지를 열고 점 세 개를 클릭한 다음 '원본 보기'를 선택하세요. Authentication-Results 헤더는 어떤 검사가 왜 실패했는지 정확히 알려줍니다.

하위 도메인 정책을 언제 사용할까

여러 하위 도메인에서 이메일을 보낸다면, 예를 들어 마케팅용 newsletter.example.com과 트랜잭션 메일용 app.example.com을 사용한다면, 하위 도메인별 DMARC 정책을 설정할 수 있습니다. 이렇게 하면 제어하는 하위 도메인에는 엄격한 정책을 적용하면서, 주 도메인에는 더 느슨한 정책을 유지할 수 있습니다.

대가는 복잡성입니다. 각 하위 도메인에는 자체 SPF, DKIM, DMARC 레코드가 필요하고, 어떤 발송 서비스가 어떤 하위 도메인에 대해 승인되어 있는지 추적해야 합니다. 대부분의 소규모 팀에게는 하나의 잘 구성된 도메인이 더 단순하고 그만큼 안전합니다.

인증이 깨졌을 때 해야 할 일

가장 흔한 실패 패턴은 DNS를 업데이트하지 않은 채 새 발송 서비스를 추가하는 것입니다. 새 트랜잭션 이메일 제공업체를 사용하기 시작했다면, 해당 제공업체의 SPF include 또는 IP 범위를 추가하고, 당신의 도메인으로 DKIM 서명을 구성하며, DMARC 정렬을 확인해야 합니다.

두 번째로 흔한 문제는 전달입니다. 사용자가 이메일을 다른 주소로 전달하면, 전달 서버가 SPF 레코드에 없기 때문에 SPF는 실패합니다. DKIM은 보통 전달되어도 유지되므로, DKIM이 통과하고 DMARC 정책이 부분 정렬을 허용한다면 메시지는 여전히 전달되어야 합니다. 전달된 메일이 거부되는 경우 DMARC 정책을 확인하세요. 엄격한 정렬과 함께 p=reject를 사용하면 전달이 깨집니다.

세 번째 문제는 DNS 전파입니다. DNS 레코드 변경 사항은 전파되는 데 몇 시간이 걸릴 수 있고, 메일 서버마다 레코드를 캐시하는 시간도 다릅니다. 방금 레코드를 업데이트했는데 동작하지 않는다면 몇 시간 기다렸다가 다시 테스트하세요. whatsmydns.net 같은 도구로 전파 상태를 확인할 수 있습니다.

핵심 요약

• MX 레코드는 수신 메일을 라우팅하고, SPF, DKIM, DMARC는 발신 메일을 인증합니다. 이들은 서로 다른 문제를 해결하며 네 가지가 모두 필요합니다.
• SPF는 전달에서 깨지고 10회 조회 제한이 있습니다. DKIM은 전달되어도 유지되지만 서비스별 구성이 필요합니다. DMARC는 이들을 묶고 보고를 활성화합니다.
• DMARC는 p=none으로 시작해 몇 주 동안 보고서를 모니터링한 다음, 정상 메일이 통과한다고 확신하면 p=quarantine 또는 p=reject로 강화하세요.
• DNS 오류는 조용합니다. 실제 이메일로 구성을 테스트하고 헤더를 검사해 SPF, DKIM, DMARC가 통과하는지 확인하세요.
• 새 발송 서비스를 추가한 뒤 인증이 깨졌다면 SPF include, DKIM selector, DMARC 정렬을 확인하세요. 헤더가 어떤 검사가 실패했는지 알려줍니다.

FAQ

Q: SPF 레코드를 여러 개 둘 수 있나요?

A: 아니요. SPF 레코드가 여러 개 있으면 모두 무시됩니다. 여러 서비스를 승인해야 한다면 단일 SPF 레코드 안에서 include: 지시문을 사용하거나 IP 범위를 직접 나열하세요. 10회 조회 제한에 주의하세요.

Q: 하루에 이메일을 몇 통만 보내도 DMARC가 필요한가요?

A: 예. DMARC는 발송량의 문제가 아닙니다. 당신이 말하는 그 주체가 실제로 맞다는 것을 증명하는 문제입니다. 작은 도메인도 위조를 막고 전달 문제를 볼 수 있게 해 주기 때문에 DMARC의 이점을 얻습니다. p=none과 보고 주소로 시작하세요.

Q: DKIM과 SPF가 모두 실패했지만 이메일이 정상처럼 보이면 어떻게 되나요?

A: DMARC 정책에 따라 다릅니다. p=none이면 메일은 경고와 함께 전달됩니다. p=quarantine이면 스팸으로 갑니다. p=reject이면 반송됩니다. 이것이 엄격한 정책을 적용하기 전에 DMARC 보고서를 모니터링해야 하는 이유입니다. 당신이 모르고 있던 정상 발송자가 있을 수 있습니다.

Q: 여러 도메인에 같은 DKIM 키를 사용할 수 있나요?

A: 기술적으로는 가능하지만 권장하지 않습니다. 각 도메인은 자체 DKIM 키 쌍을 가져야 합니다. 키를 공유하면 교체가 더 어려워지고, 개인 키가 유출되었을 때 영향 범위가 커집니다.

Q: DKIM 키는 얼마나 자주 교체해야 하나요?

A: 보편적인 규칙은 없지만, 대부분의 도메인에는 1년에 한 번 정도가 합리적입니다. 키가 유출되었다고 의심되면 즉시 교체하세요. 새 개인 키로 서명하기 전에 새 공개 키를 DNS에 게시해야 하며, 지연된 메일을 처리할 수 있도록 교체 후 며칠 동안은 이전 키도 DNS에 남겨 두세요.

<!-- tool-cta:start -->

💡 이것을 시도해 보세요: DMARC Lookup으로 모든 도메인의 게시된 정책을 검사하여 MX, SPF 및 DMARC 레코드가 실제로 어떻게 맞물리는지 확인하세요.

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — SPF 명세입니다. 구문 규칙과 10회 조회 제한을 포함합니다.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM 명세입니다. 서명 생성과 검증을 다룹니다.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC 명세입니다. 정책 구문과 집계 보고 형식을 포함합니다.
• Google Workspace: Prevent spoofing and spam — Google Workspace 도메인을 위한 SPF, DKIM, DMARC 구성 실무 가이드입니다.