export type BlogFaq = { answer: string; question: string; }; export type BlogSection = { bullets?: string[]; callout?: { body: string; title: string; }; id: string; paragraphs: string[]; steps?: Array<{ body: string; title: string; }>; table?: { headers: string[]; rows: string[][]; }; title: string; }; export type BlogPost = { category: string; description: string; faqs: BlogFaq[]; heroImage: { alt: string; src: string; }; highlights: Array<{ body: string; title: string; }>; intro: string; keywords: string[]; publishedAt: string; relatedLink: { href: string; label: string; }; readingMinutes: number; references: Array<{ href: string; label: string; note: string; }>; sections: BlogSection[]; slug: string; summary: string; title: string; updatedAt: string; }; export const blogPosts: BlogPost[] = [ { slug: "gabia-domain-email-setup", category: "도메인 연결", title: "가비아 도메인 메일 설정 방법: MX·SPF·DKIM을 한 번에 점검하기", description: "가비아에서 보유한 도메인으로 기업메일을 쓰는 방법을 정리했습니다. MX, SPF, DKIM 레코드의 역할과 입력 순서, 연결 확인 방법까지 안내합니다.", summary: "가비아 DNS 관리 화면에서 도메인 메일을 연결할 때 필요한 레코드와 확인 순서를 정리한 가이드입니다.", intro: "도메인을 구매했다고 바로 contact@내도메인.com 주소로 메일을 받을 수 있는 것은 아닙니다. 메일을 어느 서버로 받을지, 그 도메인에서 메일을 보낼 권한이 있는지를 DNS에 알려야 합니다. 이 글은 가비아에서 도메인을 관리하는 사업자가 오피셜메일에 도메인 메일을 연결할 때 필요한 설정 순서를 설명합니다.", heroImage: { alt: "도메인에서 MX·SPF·DKIM·DMARC를 거쳐 메일 서버로 연결되는 DNS 구성", src: "/blog/generated/gabia-domain-email-dns.webp", }, highlights: [ { title: "MX", body: "메일을 받을 서버를 지정합니다." }, { title: "SPF", body: "도메인으로 발송할 서버를 허용합니다." }, { title: "DKIM", body: "발송 메일에 도메인 서명을 붙입니다." }, ], keywords: [ "가비아 도메인 메일 설정", "가비아 기업메일 설정", "가비아 MX 설정", "가비아 SPF DKIM", "도메인 이메일 만들기", ], publishedAt: "2026-07-22T09:00:00+09:00", updatedAt: "2026-07-24T09:00:00+09:00", relatedLink: { href: "/guide#domain", label: "도메인 연결 가이드에서 레코드 입력 예시 보기" }, readingMinutes: 6, references: [ { href: "https://customer.gabia.com/faq/detail/3041/3040", label: "가비아 DNS 레코드 설정 매뉴얼", note: "DNS 관리툴의 메뉴 위치와 레코드 추가·저장 순서를 확인했습니다.", }, { href: "https://customer.gabia.com/faq/detail/227/2521", label: "가비아 DNS 관리툴 레코드별 기능", note: "MX 우선순위와 TXT(SPF) 레코드의 역할을 확인했습니다.", }, { href: "https://support.google.com/mail/answer/81126?hl=ko", label: "Google 이메일 발신자 가이드라인", note: "Gmail 발송에 필요한 SPF·DKIM·DMARC 인증 기준을 확인했습니다.", }, ], sections: [ { id: "before-start", title: "시작 전에 준비할 것", paragraphs: [ "도메인 메일 연결은 도메인 소유권을 가진 사람이 DNS 레코드를 수정할 수 있어야 진행할 수 있습니다. 가비아에서 도메인을 구매했더라도 네임서버를 다른 서비스로 변경한 경우에는 실제 DNS를 관리하는 서비스에서 값을 입력해야 합니다.", "오피셜메일 가입 후 도메인 연결 화면에서 사용할 도메인과 대표 메일 주소를 먼저 등록하세요. 화면에 표시되는 레코드 값은 해당 도메인에 맞춰 발급된 값이므로, 다른 회사나 예전 설정에서 복사한 DKIM 키를 사용하면 안 됩니다.", ], bullets: [ "도메인 관리 권한 또는 DNS 관리 권한", "대표 메일 주소 예: contact@내도메인.com", "오피셜메일 도메인 연결 화면에 표시된 최신 레코드 값", ], callout: { title: "www는 도메인이 아닙니다", body: "가입 또는 연결 화면에는 www.내도메인.com이 아니라 내도메인.com을 입력합니다. www는 홈페이지 접속용 호스트 이름이며, 메일 도메인은 보통 루트 도메인을 기준으로 설정합니다.", }, }, { id: "records", title: "MX·SPF·DKIM은 각각 무엇을 하나요?", paragraphs: [ "MX는 고객이 내도메인.com으로 메일을 보냈을 때 어느 메일 서버가 수신할지를 정합니다. MX가 맞지 않으면 메일이 오피셜메일 메일함으로 들어오지 않거나 기존 메일 서비스로 계속 들어갈 수 있습니다.", "SPF와 DKIM은 발신 인증에 사용됩니다. SPF는 이 도메인으로 발송할 수 있는 서버를 선언하고, DKIM은 발송 메일에 전자서명을 붙여 수신 서버가 도메인 발송 여부를 검증할 수 있게 합니다. 특히 Gmail 등 외부 수신처에서 반송이나 스팸 분류를 줄이려면 두 항목을 함께 확인하는 것이 좋습니다.", ], table: { headers: ["레코드", "역할", "가비아 입력 위치"], rows: [ ["MX", "수신 메일 경로", "호스트 @, 우선순위와 메일 서버 값 입력"], ["SPF", "발송 서버 선언", "호스트 @, TXT 값 입력"], ["DKIM", "발신 서명 검증", "호스트 dkim._domainkey, TXT 값 입력"], ["DMARC", "인증 실패 처리 정책", "호스트 _dmarc, TXT 값 입력"], ], }, }, { id: "gabia-steps", title: "가비아 DNS에서 설정하는 순서", paragraphs: [ "가비아 공식 매뉴얼 기준 경로는 **My가비아 → 서비스 관리 → DNS 관리툴 → 대상 도메인 오른쪽의 설정 → 레코드 수정 → + 레코드 추가**입니다. 값을 입력한 다음 각 행의 확인을 누르고 화면 아래 저장까지 눌러야 반영됩니다.", "기존에 다른 메일 서비스에서 사용하던 MX 또는 SPF 레코드가 있다면 바로 삭제하지 말고, 현재 사용 중인 메일함이 있는지 먼저 확인하세요. 수신 경로를 바꾸는 순간 기존 서비스의 수신도 영향을 받습니다.", ], steps: [ { title: "오피셜메일에서 레코드 값 열기", body: "메일함의 도메인 연결 화면에서 MX, SPF, DKIM, DMARC 항목을 확인합니다. DKIM은 현재 도메인에 발급된 값을 그대로 사용합니다.", }, { title: "가비아에서 MX 레코드 추가 또는 교체", body: "호스트는 보통 @로 두고, 오피셜메일 화면의 메일 서버와 우선순위를 입력합니다. 이전 MX 레코드가 남아 있으면 수신 경로가 분산될 수 있으므로 현재 메일 서비스 사용 여부를 확인합니다.", }, { title: "TXT 레코드로 SPF와 DKIM 입력", body: "SPF는 루트 호스트(@), DKIM은 dkim._domainkey 호스트에 입력합니다. 한 도메인에 SPF TXT 레코드를 여러 개 만들면 인증이 실패할 수 있으므로 기존 SPF가 있다면 하나의 정책으로 합칩니다.", }, { title: "도메인 연결 화면에서 상태 확인", body: "저장 직후에는 DNS 전파 시간이 필요할 수 있습니다. 연결 상태 확인을 눌러 MX, SPF, DKIM 항목을 각각 검증하고, 완료 후 외부 주소로 테스트 수신·발신을 해봅니다.", }, ], table: { headers: ["유형", "호스트", "입력 기준", "우선순위"], rows: [ ["MX", "@", "오피셜메일 화면의 메일 서버 값", "화면에 표시된 값"], ["TXT(SPF)", "@", "v=spf1로 시작하는 정책 전체", "-"], ["TXT(DKIM)", "dkim._domainkey", "현재 도메인에 발급된 공개키 전체", "-"], ["TXT(DMARC)", "_dmarc", "v=DMARC1로 시작하는 정책 전체", "-"], ], }, }, { id: "check", title: "연결 완료 후에는 수신과 발신을 따로 확인하세요", paragraphs: [ "도메인 연결 완료 표시는 DNS 레코드를 조회해 설정값이 맞는지 확인한 결과입니다. 실제 운영 전에는 외부 Gmail 또는 네이버 메일에서 대표 주소로 테스트 메일을 보내 수신되는지 확인하고, 반대로 대표 주소에서 외부 주소로 메일을 보내 발신이 도착하는지도 확인해야 합니다.", "발신 메일이 도착했더라도 스팸함으로 들어가거나 인증 실패 문구가 보이면 SPF와 DKIM을 다시 확인하세요. DNS 관리 화면에서 긴 TXT 값이 줄바꿈되더라도 DNS 조회 결과에서는 하나의 값으로 연결되어야 합니다.", ], bullets: [ "외부 주소 → 대표 주소: 수신 경로 확인", "대표 주소 → 외부 주소: 발신 및 스팸 분류 확인", "보낸 메일 원문: SPF, DKIM 인증 결과 확인", "오피셜메일 도메인 연결 화면: 레코드별 검증 상태 확인", ], }, { id: "dns-command-check", title: "관리 화면과 실제 DNS 응답이 같은지 확인하는 방법", paragraphs: [ "DNS 관리 화면에 값이 보이는 것과 인터넷에서 실제로 조회되는 것은 다를 수 있습니다. 네임서버가 가비아가 아니거나 저장이 끝나지 않았다면 오피셜메일 검증에서도 레코드를 찾을 수 없습니다. 아래 명령의 `내도메인.com`을 연결할 도메인으로 바꿔 확인하세요.", "```powershell\nResolve-DnsName 내도메인.com -Type MX\nResolve-DnsName 내도메인.com -Type TXT\nResolve-DnsName dkim._domainkey.내도메인.com -Type TXT\nResolve-DnsName _dmarc.내도메인.com -Type TXT\n```", "macOS 또는 Linux에서는 `dig MX 내도메인.com`, `dig TXT 내도메인.com`, `dig TXT dkim._domainkey.내도메인.com`처럼 확인할 수 있습니다. DKIM 응답이 여러 문자열로 나뉘어 보이더라도 공백 없이 이어 붙였을 때 하나의 `v=DKIM1;` 값이 되면 정상적인 TXT 분할일 수 있습니다.", ], callout: { title: "SERVFAIL은 단순 전파 지연과 다를 수 있습니다", body: "NXDOMAIN은 레코드가 없다는 뜻이고, SERVFAIL은 권한 네임서버나 DNSSEC 설정 오류일 수 있습니다. 여러 공용 DNS에서도 SERVFAIL이 반복되면 도메인 DNS 운영사에 권한 네임서버 상태를 문의하세요.", }, }, ], faqs: [ { question: "가비아에서 DNS를 저장했는데 바로 연결 완료가 되지 않습니다.", answer: "DNS 반영에는 시간이 필요할 수 있습니다. 먼저 레코드의 호스트, 값, 우선순위를 다시 확인하고, 기존 MX 또는 중복 SPF 레코드가 남아 있지 않은지 점검하세요. 시간이 지난 뒤 오피셜메일 도메인 연결 화면에서 다시 확인하면 됩니다.", }, { question: "DKIM TXT 값이 너무 길어 가비아에 입력하기 어렵습니다.", answer: "긴 DKIM 키는 DNS 서비스 화면에서 구간으로 나뉘어 보일 수 있습니다. 오피셜메일 도메인 연결 화면의 DKIM 호환 모드가 제공되는 경우 1024-bit 키를 발급해 등록할 수 있습니다. 발급한 뒤에는 반드시 새 값으로 교체해야 합니다.", }, { question: "기존 메일 서비스도 함께 쓰고 있습니다.", answer: "MX 변경은 수신 경로에 직접 영향을 줍니다. 이전 메일함에 중요한 수신이 남아 있다면 전환 전 수신 정책과 이전 데이터 보관 방법을 정한 뒤 변경하세요.", }, ], }, { slug: "gmail-550-spf-dkim-fix", category: "메일 반송 해결", title: "Gmail 550 5.7.26 해결 방법: SPF와 DKIM 인증 실패 점검 순서", description: "Gmail에서 550 5.7.26 sender unauthenticated 반송이 발생했을 때 SPF와 DKIM을 점검하는 방법을 정리했습니다. 원인별 확인 순서와 도메인 DNS 설정 기준을 안내합니다.", summary: "Gmail이 발신자 인증 실패로 메일을 거절할 때 확인해야 할 SPF·DKIM·도메인 DNS 점검 가이드입니다.", intro: "Gmail로 메일을 보냈는데 550 5.7.26, sender unauthenticated, SPF did not pass, DKIM did not pass 같은 반송 문구가 보이면 발신 도메인 인증이 통과하지 못한 상태입니다. 수신자 주소가 잘못된 문제가 아니라 도메인의 DNS 설정과 실제 발송 서버가 일치하는지 확인해야 합니다.", heroImage: { alt: "메일이 SPF와 DKIM 인증 게이트를 통과하기 전 오류를 진단하는 과정", src: "/blog/generated/gmail-550-authentication.webp", }, highlights: [ { title: "SPF 확인", body: "실제 발송 서버가 정책에 포함됐는지 봅니다." }, { title: "DKIM 확인", body: "현재 공개키와 메일 서명이 일치해야 합니다." }, { title: "새 메일 재시험", body: "DNS 반영 후 기존 큐가 아닌 새 메일로 확인합니다." }, ], keywords: [ "Gmail 550 5.7.26 해결", "SPF did not pass", "DKIM did not pass", "Gmail 메일 반송 해결", "sender unauthenticated", ], publishedAt: "2026-07-22T09:00:00+09:00", updatedAt: "2026-07-24T09:00:00+09:00", relatedLink: { href: "/guide#troubleshooting", label: "메일 반송 문제 해결 순서 더 보기" }, readingMinutes: 7, references: [ { href: "https://support.google.com/mail/answer/81126?hl=ko", label: "Google 이메일 발신자 가이드라인", note: "5.7.26 거절 조건과 SPF·DKIM·DMARC, PTR, TLS 요구사항을 확인했습니다.", }, { href: "https://support.google.com/a/answer/33786?hl=ko", label: "Google SPF 설정 안내", note: "SPF 레코드 구성과 발송 서비스 포함 원칙을 확인했습니다.", }, ], sections: [ { id: "meaning", title: "550 5.7.26은 무엇을 뜻하나요?", paragraphs: [ "이 오류는 Gmail이 발신 도메인을 인증할 수 없어서 메일을 거절했다는 뜻입니다. 반송 메일에는 보통 SPF와 DKIM 중 어떤 항목이 통과하지 않았는지 함께 표시됩니다. 둘 중 하나만 실패한 경우도 있지만, 둘 다 실패하면 우선 도메인 DNS와 발송 경로를 함께 점검해야 합니다.", "같은 발신 주소라도 어떤 수신자에게는 도착하고 Gmail에는 반송될 수 있습니다. 수신 서비스마다 인증 정책이 다르기 때문입니다. 따라서 한 주소로만 테스트해 정상이라고 판단하지 말고 Gmail 수신 테스트를 별도로 해야 합니다.", ], callout: { title: "코드 문제가 아닙니다", body: "이 반송은 웹사이트 코드나 메일 작성 화면 문제가 아니라, 발신 도메인이 실제 메일 서버를 허용하고 서명하고 있는지에 대한 DNS 인증 문제입니다.", }, }, { id: "spf", title: "SPF는 발송 서버와 도메인을 연결합니다", paragraphs: [ "SPF는 도메인 이름으로 메일을 보낼 수 있는 서버를 TXT 레코드에 선언하는 방식입니다. Gmail이 메일을 받으면 보낸 서버 IP와 도메인의 SPF 정책을 대조합니다. 현재 사용하는 메일 서버가 정책에 포함되지 않으면 SPF는 실패합니다.", "가장 흔한 실수는 SPF 레코드를 두 개 이상 만드는 것입니다. 루트 도메인(@)에 SPF TXT 레코드는 하나만 두고, 기존 서비스와 오피셜메일을 함께 사용하는 경우 필요한 발송 경로를 하나의 SPF 정책에 합쳐야 합니다.", ], bullets: [ "메일의 From 주소 도메인과 SPF를 조회한 도메인이 일치하는지 확인", "현재 발송 서버가 SPF 정책에 포함되는지 확인", "루트 도메인에 v=spf1로 시작하는 TXT 레코드가 하나인지 확인", "이전 메일 서비스의 SPF를 남겨야 하는지 확인", ], }, { id: "dkim", title: "DKIM은 메일 내용에 도메인 서명을 붙입니다", paragraphs: [ "DKIM은 발송 서버가 메일에 서명하고, 수신 서버가 DNS에 공개된 키로 그 서명을 확인하는 방식입니다. DKIM이 실패한다는 것은 DNS에 키가 없거나, 다른 키가 등록돼 있거나, 발송 서버가 해당 selector로 서명하지 않는 상황일 수 있습니다.", "오피셜메일 도메인 연결 화면에서 표시되는 DKIM 호스트와 TXT 값을 사용하세요. 다른 도메인에서 복사한 키, 과거에 재발급한 키, 값 일부가 잘린 키는 현재 발송 서명과 맞지 않을 수 있습니다.", ], steps: [ { title: "현재 DKIM selector 확인", body: "도메인 연결 화면의 호스트 이름을 확인합니다. 일반적으로 dkim._domainkey처럼 표시되지만 서비스별 selector는 다를 수 있습니다.", }, { title: "TXT 값 전체 등록", body: "v=DKIM1로 시작하는 공개키 값을 누락 없이 등록합니다. DNS 관리 화면의 표시상 줄바꿈과 실제 TXT 값 분할은 구분해서 확인합니다.", }, { title: "재발급했다면 이전 값 교체", body: "호환 모드 또는 재발급으로 키가 바뀌었다면 DNS의 기존 키를 새 값으로 바꾸고 전파가 끝난 뒤 다시 검증합니다.", }, ], }, { id: "diagnose", title: "반송 메일에서 원인을 읽는 방법", paragraphs: [ "반송 메일의 Authentication results 또는 Diagnostic-Code 부분을 보면 Gmail이 어떤 도메인과 IP를 검사했는지 확인할 수 있습니다. 예를 들어 SPF [내도메인.com] with ip: [서버 IP] = did not pass라고 나오면, 내도메인.com의 SPF에 그 서버가 허용되지 않았다는 의미입니다.", "DKIM = did not pass가 함께 보이면 DKIM 공개키 조회나 서명 검증이 실패한 것입니다. 문제를 해결한 뒤에는 동일한 수신자에게 다시 보내기 전에 오피셜메일의 도메인 연결 상태 확인을 실행하고, 새 메일로 재테스트하세요. 이미 큐에 들어간 메일은 이전 인증 상태로 발송됐을 수 있습니다.", "아래는 실제 반송 메일에서 개인정보와 IP를 제거한 형태입니다. 핵심은 수신자 주소가 아니라 Gmail이 검사한 발신 도메인과 서버 IP입니다.", "```text\n550-5.7.26 Your email has been blocked because the sender is unauthenticated.\nAuthentication results:\nDKIM = did not pass\nSPF [내도메인.com] with ip: [발송 서버 IP] = did not pass\n```", ], table: { headers: ["반송 문구", "우선 확인할 항목"], rows: [ ["SPF = did not pass", "루트 도메인의 SPF 정책, 중복 SPF, 발송 서버 포함 여부"], ["DKIM = did not pass", "DKIM 호스트, 최신 공개키, 키 재발급 여부"], ["SPF와 DKIM 모두 실패", "DNS 관리 위치, 도메인 오타, 이전 서비스 레코드 충돌"], ["인증은 통과했지만 스팸함", "메일 내용, 발송량, 수신자 반응, DMARC 정책"], ], }, }, { id: "verify", title: "DNS 수정 전후를 명령어와 메일 원문으로 검증하세요", paragraphs: [ "먼저 공개 DNS에서 레코드가 조회되는지 확인합니다. Windows PowerShell에서는 아래처럼 실행할 수 있습니다. DNS 응답이 맞더라도 실제 메일이 그 도메인으로 서명되지 않으면 DKIM은 실패할 수 있으므로 마지막에는 새 테스트 메일의 원문을 확인해야 합니다.", "```powershell\nResolve-DnsName 내도메인.com -Type TXT\nResolve-DnsName dkim._domainkey.내도메인.com -Type TXT\nResolve-DnsName 내도메인.com -Type MX\n```", "Gmail에서 새 테스트 메일을 연 뒤 **더보기 → 원본 보기**를 선택하고 SPF, DKIM, DMARC 결과를 확인합니다. 목표는 SPF와 DKIM을 모두 PASS로 만들고 From 주소 도메인이 인증 도메인과 정렬되도록 하는 것입니다.", ], table: { headers: ["검증 단계", "정상 판단 기준", "실패하면 볼 곳"], rows: [ ["공개 DNS", "SPF와 현재 DKIM 키가 조회됨", "네임서버, 호스트명, 저장 여부"], ["메일 원문 SPF", "PASS이며 발신 도메인과 일치", "발송 서버 포함 여부, 중복 SPF"], ["메일 원문 DKIM", "PASS이며 d= 도메인이 From과 정렬", "selector, 공개키, 발송 서명"], ["메일 원문 DMARC", "PASS", "SPF 또는 DKIM 정렬, DMARC 정책"], ], }, }, { id: "prevention", title: "수정 후 재발을 줄이는 운영 기준", paragraphs: [ "도메인 메일을 운영하면서 메일 서비스를 바꾸거나, 자동발송 도구를 추가하거나, DNS 담당자가 바뀌면 인증 레코드가 깨질 수 있습니다. 발송 도구를 추가할 때마다 SPF에 새 서버를 무작정 늘리기보다 실제로 도메인 이름으로 발송하는 서비스인지 먼저 확인하세요.", "Google은 모든 발신자에게 SPF 또는 DKIM 인증을 요구하고 두 인증을 모두 설정할 것을 권장합니다. 개인 Gmail 계정으로 하루 5,000통을 초과해 보내는 발신자는 SPF·DKIM·DMARC, 도메인 정렬, 원클릭 수신거부 등 추가 요구사항도 충족해야 합니다.", "대량 홍보 메일은 인증이 통과해도 수신자 반응과 발송 평판에 영향을 받습니다. 구매한 주소나 동의하지 않은 대상에게 보내지 말고, 요청한 사람에게 필요한 정보를 보내며 수신 거부 경로를 제공해야 합니다.", ], }, ], faqs: [ { question: "SPF를 mx1.officialsite.kr에 추가하면 되나요?", answer: "보통 SPF는 발신 주소의 도메인 루트에 설정합니다. 예를 들어 contact@내도메인.com으로 보냈다면 내도메인.com의 SPF 정책이 기준입니다. 실제 값은 오피셜메일 도메인 연결 화면에서 안내하는 값을 사용하세요.", }, { question: "DKIM을 설정하지 않아도 메일을 보낼 수 있나요?", answer: "일부 수신처에는 도착할 수 있지만, 업무용 도메인 메일은 DKIM을 함께 설정하는 편이 좋습니다. Gmail처럼 발신 인증을 엄격하게 확인하는 수신처에서 반송 또는 스팸 분류 위험을 줄이는 데 도움이 됩니다.", }, { question: "DNS를 수정했는데도 계속 반송됩니다.", answer: "DNS 전파 후 새 메일로 다시 테스트해야 합니다. 또한 실제 DNS를 관리하는 서비스가 어디인지, 이전 SPF·DKIM 레코드가 남아 있지 않은지, From 주소의 도메인이 설정한 도메인과 같은지 확인하세요.", }, ], }, { slug: "company-email-address-guide", category: "기업메일 시작", title: "회사 이메일 만들기: 대표 메일부터 도메인 연결까지", description: "회사 이메일 만들기를 처음 시작하는 사업자를 위해 대표 메일 주소 선택, 도메인 연결, MX·SPF·DKIM 설정과 운영 순서를 안내합니다.", summary: "회사 이메일 만들기에 필요한 대표 주소 선택, 도메인 연결, MX·SPF·DKIM 설정과 송수신 확인 순서를 정리했습니다.", intro: "사업자 등록을 마치고 홈페이지나 명함을 만들 때, 고객이 가장 먼저 확인하는 연락처 중 하나가 이메일 주소입니다. 개인 메일을 계속 써도 업무는 가능하지만, 견적·계약·제휴처럼 신뢰가 필요한 순간에는 회사 도메인 주소가 공식 창구 역할을 합니다. 처음에는 대표 메일 하나만 제대로 만드는 것으로 충분합니다.", heroImage: { alt: "하나의 회사 도메인에서 대표·고객지원·정산 메일함으로 확장되는 구성", src: "/blog/generated/company-email-address.webp", }, highlights: [ { title: "도메인", body: "회사 이름이 들어간 주소의 기반입니다." }, { title: "대표 주소", body: "고객이 기억할 공식 연락 창구입니다." }, { title: "발신 인증", body: "SPF와 DKIM으로 도메인 신뢰를 확인합니다." }, ], keywords: [ "회사 이메일 주소 만들기", "기업메일 만들기", "회사 메일 만들기", "업무용 이메일 만들기", "대표 메일 주소", ], publishedAt: "2026-07-22T09:00:00+09:00", updatedAt: "2026-07-24T09:00:00+09:00", relatedLink: { href: "/business-email", label: "기업메일 기능과 운영 방식 살펴보기" }, readingMinutes: 5, references: [ { href: "https://customer.gabia.com/faq/detail/227/2521", label: "가비아 DNS 레코드별 기능", note: "도메인 메일 연결에 필요한 MX와 TXT(SPF)의 역할을 확인했습니다.", }, { href: "https://support.google.com/mail/answer/81126?hl=ko", label: "Google 이메일 발신자 가이드라인", note: "회사 도메인 발신 인증에 필요한 기본 기준을 확인했습니다.", }, ], sections: [ { id: "address", title: "회사 이메일은 주소 구조부터 정합니다", paragraphs: [ "회사 이메일은 보통 이름 앞부분과 도메인으로 구성됩니다. contact@내도메인.com, hello@내도메인.com, support@내도메인.com처럼 고객이 용도를 바로 이해할 수 있는 주소가 좋습니다. 대표자가 직접 관리하는 계정은 admin@내도메인.com 또는 대표 이름 기반 주소로 두고, 외부 공개 주소와 분리해도 됩니다.", "처음부터 모든 역할별 주소를 만들 필요는 없습니다. 고객 문의가 많지 않은 초기에는 contact 또는 hello 하나로 시작하고, 고객지원·정산·채용처럼 업무량이 분명해질 때 별도 계정을 추가하는 편이 관리하기 쉽습니다.", ], bullets: [ "외부 공개용: contact, hello, support, sales", "관리용: admin, owner, 운영자 이름", "역할별 확장용: billing, careers, partnership", ], table: { headers: ["팀 상황", "먼저 만들 주소", "추가 시점"], rows: [ ["1인 사업자", "contact 또는 hello 1개", "문의 성격이 분리될 때"], ["고객 문의가 잦은 팀", "support + 관리자 계정", "담당자가 2명 이상일 때"], ["B2B 영업 중심 팀", "sales 또는 partnership", "영업 기록을 분리할 때"], ["정산 메일이 많은 팀", "billing + 관리자 계정", "증빙 담당자가 생길 때"], ], }, }, { id: "domain", title: "도메인이 있어야 회사 이름이 주소에 들어갑니다", paragraphs: [ "회사 이메일의 @ 뒤에는 회사가 소유한 도메인이 들어갑니다. 홈페이지가 내도메인.com이라면 contact@내도메인.com처럼 같은 도메인을 사용하면 고객이 주소를 기억하기 쉽고, 웹사이트와 메일의 공식성이 연결됩니다.", "아직 도메인이 없다면 회사명, 상표, 발음하기 쉬운 영문 이름을 기준으로 선택하세요. 이미 홈페이지를 운영하고 있다면 기존 도메인을 그대로 쓰는 것이 일반적입니다. www.내도메인.com은 홈페이지 접속용 이름이므로 메일 설정에는 내도메인.com을 사용합니다.", ], callout: { title: "도메인과 웹사이트 호스팅은 다릅니다", body: "홈페이지를 만드는 서비스와 메일을 운영하는 서비스는 달라도 됩니다. 필요한 것은 도메인의 DNS를 수정할 수 있는 권한입니다.", }, }, { id: "setup", title: "대표 메일 하나를 만드는 실제 순서", paragraphs: [ "오피셜메일은 대표 메일 1개를 무료로 시작할 수 있습니다. 가입 후 대표 메일 주소와 도메인을 등록하고, 도메인 연결 화면에 표시되는 DNS 값을 도메인 관리 서비스에 입력하면 됩니다.", ], steps: [ { title: "도메인과 대표 주소 결정", body: "내도메인.com과 contact@내도메인.com처럼 외부에 안내할 주소를 정합니다. 주소를 자주 바꾸면 명함, 홈페이지, 광고 문구도 함께 수정해야 합니다.", }, { title: "오피셜메일 가입 및 대표 계정 생성", body: "대표 계정으로 가입한 뒤 사용할 도메인을 입력합니다. 대표 계정은 팀 설정과 도메인 연결을 관리하는 기준 계정이 됩니다.", }, { title: "DNS 레코드 연결", body: "MX로 수신 경로를 설정하고, SPF와 DKIM으로 발신 인증을 설정합니다. 서비스 화면의 값과 도메인 DNS 값을 항목별로 대조합니다.", }, { title: "외부 수신·발신 테스트", body: "Gmail 또는 네이버 메일에서 대표 주소로 테스트하고, 대표 주소에서도 외부 주소로 메일을 보내 수신 여부와 스팸 분류를 확인합니다.", }, ], }, { id: "operation", title: "대표 메일부터 시작하면 좋은 이유", paragraphs: [ "초기 사업자는 모든 업무가 대표자에게 모이기 때문에 대표 메일 하나만 잘 운영해도 문의, 제휴, 계약 메일을 개인 계정과 분리할 수 있습니다. 주소가 회사 자산으로 남기 때문에 담당자가 바뀌어도 고객이 알고 있는 공식 연락처는 유지됩니다.", "팀이 커질 때만 멤버 계정을 추가하면 됩니다. 고객지원 담당자가 생기면 support, 영업 담당자가 생기면 sales처럼 역할에 맞춰 확장하고, 각 계정이 받은 메일과 보낸 메일을 분리해 인수인계 부담을 줄일 수 있습니다.", ], }, { id: "launch-checklist", title: "개통 완료를 판단하는 10분 점검표", paragraphs: [ "DNS 연결 화면의 완료 표시만 보고 개통을 끝내지 마세요. 외부 Gmail이나 네이버 메일을 이용해 수신과 발신을 각각 확인해야 합니다. DNS 변경 자체는 빠르게 끝나도 전 세계 반영에는 시간이 걸릴 수 있습니다.", ], steps: [ { title: "외부에서 회사 주소로 보내기", body: "수신함에 도착하는지, 보낸 사람과 제목이 정상적으로 표시되는지 확인합니다.", }, { title: "회사 주소에서 외부로 답장하기", body: "반송 여부와 스팸 분류를 확인하고 Gmail 원본 보기에서 SPF·DKIM 결과를 확인합니다.", }, { title: "공개 연락처 교체하기", body: "홈페이지, 견적서, 명함, SNS의 기존 개인 주소를 공식 주소로 바꿉니다.", }, { title: "관리 권한 분리하기", body: "외부에 공개할 주소와 도메인·결제를 관리할 대표 관리자 계정을 구분합니다.", }, ], callout: { title: "메일 주소 생성과 DNS 반영 시간은 다릅니다", body: "계정은 즉시 만들어져도 DNS 변경이 외부에 반영되기 전에는 수신·발신 검증이 끝나지 않을 수 있습니다. 기존 메일을 운영 중이라면 전환 시간을 따로 잡으세요.", }, }, ], faqs: [ { question: "대표 메일은 어떤 이름으로 만드는 것이 좋나요?", answer: "고객에게 공개할 대표 창구라면 contact, hello, support처럼 용도를 이해하기 쉬운 이름이 좋습니다. 관리 전용 계정은 admin처럼 분리해도 됩니다.", }, { question: "도메인이 없으면 회사 이메일을 만들 수 없나요?", answer: "회사 이름이 들어간 @도메인 주소를 만들려면 도메인이 필요합니다. 도메인을 구매한 뒤 DNS 연결을 하면 기업메일을 사용할 수 있습니다.", }, { question: "대표 메일만으로 시작해도 되나요?", answer: "네. 초기에는 대표 메일 하나로 시작하고, 실제 업무량과 담당자가 늘어날 때 멤버 계정이나 역할별 주소를 추가하는 방식이 효율적입니다.", }, ], }, { slug: "naver-works-domain-email-guide", category: "서비스 비교", title: "네이버웍스 대안 비교: 도메인 메일 선택 전 확인할 5가지", description: "네이버웍스와 독립 도메인 메일을 업무 범위, 인원별 비용, 저장 공간, 관리 기능, 이전 부담의 5가지 기준으로 비교합니다. 작은 팀이 선택 전에 확인할 항목을 안내합니다.", summary: "그룹웨어 전체가 필요한 팀과 기업메일부터 빠르게 시작하려는 팀의 선택 기준을 정리했습니다.", intro: "도메인 메일을 만들려고 검색하다 보면 네이버웍스 같은 그룹웨어와 독립 기업메일 서비스를 함께 비교하게 됩니다. 어느 쪽이 무조건 더 좋다고 말하기보다, 필요한 업무 범위와 팀 규모가 무엇인지 먼저 정하는 것이 맞습니다. 메일 외에 캘린더·드라이브·결재가 필요한지, 또는 공식 이메일만 빠르게 열어야 하는지를 기준으로 보면 선택이 쉬워집니다.", heroImage: { alt: "공식 도메인 메일과 그룹웨어 중 팀에 맞는 업무 도구를 선택하는 두 경로", src: "/blog/generated/domain-email-vs-groupware.webp", }, highlights: [ { title: "업무 범위", body: "메일만 필요한지 협업 도구까지 필요한지 구분합니다." }, { title: "팀 규모", body: "현재 인원과 6개월 뒤 확장 가능성을 함께 봅니다." }, { title: "전환 부담", body: "MX 변경과 기존 메일 보관 계획을 먼저 세웁니다." }, ], keywords: [ "네이버웍스 대신 기업메일", "네이버웍스 대체", "도메인 메일 비교", "소규모 기업메일", "무료 기업메일", ], publishedAt: "2026-07-22T09:00:00+09:00", updatedAt: "2026-07-24T09:00:00+09:00", relatedLink: { href: "/team-mailbox", label: "작은 팀을 위한 메일함 운영 방식 보기" }, readingMinutes: 6, references: [ { href: "https://naver.worksmobile.com/pricing/", label: "네이버웍스 공식 이용요금", note: "2026년 7월 24일 기준 Standard·Standard Plus 요금과 제공 용량을 확인했습니다.", }, { href: "https://naver.worksmobile.com/products/naver-works/mail/", label: "네이버웍스 메일 공식 기능 안내", note: "기업용 메일과 협업 기능 범위를 확인했습니다.", }, { href: "/team-mailbox", label: "오피셜메일 팀 메일함 안내", note: "오피셜메일의 팀 인원 과금과 제공 기능을 확인할 수 있습니다.", }, ], sections: [ { id: "five-decisions", title: "선택 전에 확인할 5가지 기준", paragraphs: [ "그룹웨어는 메일뿐 아니라 일정, 주소록, 파일, 결재 같은 협업 도구를 함께 운영하려는 조직에 적합합니다. 이미 여러 담당자가 있고 사내 업무를 한 제품 안에서 표준화해야 한다면 그룹웨어 도입을 검토할 이유가 충분합니다.", "반면 1인 사업자나 작은 팀은 먼저 고객에게 보여줄 공식 메일 주소와 수신·발신 흐름이 필요한 경우가 많습니다. 이때는 복잡한 조직 도구를 모두 도입하기보다 대표 메일 하나를 도메인에 연결하고, 필요한 때 팀 메일함과 자동화 기능을 더하는 방식이 부담이 적을 수 있습니다.", ], steps: [ { title: "메일 외 협업 기능이 필요한가", body: "메시지, 캘린더, 드라이브, 프로젝트를 한 제품에서 운영해야 하면 그룹웨어가 유리합니다. 이미 다른 협업 도구를 쓰고 있다면 메일만 분리하는 편이 단순할 수 있습니다.", }, { title: "현재 인원 기준 월 비용은 얼마인가", body: "대표자와 실제 사용할 구성원을 모두 포함해 계산합니다. 무료 체험이나 첫 계정만 보지 말고 6개월 뒤 예상 인원으로 비교하세요.", }, { title: "메일과 파일에 필요한 용량은 얼마인가", body: "대용량 첨부와 장기 보관이 많으면 1인당 메일·드라이브 용량이 중요합니다. 텍스트 중심 고객 메일이라면 실제 사용량부터 확인하세요.", }, { title: "관리·보안 기능의 범위는 어디까지인가", body: "감사 로그, 조직도, 기기 관리, 보존 정책이 필요한 조직과 대표자가 직접 계정을 관리하는 작은 팀은 필요한 수준이 다릅니다.", }, { title: "기존 메일을 옮기는 부담을 감당할 수 있는가", body: "MX 변경, 이전 메일 보관, 공유 주소, 자동 전달과 외부 서비스 로그인 주소까지 점검한 뒤 전환 일정을 정합니다.", }, ], }, { id: "selection", title: "2026년 7월 기준 비용과 제공 범위를 함께 비교하세요", paragraphs: [ "네이버웍스 공식 요금 페이지에서 메일 기능은 Standard 이상에 포함됩니다. 2026년 7월 24일 확인 기준 Standard는 월간 계약 1인당 월 8,500원, 연간 계약 1인당 월 7,000원이며 메일 100GB와 드라이브·프로젝트 기능을 제공합니다. 가격과 제공 범위는 바뀔 수 있으므로 도입 직전 공식 페이지에서 다시 확인하세요.", "오피셜메일은 대표 메일 1개를 무료로 시작할 수 있고, 성장 플랜은 대표자를 포함한 팀 인원 기준 1인당 월 3,900원(VAT 별도)입니다. 메일과 AI 요약·릴레이가 목적이라면 비교하기 쉽지만, 드라이브·프로젝트·조직 협업을 한 제품에 묶어야 한다면 가격만으로 판단하면 안 됩니다.", ], table: { headers: ["비교 항목", "네이버웍스 Standard", "오피셜메일"], rows: [ ["주요 목적", "메일 + 드라이브 + 프로젝트", "도메인 메일 + AI 요약·릴레이"], ["월간 계약 기준", "1인당 월 8,500원", "대표 메일 1개 무료, 성장 플랜 1인당 월 3,900원(VAT 별도)"], ["메일 용량", "공식 페이지 기준 100GB/인", "메일함별 제공 용량은 플랜 화면에서 확인"], ["어울리는 팀", "협업 도구를 한 제품에 묶으려는 조직", "메일부터 가볍게 정리하려는 작은 팀"], ], }, callout: { title: "기능이 적은 서비스가 항상 저렴한 선택은 아닙니다", body: "이미 별도 드라이브·메신저 비용을 내고 있다면 전체 도구 비용을 합산해야 합니다. 반대로 사용하지 않을 기능 때문에 모든 인원의 상위 플랜을 결제하는지도 확인하세요.", }, }, { id: "cost-and-operation", title: "상황별로 보면 선택이 더 단순해집니다", paragraphs: [ "초기 팀은 계정을 많이 만드는 것보다 고객 메일이 누구에게 들어오고, 누가 답하고, 기록이 어디에 남는지가 더 중요합니다. 대표 메일을 공식 창구로 두고 담당자가 생길 때 멤버 계정을 추가하면 조직 변화에 맞춰 운영할 수 있습니다.", ], table: { headers: ["현재 상황", "우선 검토할 방식", "이유"], rows: [ ["대표자 1명, 공식 문의 주소가 먼저 필요", "독립 도메인 메일", "대표 주소부터 작게 검증 가능"], ["이미 Slack·Drive 등 협업 도구를 사용", "독립 도메인 메일", "기존 도구와 역할 중복을 줄임"], ["고객지원·영업 계정만 추가할 예정", "팀 메일함 확장", "업무 역할별 기록 분리에 집중"], ["사내 일정·파일·프로젝트를 통합해야 함", "네이버웍스 같은 그룹웨어", "메일 외 조직 협업 범위가 큼"], ], }, }, { id: "migration", title: "기존 메일을 바꾸기 전 체크리스트", paragraphs: [ "사용 중인 메일 서비스가 있다면 MX를 변경하기 전에 수신 이력, 공유 주소, 자동 전달, 외부 서비스 로그인 주소를 점검하세요. MX가 바뀌면 새로 들어오는 메일의 수신 위치가 달라질 수 있습니다.", "전환 과정에서는 대표 주소 하나로 먼저 수신·발신을 검증하고, 문제 없을 때 나머지 주소를 옮기는 편이 안전합니다. 고객에게 공지해야 하는 주소 변경이 있다면 기존 주소의 자동응답 또는 전달 기간도 계획하세요.", ], bullets: [ "기존 대표 주소와 역할별 주소 목록", "자동 전달·자동응답·외부 로그인에 쓰인 주소", "이전 메일 보관 또는 백업 필요 여부", "MX 변경 후 테스트할 외부 수신 주소", ], }, ], faqs: [ { question: "오피셜메일은 네이버웍스의 모든 기능을 대체하나요?", answer: "목적이 다릅니다. 오피셜메일은 도메인 기반 업무 메일 운영, 팀 메일함, AI 요약 흐름에 초점을 둡니다. 결재·사내 캘린더·문서 협업 등 그룹웨어 전체 기능이 핵심이라면 별도 요구사항을 비교해야 합니다.", }, { question: "기존 네이버웍스 메일을 쓰면서 오피셜메일도 함께 사용할 수 있나요?", answer: "같은 도메인의 수신 MX는 운영 방식을 정해야 합니다. 기존 메일을 유지한 채 별도 도메인으로 시작하거나, 전환 계획을 세워 수신 경로를 바꾸는 방법을 검토하세요.", }, { question: "작은 팀이 가장 먼저 설정할 것은 무엇인가요?", answer: "고객에게 보여줄 대표 메일 주소 하나와 도메인 연결입니다. 수신·발신을 확인한 뒤 담당자가 생길 때 계정과 역할별 주소를 추가하는 순서가 단순합니다.", }, ], }, { slug: "online-store-business-email-trust", category: "쇼핑몰 운영", title: "쇼핑몰 사업자 이메일이 신뢰를 만드는 이유와 대표 주소 운영법", description: "온라인 스토어 사업자가 개인 이메일 대신 도메인 메일을 써야 하는 이유를 정리했습니다. 고객 문의, 입점, 제휴, 정산을 위한 대표 이메일 주소 구성과 운영 기준을 안내합니다.", summary: "쇼핑몰 고객 문의와 제휴·정산 메일을 공식 주소로 분리해 신뢰와 운영 기록을 함께 관리하는 방법입니다.", intro: "온라인 스토어는 주문 알림과 채팅 상담만으로 운영되는 것처럼 보이지만, 입점 제안·도매 문의·세금계산서·브랜드 협찬·고객 불만처럼 중요한 대화는 이메일로 남는 경우가 많습니다. 이때 개인 Gmail이나 포털 주소보다 쇼핑몰 도메인과 같은 공식 주소를 사용하면 고객과 거래처가 연락 창구를 쉽게 확인할 수 있습니다.", heroImage: { alt: "쇼핑몰의 고객 문의·제휴·정산 메일을 역할별로 분류하는 운영 흐름", src: "/blog/generated/online-store-business-email.webp", }, highlights: [ { title: "고객 문의", body: "support 또는 contact 주소로 한곳에 모읍니다." }, { title: "제휴·도매", body: "일반 문의와 분리해 담당자가 빠르게 확인합니다." }, { title: "정산·증빙", body: "개인 계정과 분리해 거래 기록을 남깁니다." }, ], keywords: [ "쇼핑몰 사업자 이메일", "온라인 스토어 기업메일", "쇼핑몰 도메인 메일", "사업자 이메일 신뢰도", "고객문의 메일 주소", ], publishedAt: "2026-07-22T09:00:00+09:00", updatedAt: "2026-07-24T09:00:00+09:00", relatedLink: { href: "/domain-email", label: "쇼핑몰 도메인으로 공식 메일 만드는 방법 보기" }, readingMinutes: 5, references: [ { href: "https://support.google.com/mail/answer/81126?hl=ko", label: "Google 이메일 발신자 가이드라인", note: "명확한 발신자 표시와 도메인 인증, 수신 동의 기반 발송 원칙을 확인했습니다.", }, { href: "/domain-email", label: "오피셜메일 도메인 메일 안내", note: "쇼핑몰 도메인으로 대표 메일을 연결하는 흐름을 확인할 수 있습니다.", }, ], sections: [ { id: "why-trust", title: "쇼핑몰 이메일은 고객이 확인하는 공식 연락처입니다", paragraphs: [ "고객은 주문 후 문제가 생기거나 제휴를 제안할 때 홈페이지 하단, 상세 페이지, 사업자 정보에 있는 연락처를 찾습니다. contact@내도메인.com처럼 쇼핑몰 이름이 들어간 주소는 고객이 어느 업체와 대화하고 있는지 바로 이해하게 합니다.", "개인 메일 주소가 항상 신뢰를 잃게 만드는 것은 아니지만, 사업자 정보·홈페이지 도메인·메일 주소가 서로 다른 경우 고객은 문의 채널이 공식인지 다시 확인하게 됩니다. 특히 고가 상품, B2B 납품, 입점·협찬 같은 거래에서는 주소의 일관성이 더 중요해집니다.", ], }, { id: "address-plan", title: "처음에는 두 개의 주소면 충분합니다", paragraphs: [ "작은 쇼핑몰이라면 외부 고객 문의를 받는 주소와 운영자가 관리하는 주소를 분리하는 것부터 시작하면 됩니다. 고객에게는 support 또는 contact를 안내하고, 대표자는 admin 또는 이름 기반 계정으로 도메인 연결과 중요한 설정을 관리합니다.", "주문량과 담당자가 늘어난 뒤에만 wholesale, partnership, billing 같은 역할별 주소를 추가하세요. 주소가 늘어나면 누가 확인하는지, 답장이 필요한 시간은 얼마인지, 담당자가 비었을 때 어떻게 넘길지까지 함께 정해야 합니다.", ], table: { headers: ["업무", "권장 주소 예시", "운영 기준"], rows: [ ["일반 고객 문의", "contact@내도메인.com", "홈페이지와 주문 안내에 동일하게 노출"], ["제휴·입점·도매", "partnership@내도메인.com", "대표자 또는 담당자에게 빠르게 전달"], ["정산·세금계산서", "billing@내도메인.com", "증빙 메일을 개인 계정과 분리"], ["관리자 설정", "admin@내도메인.com", "외부 공개 대신 관리 권한 전용으로 사용"], ], }, }, { id: "flow", title: "고객 문의가 누락되지 않는 메일 흐름 만들기", paragraphs: [ "대표 메일함 하나에 주문, 광고, 제휴, 정산 메일이 섞이면 중요한 문의를 놓치기 쉽습니다. 처음에는 폴더를 기준으로 정리하고, 팀원이 생기면 역할별 계정으로 분리하세요. 고객에게는 여러 주소를 무작정 노출하기보다 가장 빠르게 답할 수 있는 대표 주소를 먼저 안내하는 편이 좋습니다.", "긴 문의나 제휴 제안이 자주 들어온다면 AI 요약·릴레이를 활용할 수 있습니다. 핵심 요청과 확인할 사항을 보조 메일로 받아보고, 실제 답장은 원문과 첨부를 확인한 뒤 보내는 방식으로 운영하면 모바일에서도 판단이 빨라집니다.", "예를 들어 월요일 오전에 교환 요청, 세금계산서 문의, 입점 제안이 함께 도착했다면 대표 문의 주소에서 세 건을 모두 읽는 대신 문의 성격에 따라 담당 폴더 또는 계정으로 넘깁니다. 교환 요청은 주문번호 확인 후 고객지원 담당자가 답하고, 정산 메일은 증빙 전용 주소에 남기며, 입점 제안은 대표자가 원문과 첨부를 검토하는 방식입니다.", ], steps: [ { title: "대표 문의 주소를 한곳으로 통일", body: "홈페이지 푸터, 교환·환불 안내, 사업자 정보, SNS 프로필에 같은 주소를 사용합니다.", }, { title: "문의 성격별 폴더 만들기", body: "고객 문의, 제휴, 정산처럼 자주 구분하는 항목부터 폴더를 만듭니다.", }, { title: "답장 기준 정하기", body: "누가 확인하는지와 답장 목표 시간을 정해 두고, 담당자가 없는 시간의 처리 방법을 정리합니다.", }, ], table: { headers: ["수신 메일 예시", "첫 확인 항목", "담당·보관 기준"], rows: [ ["교환·환불 요청", "주문번호, 상품, 요청 기한", "고객지원 담당 + 주문 기록"], ["세금계산서 요청", "사업자 정보, 공급일, 금액", "정산 담당 + 증빙 폴더"], ["입점·도매 제안", "회사 정보, 조건, 첨부 파일", "대표 또는 영업 담당"], ["광고·협찬 제안", "발신자, 제안 범위, 비용", "제휴 폴더, 불필요하면 보관 종료"], ], }, }, { id: "launch", title: "도메인 메일을 시작한 뒤 바로 바꿔야 할 곳", paragraphs: [ "메일 주소를 만든 뒤에는 고객이 실제로 보는 접점부터 수정해야 합니다. 홈페이지 문의 페이지와 푸터, 스마트스토어 또는 쇼핑몰 사업자 정보, 주문·교환 안내, 인스타그램 프로필, 명함이나 패키지 안내문을 점검하세요.", "기존 개인 메일로 들어오던 문의가 있다면 바로 끊기보다 일정 기간 자동 전달이나 안내 문구를 운영하는 편이 좋습니다. 고객이 새 공식 주소를 인지할 수 있도록 기존 주소의 자동응답에 새 연락처를 남기는 방법도 활용할 수 있습니다.", ], bullets: [ "홈페이지 푸터와 문의 페이지", "쇼핑몰 고객센터·사업자 정보", "주문, 교환·환불, 배송 안내 문구", "SNS 프로필과 제휴 제안 안내", ], }, ], faqs: [ { question: "쇼핑몰은 고객센터 전화번호만 있으면 되지 않나요?", answer: "전화와 채팅은 즉시 응대에 좋지만, 제휴 제안, 증빙 요청, 교환·분쟁 기록처럼 내용을 남겨야 하는 업무에는 이메일이 필요합니다. 공식 도메인 주소를 함께 안내하면 고객이 연락 창구를 확인하기 쉽습니다.", }, { question: "고객 문의용 주소와 대표자 주소를 꼭 나눠야 하나요?", answer: "초기에는 한 주소로 시작할 수 있습니다. 다만 도메인 설정·결제·외부 공개 문의를 한 계정에 모두 두면 권한과 업무가 섞일 수 있어, 운영이 커지면 분리하는 편이 좋습니다.", }, { question: "쇼핑몰 도메인이 이미 있는데 바로 연결할 수 있나요?", answer: "네. 도메인의 DNS를 수정할 수 있다면 오피셜메일 도메인 연결 화면에서 안내하는 MX, SPF, DKIM 값을 등록해 대표 메일을 연결할 수 있습니다.", }, ], }, ]; export function getBlogPost(slug: string) { return blogPosts.find((post) => post.slug === slug) ?? null; } function richBlock(type: string, title: string, body = "", url = "") { return [ `:::official-block{type=${type};title=${encodeURIComponent(title)};url=${encodeURIComponent(url)}}`, body, ":::official-block-end", ].join("\n"); } function richTable(table: NonNullable, title: string) { const body = [table.headers, ...table.rows] .map((row) => row.join(" | ")) .join("\n"); const width = Number((100 / table.headers.length).toFixed(2)); const widths = table.headers.map((_, index) => index === table.headers.length - 1 ? Number((100 - width * (table.headers.length - 1)).toFixed(2)) : width, ); return richBlock("table", title, body, `column-widths:${widths.join(",")}`); } export function blogPostToMarkdown(post: BlogPost) { const highlights = post.highlights .map((highlight) => `**${highlight.title}** — ${highlight.body}`) .join("\n"); const lines = [ post.intro, "", `![${post.heroImage.alt}](${post.heroImage.src})`, "", richBlock("columns-3", "핵심 요약", highlights, "column-widths:33.33,33.33,33.34"), "", richBlock("toc", "목차"), "", ]; for (const section of post.sections) { lines.push(`## ${section.title}`, "", ...section.paragraphs, ""); if (section.steps?.length) { lines.push( richBlock( "database-list", `${section.title} 실행 순서`, section.steps .map((step, index) => `**${index + 1}. ${step.title}** — ${step.body}`) .join("\n"), ), "", ); } if (section.bullets?.length) { lines.push(...section.bullets.map((item) => `- ${item}`), ""); } if (section.table) { lines.push(richTable(section.table, `${section.title} 비교표`), ""); } if (section.callout) { lines.push( richBlock( "callout", "💡", `**${section.callout.title}** — ${section.callout.body}`, ), "", ); } } lines.push( "## 확인에 사용한 공식 자료", "", "서비스 화면과 정책은 바뀔 수 있으므로 아래 공식 문서를 기준으로 확인했습니다.", "", ...post.references.map((reference) => `- [${reference.label}](${reference.href}) — ${reference.note}`), "", ); lines.push("## 자주 묻는 질문", ""); for (const faq of post.faqs) { lines.push(richBlock("toggle", faq.question, faq.answer, "toggle-open:0"), ""); } lines.push( richBlock("page", post.relatedLink.label, "", post.relatedLink.href), ); return lines.join("\n").trim(); }