Salesforce를 통해 회사 도메인 명의로 이메일을 보낼 수는 있지만, 그것만으로는 그 이메일이 정말 회사가 보낸 것임을 증명하지 못합니다. 이를 증명하는 것이 DMARC입니다. DMARC는 Gmail과 Outlook 같은 메일 제공업체가 메시지가 도메인 소유자의 허가를 받아 발송되었는지 확인할 때 사용하는 이메일 보안 표준입니다. 각 Salesforce 제품에서 짧은 인증 설정을 완료하기 전까지는, Salesforce로 보내는 모든 이메일이 이 확인을 통과하지 못해 스팸함에 들어가거나 아예 거부될 수 있습니다.
해결 방법은 잘 문서화되어 있지만, 설정 방식이 서로 다른 여러 Salesforce 제품에 흩어져 있습니다. 이 가이드는 기본 Salesforce 구성에서 인증 공백이 어디에 있는지, 그리고 Sales Cloud, Account Engagement(구 Pardot), Marketing Cloud Engagement 각각에서 이를 어떻게 해결하는지 설명합니다.
Salesforce를 통해 이메일을 발송하면 그 이메일은 회사의 자체 시스템에서 나가는 것이 아닙니다. Salesforce의 서버가 메시지를 만들어 수신자에게 전달하고, From 줄에는 회사의 주소가 표시됩니다. 이 서버들은 Salesforce의 자체 도메인에서 운영되고 Salesforce의 자체 설정을 사용하며, 회사가 제어하는 영역과는 분리되어 있습니다.
Gmail이나 Outlook 같은 메일 제공업체는 From 주소만 보고 신뢰하지 않습니다. 누구나 어떤 주소든 입력할 수 있기 때문입니다. 대신 기술적인 증거를 확인합니다. 어떤 서버가 메시지를 전달했는지, 그리고 어떤 도메인이 그 메시지를 보증했는지를 봅니다.
DMARC는 수신자에게 보이는 From 주소의 도메인이 메시지를 인증한 도메인과 같은지 판별합니다. 두 도메인이 일치하면 수신 서버는 그 이메일이 회사가 보낸 것임을 알 수 있습니다. 이 일치를 정렬(Alignment)이라고 하는데, 기본 Salesforce 구성은 DMARC 정렬을 제공하지 않습니다. 메시지는 Salesforce 명의로 인증되는 반면, 수신자에게 보이는 이름은 회사의 도메인이기 때문입니다.
그다음에 일어나는 일은 회사의 DMARC 정책에 따라 달라집니다. p=none에서는 메일이 그대로 도착하고 실패 내역은 보고서에만 나타납니다. p=quarantine이나 p=reject에서는 수신 서버가 정렬되지 않은 메일을 스팸함으로 보내거나 수신을 거부하며, 캠페인 이메일이 받은편지함에 도달하지 못하게 됩니다.
모든 이메일에는 두 개의 발신자 주소가 있습니다. From 주소는 수신자에게 보이는 주소입니다. 반환 경로(return path)는 전송 실패, 즉 반송(bounce)이 전달되는 숨겨진 주소입니다. DMARC의 SPF 검증은 반환 경로를 봅니다. SPF 정렬이 성립하려면 반환 경로의 도메인이 From 도메인과 일치해야 합니다.
Salesforce가 대신 발송할 때 메시지는 Salesforce의 메일 서버에서 나가며, 기본 설정에서 반환 경로에는 회사의 도메인이 아니라 Salesforce가 운영하는 도메인이 사용됩니다. 이는 플랫폼의 일반적인 동작 방식이고, 회사 쪽에서 아무 설정을 하지 않아도 반송 처리가 계속 작동하게 해 줍니다. 동시에 회사의 도메인은 기본 상태에서 인증되지 않은 채로 남는다는 뜻이기도 합니다.
각 Salesforce 제품은 저마다의 인프라를 통해 발송하고 저마다의 인증 설정을 갖습니다. Sales Cloud는 팀이 CRM에서 보내는 이메일을 담당합니다. Account Engagement는 마케팅 자동화와 잠재 고객 육성 캠페인을 운영합니다. Marketing Cloud Engagement는 대량 캠페인 발송을 처리합니다. 한 제품을 설정해도 나머지 제품이 함께 설정되지는 않습니다.
여기서 중요한 주소는 두 가지입니다. 수신자에게 보이는 From 주소, 그리고 전송 실패가 전달되는 숨겨진 반환 경로입니다. DMARC는 반환 경로가 회사의 도메인을 사용할 때에만 SPF 통과를 인정합니다. 기본 Salesforce 설정에서는 반환 경로가 회사의 도메인을 사용하는 경우가 없습니다.
Account Engagement를 예로 들어 보겠습니다. Account Engagement가 보내는 메시지의 반환 경로는 Salesforce 소유 도메인에 있으며, Salesforce의 DMARC 지원 문서에 따르면 bounce.s7.exacttarget.com 같은 주소가 사용됩니다. 수신 서버가 SPF 검증을 실행하면 회사의 도메인이 아니라 이 Salesforce 도메인을 확인합니다. 검증은 통과할 수 있지만, 증명하는 대상이 잘못되었습니다. Salesforce의 도메인을 보증할 뿐, 회사의 도메인은 증명되지 않은 상태로 남습니다. DMARC는 이를 실패로 처리합니다.
Sales Cloud에서도 같은 불일치가 생길 수 있습니다. Bounce Management나 Email Security Compliance 기능이 켜져 있으면 Salesforce는 Salesforce의 SPF 및 DKIM FAQ에 설명된 대로 반환 경로를 Salesforce 도메인의 반송 추적 주소로 교체합니다. 두 도메인이 더 이상 일치하지 않으므로, DMARC의 SPF 검증은 같은 이유로 실패합니다.
이미 SPF 레코드에 Salesforce의 include 항목인 include:_spf.salesforce.com을 추가해 두었을 수도 있습니다. 이 항목은 그대로 유지하세요. Salesforce의 서버가 회사 도메인 명의로 발송하도록 허가되었음을 수신 서버에 알려 주기 때문입니다. 다만 이 항목이 반환 경로를 바꾸지는 않으므로, 이것만으로는 불일치를 해결할 수 없습니다.
이 때문에 Salesforce에서는 DKIM이 신뢰할 수 있는 방법입니다. DKIM 서명은 메시지 자체에 담겨 함께 이동하고, 어느 서버가 메일을 전달하든 회사의 도메인에 직접 연결됩니다. DKIM 키를 설정하고 나면 Salesforce가 모든 메시지에 회사 도메인 명의로 서명하고, DMARC는 필요한 증거를 갖추게 됩니다.
각 Salesforce 제품에는 한 번의 설정 작업이 필요하고, 각 작업은 회사 도메인에 새 DNS 레코드 몇 개를 게시하는 것으로 마무리됩니다. 회사의 DNS 설정에 접근할 수 없다면 이 섹션을 접근 권한이 있는 담당자에게 공유하세요. 담당자에게 필요한 내용이 모두 들어 있습니다. 직접 접근할 수 있다면 아래 단계를 그대로 따라 하면 됩니다.
설정이 다른 담당자의 손에 맡겨져 있다면 Salesforce 이메일이 DMARC를 통과하는지 확인하는 단계로 바로 건너뛰어도 됩니다.
Salesforce Setup에서 Email, DKIM Keys 순서로 이동해 DKIM 키를 생성합니다. 2048비트 키를 선택하고 도메인을 발송 도메인으로 설정하세요. 그러면 Salesforce가 CNAME 레코드를 제공하는데, 이는 회사 도메인에 게시하는 작은 DNS 항목입니다. 레코드가 반영되면 키를 활성화하세요. 그 이후에는 Salesforce가 30일마다 키를 자동으로 교체하므로 별도의 유지 관리가 필요 없습니다.
설정의 흐름은 동일합니다. Account Engagement가 발송 도메인용 DKIM 레코드를 생성하면 이를 DNS에 게시하고, 그때부터 Account Engagement가 회사 도메인 명의로 이메일에 서명합니다. 이 점에 대한 Salesforce의 안내는 명확합니다. DKIM이 올바르게 구성되어 있으면 DMARC는 통과합니다.
Salesforce 문서에 나오는 두 가지 주의 사항도 알아 둘 필요가 있습니다. 이메일 발송 도메인과 트래커 도메인은 분리해서 사용해야 합니다. 두 용도에 같은 도메인을 쓰면 인증 오류가 발생합니다. 또한 SPF 정렬까지 원한다면 사용자 지정 반환 경로가 필요하며, 이는 Account Engagement 지원 케이스를 통해 요청합니다.
Marketing Cloud는 설정 변경이 아니라 구매가 필요한 유일한 경우입니다. Sender Authentication Package에 포함된 Private Domain 제품은 Salesforce의 Private Domain FAQ에 안내된 대로 전용 발송 도메인에 DKIM, SPF, DMARC 인증을 적용합니다. 대부분의 팀은 mail.example.com 같은 하위 도메인을 위임하고 해당 레코드의 관리를 Salesforce에 맡깁니다. 조직이 DNS를 직접 호스팅하는 경우에는 회사의 DNS 팀이 그 레코드를 유지 관리하며, Salesforce 지원팀은 자체 호스팅 DNS 문제를 지원하지 않습니다.
어떤 제품을 사용하든 DNS 변경 하나를 더해야 설정이 완성됩니다. 회사 도메인의 SPF 레코드에 include:_spf.salesforce.com을 추가하세요. 정렬은 여전히 DKIM에서 나오지만, 완전한 SPF 레코드는 Salesforce 메일이 거치는 모든 경로에서 기본 인증을 유지해 줍니다.
빠른 테스트에는 메시지 하나면 충분합니다. 각 Salesforce 제품에서 직접 관리하는 메일함으로 이메일을 보내고, 메시지 헤더를 열어 dkim=pass와 함께 d= 값에 회사 도메인이 표시되는지 확인하세요. 서명이 Salesforce 소유 도메인으로 통과했다면 회사 도메인의 DKIM 설정이 아직 끝나지 않았다는 뜻입니다.
DNS 쪽은 아래 검사 도구로 몇 초 만에 확인할 수 있습니다. 회사 도메인에 유효한 DKIM 레코드가 게시되어 있는지 보여 줍니다.
가장 확실한 확인 수단은 회사의 DMARC 데이터입니다. DMARC 집계 보고서에는 Salesforce의 IP 대역을 포함해 회사 도메인 명의로 발송하는 모든 발신원이 나열되고, 각 메시지가 정렬을 갖춰 통과했는지 표시됩니다. 보고서에 Salesforce 트래픽이 실패로 나타나면, SPF와 DKIM 중 어느 쪽을 손봐야 하는지도 보고서가 알려 줍니다. DMARCeye의 무료 플랜은 도메인 1개를 지원하며, 원시 보고서를 발신원과 다음 단계가 정리된 읽기 쉬운 목록으로 바꿔 줍니다. DNS 변경이 반영되는 동안 Salesforce 발신원이 실패에서 정렬 상태로 바뀌는 과정을 지켜볼 수 있습니다.
플랫폼의 기본 설정은 회사의 도메인이 아니라 플랫폼 자신을 인증합니다. 해결 방법은 Salesforce의 문서에도 분명하게 나와 있습니다. 회사 도메인 명의로 발송하는 모든 Salesforce 제품에 DKIM을 설정하고, SPF 레코드에 include:_spf.salesforce.com을 유지하세요. 성공 여부는 단순한 SPF나 DKIM 통과가 아니라 정렬을 기준으로 판단해야 합니다.
필요한 작업은 DNS 레코드 몇 개가 전부이며, Salesforce 메일이 회사 도메인 명의로 통과하고 있다는 사실을 며칠 안에 DMARC 보고서로 확인할 수 있습니다. DMARCeye는 이 보고서를 대신 모니터링하고 여전히 조치가 필요한 발신원을 짚어 줍니다.