기술 중심 비즈니스에서는 SPF의 개념을 배우고 구현하는 것이 중요합니다. 피싱, 스팸의 잠재적 위험으로부터 기업을 보호할 수 있기 때문입니다, BEC 공격등으로부터 보호할 수 있습니다. SPF 또는 발신자 정책 프레임워크는 SPF 레코드를 사용하여 작동합니다.

이 블로그에서는 기술 프로토콜을 사용한 이메일 인증의 개념을 이해하는 데 필요한 SPF 구문 표, SPF 메커니즘, SPF 한정자 및 SPF 수정자에 대해 폭넓게 설명합니다.

주요 내용

기술 중심 비즈니스가 피싱 및 이메일 스푸핑으로부터 보호하려면 SPF를 이해하는 것이 필수적입니다.
SPF 레코드는 도메인을 대신하여 이메일을 보낼 수 있는 권한이 있는 IP 주소를 지정하는 중요한 DNS 항목입니다.
이메일 공격에서 도메인의 무단 사용을 방어하려면 SPF 레코드를 생성하고 정기적으로 확인하는 것이 중요합니다.
SPF 메커니즘, 한정자 및 수정자는 수신 서버가 SPF 레코드를 해석하는 방법을 결정하는 핵심 구성 요소입니다.
최적의 이메일 보안과 전달성을 보장하려면 올바른 형식의 단일 SPF 레코드를 유지해야 합니다.

벤기너를 위한 SPF 구문

SPF 레코드는 공식 도메인 네임을 사용하여 이메일을 보낼 수 있는 모든 IP 주소의 목록이 포함된 DNS 레코드입니다. 목록에 없는 서버가 해당 도메인을 사용하여 이메일을 보내면 승인되지 않은 것으로 처리됩니다. 따라서 수신자의 메일함에서 해당 항목이 거부됩니다. 이렇게 하면 해커가 시작한 악의적인 활동에 회사 이름이 연루되지 않도록 보호할 수 있습니다.

기업은 SPF 기록을 생성하고 SPF 레코드 확인 을 생성하고 확인하여 자체 도메인 이름을 사용하여 시도되는 피싱 공격을 방지해야 합니다. 이상 2억 5,500만 건 이상의 피싱 공격 가 2022년 상반기에만 2억 5,500만 건 이상 기록되었습니다! SPF를 구현하고 SPF 구문에 대해 배우는 것이 얼마나 중요해졌는지 상상해 보세요.

SPF 레코드에는 수신자의 서버가 도메인에서 수신한 이메일을 확인하고 유효성을 검사하도록 지시하는 지침이 있습니다. 또한 인증에 실패한 이메일에 대해 수행해야 할 작업도 알려줍니다. 특정 구성 요소는 모든 지침을 나타냅니다.

SPF 레코드 예제를 사용하여 각 요소를 분석해 보겠습니다.. SPF 구문은 다음과 같습니다.

v=spf1 ip4:123.1.5.0 ip4:100.5.2.1 include:exampledomain.com ~all

각 요소의 기능은 다음과 같습니다:

v=spf1은 수신 서버에 SPF 레코드에 대해 지정합니다. 모든 SPF 레코드는 이와 같이 시작해야 합니다.
이 SPF 구문의 다음 섹션에서는 도메인을 사용하여 이메일을 보낼 수 있는 IP 주소를 알려줍니다. 위의 예에서는 ip4:123.1.5.0 및 ip4:100.5.2.1이 있습니다.
위의 예에서 'include:exampledomain.com' 섹션은 해당 도메인을 사용하여 이메일을 보낼 수 있는 제3자를 지정합니다. '포함' 태그는 포함된 도메인(exampledomain.com)의 SPF 레코드에서 권한이 있는 IP 주소를 확인할 수신자 서버를 나타냅니다. SPF 레코드 내에 여러 도메인을 추가할 수 있지만 유효한 도메인이어야 합니다.
-all 요소는 수신 서버가 SPF 레코드에 지정된 목록에 없는 도메인이나 IP 주소에서 이메일을 보낼 경우 해당 이메일을 SPF 통과하지 않음으로 표시하도록 지시합니다.

PowerDMARC로 구문을 간소화하세요!

15일 평가판 시작 데모 예약하기

고급 SPF 구문

SPF 구문 테이블은 단일 텍스트 문자열이 포함된 DNS TXT 레코드를 사용하여 정의됩니다. 항상 사용되는 SPF 버전을 지정하는 'v=' 요소로 시작하며, 현재 버전은 하나뿐입니다.

모든 SPF 레코드에는 공식 도메인을 사용하여 메시지를 공유할 수 있는 호스트에 대한 규칙으로 작동하는 특정 조건이 등록되어 있으며 몇 가지 추가 정보를 표시할 수도 있습니다.

고급 SPF 구문에서 에서는 의 세 가지 구성 요소인 SPF 메커니즘, SPF 한정자, SPF 수식어를 분석합니다.

SPF 메커니즘

ALL: 항상 일치하며 SPF 레코드 끝에 추가되는 마지막 메커니즘입니다. 일치하지 않는 IP에 대해서는 '-all'과 같은 기본 결과를 표시합니다.
A: AAAA 또는 레코드 가 있는 도메인 이름을 일치하는 것으로 나타냅니다. 이 DNS SPF 레코드 구문이 지정되지 않은 경우 현재 도메인이 사용됩니다.
ip4: 발신자가 SPF 레코드에서 지정된 ipv4 주소 범위에 연결되어 있으면 일치합니다. 범위의 길이를 지정하는 접두사와 함께 추가합니다. 접두사가 없는 경우 /32가 사용됩니다.
ip6: 발신자가 지정된 ipv6 주소 범위에 속하면 일치합니다. ip4 지시어와 범위 길이를 나타내는 접두사가 추가됩니다. 접두사가 없는 경우 /128이 사용됩니다.
MX: 지정한 MX 레코드에 포함된 것과 동일한 IP 주소를 가진 발신자를 허용합니다. MX 레코드 는 메시지를 수락할 각 서버의 IP 주소와 우선순위 값으로 구성됩니다.
PTR: IP 주소를 하위 도메인 또는 도메인으로 확인할 수 있도록 권한이 있는 도메인을 지정합니다. 정확히 일치하는 모든 도메인 또는 하위 도메인에 대해 정방향 조회를 수행하여 IP 주소를 가져옵니다.

이 메커니즘은 여러 번 조회해야 하므로 시간이 많이 걸리고 신뢰할 수 없는 것으로 간주됩니다. 이 메커니즘은 RFC 7208 가이드라인.

존재: 입력한 도메인에 대해 DNS A 레코드 검색을 수행합니다. 실제 조회 결과와 관계없이 유효한 A 레코드가 발견되면 일치하는 것으로 간주합니다.
포함: 도메인을 명시하여 타사 이메일 발신자에게 권한을 부여합니다. 발신자의 IP 주소가 나열된 도메인의 SPF 레코드에 제공된 IP 주소 또는 도메인과 일치하는 경우에만 발신자에게 권한이 부여됩니다.

SPF 예선

메커니즘에 예시 조건이 없는데도 일치하는 항목이 있으면 SPF 인증이 통과됩니다. 8가지 메커니즘은 각각 아래에 언급된 네 가지 한정자 중 하나와 결합됩니다.

예선	결과	수신 서버에서 수행한 작업
+	패스	이메일이 SPF 인증을 성공적으로 통과하여 서버에서 이메일을 주고받을 수 있습니다. 이메일이 정품으로 표시됩니다. 이 조치는 한정자가 없는 경우 적용되는 기본 조치입니다.
-	실패	보내는 서버가 목록에 속하지 않아 이메일 인증에 실패합니다. 수신자의 사서함에서 메일이 거부될 수 있습니다.
~	SoftFail	수신자의 받은 편지함에서는 메시지를 수락하지만 의심스러운 메시지로 표시되어 스팸 폴더로 이동합니다.
?	중립	이메일 메시지가 인증을 통과하지 못하거나 실패합니다. 수행된 작업이 지정되지 않았으며 수신자가 이메일을 수락합니다.

SPF 수정자

SPD 수정자는 SPF 구문의 작업 매개변수를 결정하는 역할을 합니다. 여기에는 '=' 기호로 구분된 이름 또는 값 쌍이 포함되며, 규칙에 대한 추가 세부 사항과 예외가 있는 경우 이를 공유합니다.

수정자는 SPF 레코드의 마지막 섹션에만 한 번만 표시됩니다. 식별되지 않은 모든 수정자는 프로세스에서 무시됩니다. '리디렉션' 수정자는 인증을 위해 다른 SPF 레코드를 리디렉션하는 데 사용됩니다. 둘 이상의 도메인에 동일한 SPF 레코드 콘텐츠를 사용하려는 경우에 사용됩니다.

'포함' 메커니즘은 회원님을 대신하여 또는 회원님의 비즈니스 이름을 사용하여 이메일을 보낼 수 있도록 허용된 타사 도메인에 사용됩니다. 'exp' 수정자는 메커니즘이 일치할 때 수신 서버가 실패 SPF 한정자를 반환한 이유를 지정합니다.

SPF 기록 가이드라인

SPF 구문 표를 사용하여 SPF 레코드를 만들 때 다음 사항에 유의하세요.

하나의 도메인에 대해 여러 SPF 레코드를 정렬할 수 없습니다.
SPF 레코드에는 대문자가 없어야 하며, 그렇지 않으면 오류가 표시됩니다.
255자를 넘지 않아야 합니다. 이 숫자를 초과하는 문자열은 인증에 실패합니다.
동일한 도메인으로 확인되는 SPF 메커니즘이 있는 경우 삭제합니다.
사용하지 않는 ip4 및 ip6 SPF 메커니즘을 삭제합니다. 또한 주소 범위를 병합할 수 있는지 확인하세요.
SPF 정보를 저장할 하위 도메인을 만들 수 있습니다. 이 작업은 '_spf.domain.com'을 사용하여 수행할 수 있습니다. 하나의 SPF 레코드에 추가할 IP 주소가 여러 개 있는 대형 IT 기업에는 이 방법을 권장합니다.