이메일을 보내는 것은 쉽습니다.

하지만 자신의 도메인에서 수백만 개의 이메일을 안정적으로 전송하는 것은 완전히 다른 문제입니다.

이는 단순한 설정 세부 사항이 아닙니다.

이는 귀하의 이메일이 신뢰받는지, 전달되는지, 아니면 스팸으로 필터링되는지를 결정하는 기반 구조의 일부입니다.

본 가이드에서는 발신 도메인이 어떻게 작동하는지, 왜 중요한지, 그리고 자신의 도메인에서 이메일을 보내기 전에 무엇을 구성해야 하는지 자세히 설명하겠습니다.

발신 도메인이란 무엇인가?

발신 도메인은 나가는 이메일의 신원(identity)으로 사용하는 도메인을 말합니다.

예를 들어, 귀하의 회사가 다음을 소유하고 있다고 가정해 봅시다:

example.com

귀하는 다음과 같은 주소에서 이메일을 보내고 싶을 수 있습니다:

[email protected]
[email protected]
[email protected]
...

일반적인 제공업체 주소를 사용하는 대신, 귀하의 애플리케이션은 자신의 도메인을 사용하여 이메일을 전송합니다.

이는 이메일 신원에 대한 통제권을 부여하며, 자신의 도메인에 특화된 인증을 구성할 수 있게 해줍니다.

이메일 마케팅 플랫폼의 경우, 발신 도메인은 특히 중요합니다. 캠페인이 보내는 비즈니스를 대표해야 하기 때문입니다.

왜 자체 발신 도메인을 사용해야 하는가?

전용 발신 도메인을 설정하는 데에는 몇 가지 이유가 있습니다.

1. 브랜드 일관성 (Brand consistency)

고객들은 이메일을 열어보기 전에 누가 보냈는지 알아야 합니다.

비교해 보세요:

[빈칸]

vs

낯선 일반적인 발신 주소와 비교했을 때.

귀하의 도메인은 브랜드 아이덴티티의 일부가 됩니다.

2. 이메일 인증 (Email authentication)

도메인에는 다음과 같은 인증 메커니즘으로 구성될 수 있습니다:

• SPF
• DKIM
• DMARC

이러한 요소들은 수신 메일 시스템이 메시지가 승인되었는지, 그리고 발신자의 신원이 신뢰할 만한지 평가하는 데 도움을 줍니다.

3. 더 나은 통제력 (Better control)

이메일 인프라를 구축할 때, 발신 도메인을 제어하면 다음 사항에 대한 가시성이 높아집니다:

• 인증 (Authentication)
• 발신 신원 (Sending identities)
• 도메인 구성 (Domain configuration)
• 평판 (Reputation)
• 전달 이벤트 (Delivery events)
• 바운스 처리 (Bounce handling)
• 불만 처리 (Complaint handling)

4. 이메일 트래픽 분리 (Separation of email traffic)

모든 유형의 이메일이 정확히 같은 인프라를 공유할 필요는 없을 수 있습니다.

예를 들어:

marketing.example.com

은 캠페인에 사용될 수 있고, 반면:

mail.example.com

은 애플리케이션 알림에 사용될 수 있습니다.

적절한 아키텍처는 제품, 볼륨, 그리고 평판 전략에 따라 달라집니다.

이메일 인증 작동 방식

이메일을 보낼 때, 수신 메일 서버는 단순히 From 주소를 신뢰하지 않습니다.

서버는 DNS 레코드 및 기타 인증 신호를 확인하여 메시지가 실제로 승인되었는지 판단할 수 있습니다.

가장 중요한 세 가지 기술은 다음과 같습니다:

SPF

DKIM

DMARC

각각 살펴보겠습니다.

SPF: Sender Policy Framework (발신자 정책 프레임워크)

SPF는 도메인 소유자가 해당 도메인을 대신하여 이메일을 보낼 권한이 있는 메일 서버를 지정하는 DNS 레코드를 게시할 수 있도록 합니다.

간소화된 예시는 다음과 같습니다:

example.com TXT
v=spf1 include:mail-provider.example ~all

정확한 레코드는 사용 중인 이메일 인프라에 따라 달라집니다.

수신 서버가 이메일을 받으면, 발신 서버의 IP 주소를 도메인의 SPF 정책과 비교할 수 있습니다.

만약 해당 서버가 승인되지 않았다면, 메시지는 SPF 평가에 실패할 수 있습니다.

중요한 SPF 제한 사항

SPF에는 DNS 조회 한계가 있습니다.

조회 한계를 고려하지 않고 계속해서 제공업체와 include 구문을 추가하면, 결국 SPF 구성이 실패할 수 있습니다.

이것이 이메일 인프라를 새로운 제공업체가 도입될 때마다 지속적으로 DNS 레코드를 추가하는 대신 신중하게 설계해야 하는 이유 중 하나입니다.

DKIM: DomainKeys Identified Mail (도메인 키 식별 메일)

DKIM은 발신되는 이메일에 암호화 서명을 추가합니다.

발신 시스템은 개인 키(private key)로 메시지에 서명합니다.

해당 공개 키(public key)는 DNS를 통해 게시됩니다.

간소화된 DKIM DNS 레코드는 다음과 같을 수 있습니다:

selector1._domainkey.example.com

값에는 공개 키가 포함되어 있습니다.

이메일이 도착하면, 수신 서버는 공개 키를 검색하여 서명을 검증할 수 있습니다.

이는 메시지가 DKIM 서명과 연결된 도메인에 의해 승인되었으며, 메시지의 중요한 부분이 서명 후 수정되지 않았음을 확립하는 데 도움이 됩니다.

DKIM은 프로덕션 이메일 전송 시스템을 구축할 때 특히 중요합니다.

DMARC: 도메인 기반 메시지 인증

DMARC는 SPF와 DKIM을 기반으로 합니다.

이는 도메인 소유자가 수신 서버가 적절하게 인증되지 않은 메시지를 어떻게 처리해야 하는지를 설명하는 정책을 게시할 수 있도록 합니다.

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

_dmarc.example.com TXT
v=DMARC1; p=none

도메인은 이메일 인증이 이해되고 모니터링됨에 따라 점진적으로 더 엄격한 정책으로 이동할 수 있습니다.

예를 들어:

p=none

은 모니터링 중에 유용할 수 있습니다.

그 후 합법적인 전송 출처가 검증된 후에 더 제한적인 정책을 도입할 수 있습니다.

중요한 부분은 단순히 DMARC 레코드를 추가하는 것이 아닙니다.

엄격한 정책을 시행하기 전에 어떤 시스템이 귀하의 도메인에 대해 합법적으로 이메일을 전송하고 있는지 이해해야 합니다.

DNS 설정

전송 도메인을 이메일 플랫폼에 추가할 때, 일반적으로 구성할 DNS 레코드를 받게 됩니다.

여기에는 제공업체와 구성에 따라 다음이 포함될 수 있습니다:

TXT
CNAME
MX

예를 들어, 이메일 플랫폼은 다음과 같은 DKIM CNAME 레코드를 제공할 수 있습니다:

selector1._domainkey.example.com
selector2._domainkey.example.com

귀하의 DNS 제공업체는 다음 중 하나일 수 있습니다:

• Cloudflare
• Route 53
• GoDaddy
• Namecheap
• Vercel DNS
• DigitalOcean
• 다른 도메인 제공업체

제공업체마다 인터페이스가 다르지만, 근본적인 DNS 개념은 동일하게 유지됩니다.

일반적인 전송 도메인 워크플로우

프로덕션 이메일 플랫폼은 이 프로세스를 사용자에게 훨씬 간단하게 만들 수 있습니다.

워크플로우는 다음과 같을 수 있습니다:

도메인 추가
    ↓
DNS 레코드 생성
...

이것은 저희가 Cresca에서 새로운 Sending Domains 기능을 통해 최근에 도입한 워크플로우입니다.

Cresca의 전송 도메인

우리는 이메일 인프라가 사용자들에게 여러 시스템에 걸쳐 모든 것을 수동으로 관리하도록 요구해서는 안 된다고 생각하여 Sending Domains를 구축했습니다.

Cresca 내에서 사용자는 자신의 도메인을 추가하고 발신 설정에 필요한 DNS 구성을 받을 수 있습니다.

일반적인 흐름은 다음과 같습니다:

Cresca 대시보드
      ↓
Sending Domains
...

도메인이 검증되면 이메일 전송 설정의 일부로 사용할 수 있습니다.

이는 특히 Cresca를 사용하여 다음 작업을 수행하는 팀에게 유용합니다:

• 이메일 마케팅
• SaaS 알림
• 트랜잭션 이메일
• 제품 업데이트
• 고객 커뮤니케이션
• 자동화 캠페인

마케팅 이메일 vs 트랜잭션 이메일

모든 이메일이 같지 않다는 것을 이해하는 것도 중요합니다.

마케팅 이메일

예시:

제품 공지

프로모션 캠페인
...

이러한 이메일은 일반적으로 마케팅 목적으로 청중에게 전송됩니다.

트랜잭션 이메일

이것들은 사용자 또는 애플리케이션의 동작에 의해 트리거됩니다.

예시:

환영 이메일
비밀번호 재설정 이메일
주문 확인서
...

인프라는 겹칠 수 있지만, 발신 전략과 평판 고려 사항은 다를 수 있습니다.

SaaS 제품의 경우, 전송량이 증가함에 따라 이메일 아키텍처를 체계적으로 유지하는 것이 점점 더 중요해집니다.

반송 및 불만 처리 무시하지 마세요

도메인 인증은 이메일 전달 가능성(deliverability)의 한 부분일 뿐입니다.

이메일이 전송된 후에 발생하는 일에도 주의를 기울여야 합니다.

예를 들어:

이메일 전송됨
   ↓
전달됨
...

하지만 다른 경로는 다음과 같을 수 있습니다:

이메일 전송됨
   ↓
하드 바운스(Hard Bounce)
...

또는:

이메일 전송됨
   ↓
스팸 불만 신고
...

영구적으로 반송된 주소로 계속해서 반복적으로 보내는 것은 나쁜 전략입니다.

운영 이메일 시스템은 전달 이벤트를 처리하고 억제(suppression) 정보를 유지해야 합니다.

발신 평판이 중요한 이유

이메일 제공업체들은 사용자의 메시지를 고립적으로 평가하지 않습니다.

발신 행동은 귀하의 인프라 및 도메인과 관련된 평판에 기여합니다.

수신자 품질이 낮으면 다음과 같은 문제가 발생할 수 있습니다:

• 높은 반송률 (bounce rates)
• 스팸 신고 (Spam complaints)
• 전달 가능성 감소 (Reduced deliverability)
• 제공자 속도 제한 (Provider throttling)
• 평판 문제 (Reputation problems)

이는 이메일 마케팅이 단순히 다음의 과정만은 아니라는 것을 의미합니다:

작성 → 전송 클릭

더 현실적인 시스템은 다음과 같은 형태를 띱니다:

잠재 고객 (Audience)
   ↓
검증 (Validation)
...

이 전체 피드백 루프가 중요합니다.

간단한 운영 체크리스트

도메인에서 실제 이메일을 전송하기 전에 다음 사항들을 확인하세요.

도메인

• 해당 도메인은 귀하의 조직이 소유하고 통제하는가
• DNS 접근 권한을 확보했는가
• 발신 신원(Sending identity)이 구성되었는가

인증 (Authentication)

• SPF가 올바르게 설정되었는가
• DKIM이 구성 및 검증되었는가
• DMARC가 구성되었는가
• 합법적인 발신 출처(sending sources)가 문서화되었는가

전송 인프라 (Sending infrastructure)

• 전송 제공자(Sending provider)가 구성되었는가
• 반송 이벤트(Bounce events)를 처리하는가
• 신고 이벤트(Complaint events)를 처리하는가
• 억제 시스템(Suppression system)이 활성화되었는가
• 전송 제한(Sending limits)을 이해하고 있는가

애플리케이션 (Application)

• '보낸 사람' 주소(From address)를 통제하는가
• 사용자가 임의로 발신자 신원을 위조할 수 없는가
• 전송 전에 도메인 검증을 수행하는가
• 캠페인 수신자를 책임감 있게 관리하는가

모니터링 (Monitoring)

• 전달률(Delivery rate)을 모니터링하는가
• 반송률(Bounce rate)을 모니터링하는가
• 신고율(Complaint rate)을 모니터링하는가
• 도메인 평판(Domain reputation)을 모니터링하는가

이것을 구축하며 배운 것들

이메일 인프라를 구축하면서 얻은 가장 큰 교훈 중 하나는 이메일을 보내는 것은 쉬운 부분이라는 것입니다.

어려운 부분은 전송 주변에 시스템을 구축하는 것입니다.

다음 사항들을 고려해야 합니다:

신원 (Identity)
인증 (Authentication)
인프라 (Infrastructure)
...

좋은 이메일 플랫폼은 사용자에게 필요한 만큼의 가시성과 통제권을 제공하면서도 이러한 복잡성 대부분을 숨겨주어야 합니다.

이것이 Cresca가 나아가고 있는 방향입니다.

Cresca에 전송 도메인이 라이브되었습니다

이제 Cresca에 발신 도메인(Sending Domains) 기능이 추가되어 팀들이 자체 도메인을 연결하고 자신들의 브랜드 중심으로 이메일 발송 환경을 구축할 수 있게 되었습니다.

도메인 설정을 별도의 기술적 작업으로 취급하기보다는, 이제는 이메일 워크플로우 자체의 일부가 되고 있습니다.

만약 SaaS 제품을 개발하거나, 이메일 캠페인을 운영하거나, 트랜잭션 이메일을 발송하는 경우라면, 발신 도메인에 대한 통제권은 중요한 기반이 됩니다.

당신의 도메인. 당신의 브랜드. 당신의 이메일.

Cresca는 여기서 확인하실 수 있습니다:

[https://www.cresca.xyz/]

최종 생각 (Final Thoughts)

이메일 전달 가능성(Email deliverability)은 단 하나의 DNS 레코드로 해결되지 않습니다.

이는 다음 요소들의 조합입니다:

인증(Authentication) + 수신자 품질(recipient quality) + 발송 행태(sending behavior) + 모니터링(monitoring) + 평판(reputation).

발신 도메인을 올바르게 설정하는 것이 첫 번째 단계 중 하나입니다.

그리고 이메일 볼륨이 증가함에 따라, 이러한 인프라를 이메일 플랫폼 자체에 구축해 놓는 것은 상당한 양의 엔지니어링 및 운영 작업을 절약할 수 있습니다.

이것이 바로 우리가 Cresca로 구현하고 있는 것입니다.