SPF(Sender Policy Framework)는 도메인 기반 메일 인증 기술로,

DNS에 발송 허용 서버를 명시하여 메일 위변조(Spoofing)를 방지하는 역할을 합니다.

SMTP 프로토콜의 구조적 한계(발신자 위조 가능)를 보완하기 위해 사용되며,

대부분의 메일 시스템(Gmail, Naver, Outlook 등)에서 기본적으로 검증됩니다.

2. 적용 목적

- 발신 도메인 위조 방지

- 스팸 메일 판정률 감소

- 메일 서버 신뢰도 향상

- 외부 SMTP 서비스와의 호환성 확보

3. DNS 설정 (보안 마스킹)

v=spf1 ip4:XXX.XXX.XXX.0/24 ip4:XXX.XXX.XXX.0/24 ip4:XXX.XXX.XXX.XXX ~all

4. SPF 레코드 구조 분석

SPF는 단일 TXT 레코드 내에서 아래와 같은 구조로 구성됩니다.

v=spf1 [mechanisms] [qualifier]

✔ 주요 구성 요소

구성설명

v=spf1SPF 버전 선언 (필수, 1회만 사용)

ip4IPv4 기반 발송 허용 서버

include외부 메일 서비스 허용

all기본 정책 (마지막 위치 필수)

5. 동작 원리 (메일 인증 흐름)

수신 서버는 SMTP 연결 시 발신 IP 확보

발신 도메인의 DNS TXT(SPF) 레코드 조회

SPF 정책에 따라 발신 IP 검증

결과 반환 (Pass / Fail / SoftFail / Neutral)

6. SPF 평가 결과 의미

결과의미

Pass허용된 서버

Fail (-all)명시적 거부

SoftFail (~all)비권장 (수신측 판단)

Neutral (?all)정책 없음

7. 설정 시 핵심 규칙 (중요)

★ 단일 레코드 원칙

SPF TXT 레코드는 반드시 1개만 존재해야 함

복수 존재 시 → PermError

all 메커니즘 위치

all은 반드시 마지막에 위치

이후 선언은 무시됨

☞ 잘못된 예

v=spf1 ip4:1.1.1.1 -all ip4:2.2.2.2

☞ 중복 선언 금지

❌ 잘못된 예

v=spf1 ... v=spf1 ...

공백 구분 필수

각 메커니즘은 공백으로 분리

8. 운영 전략 (실무 관점)

● 초기 운영 단계

~all

신규 환경에서 안전하게 적용

오탐 방지

● 안정화 이후

-all

허용된 서버 외 발송 완전 차단

보안 강화

9. 검증 방법

☞ DNS 조회

dig TXT example.com

☞ SPF 검사 도구

MXToolbox

Google Admin Toolbox

KISA DNS Checker

11. 확장 구성 (권장)

SPF 단독으로는 완전한 인증 체계가 아니므로

다음과 함께 구성하는 것을 권장한다.

☞ DKIM (서명 기반 인증)

메일 위변조 방지

공개키 기반 검증

☞ DMARC (정책 통합)

SPF + DKIM 결과 기반 정책 적용

보고서 수신 가능

12. 보안 및 운영 고려사항

내부 SMTP 릴레이 서버 포함 여부 확인

클라우드 메일 서비스(include) 추가 여부 검토

NAT 환경에서 실제 발신 IP 확인 필요

DNS 전파 시간 고려 (TTL)

MariaDB는 관계형 데이터 베이스입니다 관계형 데이터베이스 하면은 MySQL이 떠오르실텐데요

MariaDB는 오픈소스 MySQL의 코드를 기반으로 관계형 데이터 베이스 입니다

처음 MySQL 은 무료 오픈소스였습니다 그런데 MySQL은 오라클로 넘어간 후에 유료가 되고 이러한 문제를 해결하기 위해 MySQL AB 출신 개발자들이 다로 나와 만든것이 MariaDB입니다

MySQL과 기능적으로 거의 동일하며, 성능은 더 뛰어나며, 초기 버전은 MariaDB 5.5 버전이고 MySQL 5.5 버전과 거의 모든 기능이 호환이되고 MySQL 5.6 버전부터는 MariaDB 10.0 버전으로 보시면 됩니다

추이는 MySQL에서 MariaDB로 대체해가며 점유율 점차적으로 상승하고 있으며, MySQL에서 MariaDB로 넘어간 업체들도 많아지고 있습니다.

성능부분에서는 MySQL 보다 훨씬 뛰어나다는 이야기가 많습니다

URL : https://downloads.mariadb.org/mariadb/ 

error_page 지시어 뒤에 상태코드와 URL을 지정하여 접속한 사용자에게 리다이렉트를 할수 있습니다

클라이언트 에러 페이지

403: 권한 없음 → /data/www/errors/403.html

404: 페이지 없음 → /data/www/errors/404.html

서버 에러 페이지

500: Internal Server Error

502: Bad Gateway

503: Service Unavailable

504: Gateway Timeout

→ 모두 /data/www/errors/50x.html 로 안내

internal; 옵션

직접 http://example.com/50x.html 이런 식으로 접근은 못하게 막고, nginx가 내부에서만 호출할 수 있도록 제한

-h: 사람이 읽기 쉬운 단위(KB, MB, GB 등)로 표시

--max-depth=1: 현재 디렉토리 기준 바로 아래(1단계 깊이)의 디렉토리 용량만 출력

[원본파일] : 연결할 실제 파일이나 디렉토리

[심볼릭 링크 파일] : 새로 만들 심볼릭 링크의 이

링크 파일은 보동 ->(화살표)로 표시됩니다.

* 심볼릭 링크 자체의 권한은 의미 없음

* 파일에 실제 접근할 대는 원파일의 권한만 따름

grep ^- : 맨 앞에 -로 시작하는 줄(즉, 파일)만 찾기

wc -l 그줄의 개수를 세기

-type l 옵션은 심볼릭 링크 타입만 찾는다는 의미 입니다.

현재 디렉토리에서 찾으려면 find . -type l 로 찾으면 됩니다.

server_names_hash_bucket_size: 버킷의 크기입니다. 이름이 길 경우 이 값이 작으면 제대로 버킷을 구성할 수 없습니다.

긴 서브도메인 또는 와일드카드 사용 시 이 경고가 자주 발생합니다.

단순히 server_names_hash_bucket_size만 수정하면 무시될 수 있으니 두 항목 모두 조정하는 게 안전합니다.

Ubuntu 20.04에서는 패키지 관리자를 통해 libjemalloc-dev를 쉽게 설치할 수 있습니다. 이 패키지는 jemalloc 라이브러리와 개발 헤더 파일을 포함하고 있습니다.

2. MariaDB에 jemalloc 적용하기

mysqld_safe 에서 jemalloc 라이브러리를 추가하면 적용할 수 있습니다

3. MariaDB에 재시작

mysqld_safe 파일을 수정하거나 컴파일이 완료되면, MariaDB를 재시작하여 변경 사항을 적용합니다.

4. MariaDB에 jemalloc 적용 확인하기

MariaDB가 jemalloc을 제대로 사용하고 있는지 확인하려면, lsof 명령어를 사용하여 jemalloc 라이브러리가 MariaDB 프로세스에 로드되었는지 확인할 수 있습니다.

2. -type f: 파일 타입이 일반 파일인 경우만 검색합니다.

3. -exec sh -c '...' \;: 각 파일에 대해 쉘 명령어를 실행합니다.

4. file --mime {}: 파일의 MIME 타입을 확인합니다.

5. grep -q "text/xml; charset=unknown-8bit": MIME 타입이 text/xml; charset=unknown-8bit인지 확인합니다.

6. mv {} /path/to/destination_directory/: MIME 타입이 일치하는 파일을 목적 디렉토리로 이동합니다.

HTTP 요청을 HTTPS로 리다이렉트하는 설정입니다. 이는 보안 연결을 강제하기 위해 흔히 사용됩니다.

2 특정 URL 리다이렉트

특정 도메인으로 모든 트래픽을 리다이렉트하는 설정입니다. 예를 들어, test1.com을 test2.com으로 리다이렉트합니다.

3. 특정 URL 리다이렉트

특정 URL을 다른 URL로 리다이렉트하는 설정입니다. 예를 들어, /page를 /new-page로 리다이렉트합니다.