ZDNET을 따르세요: 우리를 구글에서 선호 소스로 추가하세요. 

ZDNET 주요 내용

• 도메인을 보호하고 이메일을 스팸에서 제외시키는 DNS 레코드가 세 가지 있습니다.
• 세 가지 모두를 실행하면 완전한 보호를 얻을 수 있습니다. 
• 또한 도메인이 해킹당하는 것을 방지합니다.

많은 업무 이메일을 보내고 계신데 계속 무응답을 받으신다면, 이메일이 누군가의 스팸 폴더로 갈 가능성이 매우 높습니다. 

이런 상황이 발생할 수 있는 몇 가지 이유는 항상 이메일의 내용과 관련이 있는 것은 아닙니다. 가장 흔한 경우는 도메인이 인증되지 않았기 때문입니다. 이는 수신 메일 서버가 메시지를 조용히 스팸 폴더에 넣는 데 필요한 모든 이유를 제공합니다. 

그리고:버너 이메일이 이메일함을 어떻게 보호하는지 - 설정하는 것은 간단하고 무료입니다

이런 걸 실수로 만나는 경우가 예상보다 훨씬 많았어요. 진정으로 좋은 이메일 콘텐츠를 가진 팀들도 포함이에요. 다행히 SPF, DKIM, DMARC라고 불리는 세 가지 DNS 레코드를 포함한 쉬운 해결책이 있어요. 이 세 가지가 함께 인터넷에 당신의 이메일이 정당하다는 것을 증명해요. 또한, 당신의 도메인이 사이버 범죄자들에 의해 해킹당하고 이메일에서 당신을 모방할 수 있도록 방지해요.

Gmail과 Yahoo는 2024년 2월부터 대량 발송자에 대해 이러한 인증 요구사항을 강제하기 시작했습니다. 이에 따라 Microsoft는 2025년 5월에 Outlook.com, Hotmail, 및 Live.com에 동일한 요구사항을 추가했습니다. 아직 설정하지 않았다면 이는 더 이상 선택 사항이 아닙니다.

SPF, DKIM, DMARC이 실제로 어떻게 작동하는지

세 가지 프로토콜은 이메일 인증에서 다른 약점을 다룹니다. SPF는 이메일을 발송하는 서버가 해당 작업을 수행할 권한이 있는지 확인합니다. DKIM은 발송 중인 메시지에 암호화 서명을 추가하여 전송 중에 변경되지 않았음을 확인합니다. 

DMARC는 두 가지를 연결하여 검사 중 하나가 실패할 때 수신 서버가 어떻게 행동해야 하는지를 알리는 정책을 게시하고 인증 보고서를 다시 본인에게 라우팅합니다.

당신은 정말 세 가지 모두가 필요합니다. SPF만으로는 수신자가 이메일을 받을 때 본인이 보는 "From" 주소를 가짜로 만드는 것을 막을 수 없습니다. DKIM만으로는 부정된 서버에서 보낸 이메일을 포착하지 못합니다. 세 가지를 모두 사용해야만 전달 가능성 문제와 도메인 가짜성에 대한 완전한 보호를 얻을 수 있습니다.

1. SPF: 당신을 대신하여 보내는 서버를 인증합니다.

SPF (발신 정책 프레임워크)는 도메인을 대신하여 이메일을 발송할 수 있는 모든 IP 주소와 메일 서버를 나열하는 DNS TXT 레코드입니다. 수신자의 메일 서버가 당신으로부터 보낸 것으로 주장하는 메시지를 받으면, 발신 서버의 IP 주소와 해당 레코드를 확인합니다. IP 주소가 목록에 없으면 메시지가 실패합니다.

또한: 제가 정리하기 좋은 이메일 껌은 이메일함의 혼란을 자동으로 정리하는 것입니다.

설치를 하는 것은 도메인 등록기(GoDaddy, Cloudflare, Namecheap 등)에 로그인하고 도메인 루트에 TXT 레코드를 추가하는 것을 의미합니다. 이 작동 방식은 다음과 같습니다: 

1. 먼저 이메일 서비스에서 SPF 값을 얻으세요. Google Workspace, Microsoft 365, 그리고 대부분의 플랫폼은 도메인 인증 페이지에서 복사하여 붙여넣을 정확한 레코드 값을 제공합니다. Google Workspace의 경우, 다음과 같습니다: v=spf1 include:_spf.google.com ~all. 

2. 여러 서비스를 통해 이메일을 보내면 동일한 레코드에 쌓아야 합니다. 예를 들어,   v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all. 

3. 도메인의 DNS 레코드를 관리하는 플랫폼에 로그인하세요. 이는 GoDaddy, Cloudflare, Namecheap, Route 53 등이 될 수 있습니다. DNS 페이지에서 새로운 TXT 레코드를 만들고, 호스트를 @ (루트 도메인)으로 설정한 다음, 이전 단계에서 복사한 SPF 값을 붙여넣으세요.

그것만으로도 쉽습니다! 도메인은 SPF TXT 레코드를 하나만 가질 수 있으며, 최대 10회까지 DNS 조회가 가능합니다. 첫 번째 레코드를 편집하는 대신 두 번째 SPF 레코드를 만드는 것은 두 레코드 모두를 손상시킬 것입니다. 따라서 인증된 발신자 목록을 간결하게 유지하십시오. 

2. DKIM: 모든 이메일에 위변조 불가능한 서명을 추가

DKIM (도메인키 인식 메일)은 공개키 암호화를 사용하여 발신 메시지에 서명합니다. 당신의 메일 서버는 보유한 개인키를 사용하여 서명을 첨부하고, 수신자는 당신이 DNS에 게시한 일치하는 공개키를 사용하여 확인할 수 있습니다. 만약 메일이 당신의 서버와 수신자의 이메일함 사이에서 어느 시점에든 변경되었다면, 그 서명 확인은 실패합니다.

또한: 이 간단한 이메일 속임수는 귀찮은 마케팅 스팸으로부터 나를 구해줍니다(그리고 이걸 하기는 무료입니다)

Google Workspace, Microsoft 365, 그리고 SendGrid와 같은 주요 이메일 플랫폼들은 당신을 위해 DKIM 키 쌍을 생성해 줄 것입니다. 당신의 일은 그들이 제공하는 공개 키를 복사하고, 당신의 도메인의 DNS 설정에 새로운 TXT 레코드로 붙여넣는 것입니다. 

정확한 설정 단계는 이메일 제공업체와 도메인 등록기관에 따라 다를 수 있지만, 여기서는 필요한 일반적인 개요를 제공합니다. 

1. Google Workspace, Microsoft 365, SendGrid, Mailchimp 등의 이메일 서비스 제공업체는 도메인 인증 설정 페이지로 이동하면 DKIM 레코드를 생성해 줄 것입니다. 예를 들어 Google Workspace를 사용하는 경우, 이는 앱 > Google Workspace > Google Admin Console에서 Gmail을 클릭하여 새로운 레코드를 생성하고 이 값들을 먼저 복사하세요. 

2. 그런 다음, 도메인 등록사의 DNS 설정 페이지로 이동하여 이전에 SPIF 설정할 때와 같이 새로운 TXT 레코드를 만드세요. 일부 제공자는 TXT 레코드 대신 CNAME 레코드로 이를 추가해야 할 수도 있으므로, 이메일 제공자의 문서를 참조하세요. 

3. 호스트 이름과 이메일 제공자로부터 받은 레코드 값을 새로운 DNS 레코드에 붙여넣으세요. 타이핑 오류가 없는지 확인하세요. 이는 도메인 보안에 영향을 줄 수 있습니다.

4. 이제 이메일 제공자의 인증 설정으로 돌아가세요. 이곳에서 도메인에 대한 DKIM 서명을 활성화합니다. Google Workspace에서는 관리 콘솔의 "이메일 인증" 페이지를 다시 방문하고 "인증 시작"을 클릭하여 이 작업을 수행합니다. DNS 레코드가 도메인 전체에 퍼지하는 데 시간이 걸리므로, 이 작업은 24-48시간 후에 수행해야 합니다. 

DKIM은 전달된 메시지에 특히 유용합니다. 전달은 IP 주소가 변경되어 SPF를 깨뜨리는 경우가 많지만, DKIM 서명은 일반적으로 무결성을 유지합니다. 이는 SPF만으로 실패했을 때도 전달된 이메일이 여전히 인증을 통과할 수 있다는 의미입니다. 

3. DMARC: 인증이 실패할 때 발생하는 규칙을 설정합니다

DMARC (도메인 기반 메시지 인증, 보고 및 준수)은 SPF와 DKIM을 강제적으로 적용하는 정책 계층입니다. 이 없으면 검수에 실패를 감지한 수신 서버는 다음에 어떻게 해야 할지에 대한 지시를 받지 못하며, 당신은 실패가 일어나는 이유를 알 수 없습니다. 이를 설정하고 작동하는 방법은 다음과 같습니다:

1. 먼저 DMARC 보고를 위한 전용 이메일 주소를 만듭니다. 예를 들어, reports@yourdomain.com과 같습니다. 

2. 대부분의 이메일 제공업체는 대시보드에 DMARC 생성기를 제공하지만, MXToolbox나 DMARCLY와 같은 제3자 서비스를 사용할 수도 있습니다. 

3. 새로운 TXT 레코드를 추가합니다. 호스트 이름은 _dmarc이어야 합니다. DMARC 생성기에서 직접 레코드 값을 붙여넣으세요. 

4. 2-4주 동안 별도의 이메일함에서 오류 보고서를 주의 깊게 살펴보세요. 이는 전달성을 향상시키기 위해 해결해야 할 이메일함의 문제를 드러낼 것입니다.

또한: 나는 NordVPN의 무료 사기 체크기를 실제 피싱 이메일로 테스트했는데, 이는 어떻게 처리되었는지 여기에 있습니다

다른 두 가지와 마찬가지로, DMARC은 이번에 추가된 TXT 레코드입니다. 간단한 시작 레코드는 이렇게 보입니다: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. p=none 설정은 수신 서버가 실패한 메시지에 대해 아무 작업도 하지 않지만, 지정한 주소로 집계 보고서를 보낼 것을 의미합니다. 그 보고서는 어떤 서비스가 대신 보내고 있는지와 인증을 통과하는지 여부를 보여줍니다.

몇 주간의 보고서를 검토하고 정당한 메일이 원활하게 통과하는 것을 확인한 후에 정책을 좁힐 수 있습니다. p=quarantine로 이동하여 실패한 메시지를 스팸으로 라우팅하고, 그 다음에는 p=reject로 전혀 차단하도록 설정합니다. 

보고서를 검토하기 전에 바로 p=reject로 이동하는 것은 제가 보는 가장 일반적인 구현 오류입니다, 그리고 그 결과로 당신 자신의 마케팅이나 거래 메일을 차단하게 됩니다.

왜 하나만 선택할 수 없나요

각 프로토콜은 다른 것들로 채워지는 공백이 있습니다. SPF는 발송 서버를 확인하지만 수신자가 실제로 보는 "From" 주소를 확인하지 않으므로, 공격자는 SPF를 통과하면서도 여전히 당신의 도메인을 가장할 수 있습니다. DKIM은 메시지 무결성을 확인하지만 서명 도메인이 보이는 발신자와 일치하는지 확인하지 않습니다. 

DMARC은 모든 요소 간의 정렬을 강제하고 정렬되지 않은 경우에 선택한 정책을 적용합니다.

결합된 납품 가능성 상승은 측정 가능합니다. Validity의 2025년 이메일 벤치마크 보고서에 따르면, 올바르게 인증된 도메인은 미인증 도메인보다 인박스 배치율이 대략 60% 포인트 높습니다. 차가운 외부 활동 캠페인이나 대량 뉴스레터를 운영하는 모든 사람에게 그 격차는 결과를 내는 캠페인과 완전히 사라지는 캠페인 사이의 차이입니다.

기록이 작동하는지 어떻게 확인하세요

DNS 변경 사항은 전 세계적으로 확산되기 위해 보통 15분에서 48시간까지 걸립니다. 그 기간이 지나면 무료 도구를 사용하여 모든 것이 올바르게 구성되었는지 즉시 확인할 수 있습니다. MX Toolbox은 SPF, DKIM, DMARC에 대한 별도의 검사기가 있습니다. 또한 check@dmarcly.com으로 테스트 이메일을 보내서 도메인에 대한 전체 인증 보고서를 받을 수 있습니다.

또한: 2026년 최고의 이메일 호스팅 서비스: 전문가가 테스트 및 리뷰했습니다

DMARC 집계 보고서가 가장 가치 있는 지속적인 신호입니다. DMARC 레코드를 게시한 후 하루 이틀 안에 지정한 주소로 보고서가 시작됩니다. 이는 도메인 하에 이메일을 보내는 모든 서버를 보여주며 각각이 인증을 통과했는지 여부를 나타냅니다. 정기적으로 읽는 것은 구성 오류를 조기에 포착하는 가장 좋은 방법이며, 이메일 전달성에 영향을 미치거나 피싱 캠페인에서 도메인을 악용하게 되기 전에 이를 방지할 수 있습니다.