SPF 및 DKIM을 통한 이메일 인증

SPF 및 DKIM을 통한 이메일 인증

다시 시작합니다! 약어 다시, 알아야 할 것, 또 괴상한 정보! 글쎄, 그들은 심각한 문제이며 이메일의 올바른 전달은 이러한 약어에 달려 있습니다. 우리는 개인적인 경험을 통해 이러한 두문자어가 생소하고 무섭게 들릴 수 있으며 전혀 흥미롭지 않게 보일 수 있음을 알고 있습니다. 또는 아마도 그것들이 당신에게 친숙하게 들릴지 모르지만 당신은 그것들이 실제로 무엇인지 확인할 만큼 충분히 신경을 쓰지 않았을 것입니다. 좀 해보자 비기술자를 위한 명확성.

어느 쪽이든, 이메일 전송을 더 잘 제어하려면 SPF 및 DKIM이 무엇인지, 메일 서버의 DNS 레코드에 설정하는 방법에 대해 조금 배울 시간입니다. 프로그래머뿐만 아니라 이해할 수 있는 간단한 단어로 설명하기 위해 최선을 다할 것입니다.

SPF란 무엇입니까? SPF는 어떻게 작동합니까?

간단히 말해서 SPF(Sender Policy Framework)는 악의적인 사용자가 사용자를 대신하여 이메일을 보내는 것을 방지하기 위해 구축된 보안 메커니즘입니다. 메커니즘에는 DNS 서버 간의 통신이 포함됩니다. 여기에서 모든 것이 무섭게 보이기 시작합니다! 그러나 당황하지 마십시오. 나는 그것을 가능한 한 간단하게 유지하려고 노력할 것입니다.

Bob에게 이메일을 보냈다고 가정해 보겠습니다. 그러나 Bob의 DNS 서버는 이메일이 실제로 귀하가 보낸 것인지 어떻게 알 수 있습니까? 문제는 그가 실제로 모른다는 것입니다. DNS 서버에 SPF를 설정하지 않은 경우. 음, DNS 서버가 무엇인지 설명해야 하지만 건너뛰겠습니다. 그렇지 않으면 저를 지옥으로 보내실 겁니다!

SPF는 도메인에서 이메일을 보내는 데 사용할 수 있는 IP 주소를 정의합니다. 따라서 서버 간에 가능한 두 가지 "대화"를 상상해 봅시다. 더 쉽게 하기 위해 당신의 이름이 Paul이라고 가정해 봅시다.

시나리오 1 – SPF를 설정하지 않았습니다.

마이크의 서버: 이봐, 밥의 서버. 마이크에게서 새 메시지가 왔습니다.
밥의 서버: 안녕 마이크의 서버. 당신의 SPF는 무엇입니까?
Mike's Server: 예, SPF에 대해… 난 하나도 없어. 저를 믿으세요. Mike가 보낸 것입니다.
Bob의 서버: SPF가 없으면 Mike가 보냈는지 확신할 수 없습니다. 귀하와 비교할 수 있도록 Mike의 허용된 IP를 알려주세요.
Mike의 서버: Mike의 IP 화이트리스트가 없습니다.
밥의 서버: 그럼 난 당신의 메시지를 원하지 않습니다. 배송이 거부되었습니다. 미안해 친구야...

시나리오 2 – SPF를 설정했습니다.

마이크의 서버: 이봐, 밥의 서버. 마이크에게서 새 메시지가 왔습니다.
밥의 서버: 안녕 마이크의 서버. 당신의 SPF는 무엇입니까?
마이크의 서버: 여기 내 SPF가 있습니다. Mike 자신이 자신을 대신하여 사용할 수 있다고 선언한 전체 IP 목록이 있습니다.
Bob의 서버: 좋아, 어디 보자... 그리고 당신이 내게 보낸 메시지는 IP 64.233.160.19에서 보낸 것입니다. 알겠습니다. 목록에 있습니다. 모든 것이 괜찮아 보입니다. 메시지를 주시면 Bob에게 보여드리겠습니다. 감사합니다!

이 지나친 단순화에 대해 모든 시스템 독자들에게 사과드립니다. 여러분이 떨고 있다는 것을 알고 있지만 저를 용서해 주시고 우리는 여러분의 기술적 지식이 부럽지만 비기술적인 청중과 이야기해야 하고 단순화해야 한다는 것을 명심하십시오.

어쨌든 이 두 가지 짧은 대화의 교훈은 SPF를 설정하는 것입니다. 그렇지 않으면 나쁜 사람처럼 보일 수 있으며 모든 이메일이 배달되지는 않습니다.

SPF에 어떤 애플리케이션을 포함해야 합니까?

일반적인 아이디어는 귀하를 대신하여 이메일을 보내는(그리고 귀하의 것이 아니라 SMTP를 사용하는) 모든 애플리케이션이 귀하의 SPF에 포함되도록 하는 것입니다. 예를 들어 Google Apps를 사용하여 도메인에서 이메일을 보내는 경우 Google을 SPF에 넣어야 합니다. 다음은 이를 수행하는 방법에 대한 Google의 지침입니다.

그러나 Google이 SPF에서 권한을 가진 유일한 애플리케이션이 아님을 확인하는 것이 중요합니다. 예를 들어 HelpScout을 사용하여 지원 이메일을 관리하고 MailChimp를 사용하여 뉴스레터를 보내는 경우 SPF에 두 가지를 모두 포함합니다.

내 SPF에 딱따구리도 포함해야 합니까?

아니요. 내가 말했듯이 귀하를 대신하여 이메일을 보내지만 자체 SMTP를 사용하는 앱을 SPF 레코드에 두는 것을 기억해야 합니다. Woodpecker는 자체 SMTP를 사용하여 이메일을 보내므로 대량 이메일 전송 앱이라기보다는 온라인 이메일 클라이언트에 가깝습니다.

즉, Woodpecker에서 보낸 이메일의 배달 가능성은 도메인의 평판에 따라 달라집니다. SPF 및 DKIM을 설정하면 도메인의 좋은 평판을 보호할 수 있으므로 이메일의 전달 가능성이 향상됩니다.

서버에서 단계별로 SPF 레코드를 설정하는 방법은 무엇입니까?

첫 번째 단계는 현재 SPF 레코드가 무엇인지 확인하는 것입니다. 다음과 같은 도구를 사용하여 이 작업을 수행할 수 있습니다.

도메인을 입력하면(예: 나는 woodpecker.co를 입력함) 도구가 일부 테스트를 실행하고 현재 SPF 또는 아직 설정되지 않았다는 알림을 표시합니다.

다음 단계는 무엇입니까?

도메인 호스트에 따라 단계가 달라집니다. 기본적으로 적절하게 구조화된 텍스트 줄을 콘솔의 올바른 위치에 붙여넣는 문제입니다. 예를 들어 Google Apps를 사용하여 도메인에서 모든 이메일을 보내는 경우 행은 다음과 같아야 합니다.

"v=spf1 포함:_spf.google.com ~모두"

레코드의 "v=spf1" 부분을 버전이라고 하고 그 뒤에 오는 부분을 메커니즘이라고 합니다.

이제 각 부분이 정확히 무엇을 의미하는지 봅시다.

  • v=spf1 이 요소는 레코드를 SPF로 식별합니다.
  • 포함:_spf.google.com 이 메커니즘에는 인증된 서버인 메일 서버가 포함됩니다.
  • ~v=spf1 이 요소는 이메일이 승인되지 않은 서버("include:" 메커니즘에 나열되지 않음)에서 수신된 경우 소프트 실패로 태그가 지정되어 통과할 수 있지만 스팸 또는 의심스러운 것으로 플래그가 지정될 수 있음을 나타냅니다.

그러나 이보다 더 많은 앱을 사용하는 경우(예: 뉴스레터를 보내는 것, 지원 메시지를 보내는 것 등)에는 다른 모든 앱을 포함해야 하므로 줄이 조금 더 길어집니다. 그것. 또는 Google Apps를 사용하지 않고 다른 호스트의 서버(예: GoDaddy)를 사용하는 경우 라인이 달라집니다.

가장 일반적인 도메인 호스트에 대해 SPF를 설정하는 방법은 다음과 같습니다.

DKIM이란?

DKIM(DomainKeys Identified Mail) 표준은 SPF와 동일한 이유로 만들어졌습니다. 악당이 사용자를 이메일 발신자로 사칭하는 것을 방지하기 위해서입니다. 수신자의 서버가 발신자가 본인인지 여부를 확인할 수 있도록 이메일에 추가로 서명하는 방법입니다.

DNS 서버에 DKIM을 설정하면 수신자에게 "예, 이 메시지를 보내는 사람은 바로 나입니다"라고 말하는 또 다른 방법을 추가하는 것입니다.

dkim 및 spf 설정 방법

전체 아이디어는 메시지 헤더에 있는 추가 서명의 암호화 및 암호 해독을 기반으로 합니다. 이를 가능하게 하려면 두 개의 키가 필요합니다.

  • 개인 키(귀하의 도메인에 고유하고 귀하만 사용할 수 있습니다. 이를 통해 메시지 헤더의 서명을 암호화할 수 있습니다).
  • 공개 키(DKIM 표준을 사용하여 DNS 레코드에 추가하여 수신자의 서버가 이를 검색하고 메시지 헤더에 숨겨진 서명을 해독할 수 있도록 함)

DKIM의 큰 그림을 보려면 Game of Thrones를 살펴보십시오. Ned Stark는 로버트 왕에게 메시지와 함께 까마귀를 보내고 있습니다. 누구나 종이 한 장을 가져다가 메시지를 쓰고 네드 스타크에게 서명할 수 있습니다. 그러나 메시지를 인증하는 방법이 있습니다. 바로 봉인입니다. 이제 모두가 Ned의 인장이 다이어 울프 (이것은 공개 키입니다). 하지만 Ned만이 원본 인장을 가지고 메시지에 넣을 수 있습니다.(이것이 개인 키입니다.) DKIM을 설정하는 것은 공개 키 정보를 서버 레코드에 넣는 것입니다. 올바른 위치에 넣어야 하는 txt 레코드일 뿐입니다.

이렇게 설정하면 누군가가 귀하로부터 이메일을 받을 때마다 수신자의 서버가 공개 키를 사용하여 숨겨진 서명을 해독하려고 시도합니다. 성공하면 메시지를 추가로 인증하고 결과적으로 모든 이메일의 권한을 높입니다.

서버에서 단계별로 DKIM 레코드를 설정하는 방법은 무엇입니까?

먼저 공개 키를 생성해야 합니다. 이렇게 하려면 이메일 제공업체의 관리 콘솔에 로그인해야 합니다. 다음 단계는 이메일 제공업체에 따라 다를 수 있습니다.

Google Apps를 사용하여 이메일을 보내는 경우 다음은 이스트 루치 오니 단계별로. Google Apps 사용자의 경우 DKIM 서명이 기본적으로 꺼져 있으므로 Google 관리 콘솔에서 수동으로 켜야 합니다.

공개 키가 있으면 생성된 txt 레코드를 가져와 DNS 레코드의 올바른 위치에 붙여넣습니다.

마지막으로 개인 키로 암호화된 서명으로 이메일 전송을 시작하려면 이메일 서명을 활성화해야 합니다. 방법은 다음과 같습니다., Google Apps를 사용하여 이메일을 보내는 경우

SPF 및 DKIM 설정 및 배달 가능성 향상

마케팅 또는 수신 또는 발신 판매를 위해 많은 이메일을 보내는 경우 도메인 평판이 중요하므로 이를 관리해야 합니다. 도메인이 블랙리스트에 오르고 이메일이 스팸으로 분류되는 것을 원하지 않습니다. DNS 서버에서 SPF 및 DKIM 레코드를 올바르게 설정하는 것은 도메인의 보안과 메시지의 높은 전달 가능성을 위해 필요한 단계입니다.

그것들을 설정하는 것이 복잡해 보일 수 있지만 의심할 여지 없이 그만한 가치가 있습니다. 내가 당신이라면 내 계정으로 이동하여 내 SPF 및 DKIM이 올바르게 설정되었는지 확인하거나 내 IT 직원에게 요청합니다. 그리고 대답이 "아니오"인 것으로 밝혀지면 그들에게 도와달라고 요청할 것입니다.