
최근 스팸 메일은 점점 더 정교해지고 수법도 다양해지면서, 일반적인 필터링만으로는 완벽하게 차단하기 어려워졌습니다. 이러한 환경에서 메일의 신뢰성을 높이기 위해서는 DNS에 PTR, SPF, DKIM, DMARC와 같은 인증 기술을 적용하여 도메인의 무결성을 강화하는 것이 중요합니다. 이렇게 다양한 메일 보안 기술을 적용하더라도 100% 차단은 어렵지만, 메일 서버와 도메인에 네임서버(DNS)와 같은 인증 설정을 적용해 두면 수신자 입장에서의 신뢰도와 메일 발송(전달) 성공률을 높일 수 있습니다.
이게 깊게 들어가면 조금 어려울 수 있는데, 도메인 인증 기술은 메일을 주고받는 양쪽 모두에 적용되며, 수신자 입장과 발신자 입장에서 다르게 작동합니다. 이 개념을 이해하면 메일이 왜 스팸 처리되는지, 어떻게 인증 정책을 구성해야 하는지를 명확히 알 수 있습니다.
iRedMail 공식 문서 DNS 관련 참고 : https://docs.iredmail.org/setup.dns.html
| 구분 | 수신자 입장 (내가 메일을 받는 쪽) | 발신자 입장 (내가 메일을 보내는 쪽) |
| 목적 | 들어오는 메일의 진위 여부 판단 | 나가는 메일이 신뢰받게 보이도록 구성 |
| 체크하는 항목 | 발신자의 SPF/DKIM/PTR/DMARC를 검사 | 내 도메인의 SPF/DKIM/DMARC를 설정 |
| 예시 | Gmail에서 들어온 메일이 SPF fail이면 스팸 또는 차단 처리 |
Gmail 수신자가 내가 보낸 메일을 SPF Fail로 판단 가능 |
◈ STEP① SPF 정책 적용
ⓐ 수신(Received) 적용(X)
※ iRedMail 오픈소스 메일 서버에서는 자체 Postfix 확장 모듈인 iRedAPD를 사용하므로, 기본적으로 수신 메일에 대한 SPF 검사 정책은 적용되어 있지 않습니다. 관련 내용은 이전에 작성한 포스팅인 메일서버등록제(SPF:Sender Policy Framework)를 참고해 주세요. SPF 검사 기능을 직접 적용하면, 수신 시 발신자의 SPF 레코드를 확인하고 통과될 경우 메일 헤더에 해당 결과를 표시할 수 있게 됩니다. (캡처 참고)

ⓑ 발송(Sender) 적용
※ 메일 발송 시 실제 발송 주체는 메일 서버가 아닌 DNS의 TXT(SPF) 레코드에 의해 검증되므로, DNS 관리 페이지에서 반드시 SPF 값을 등록해야 합니다. 혼동하기 쉬운 부분으로 SPF값은 일종의 메일 인증 기술 이름으로 실제 등록은 TXT레코드에 등록을 합니다. SPF 등록 관련 추가 정보(리턴 메일 포함)


※ 만약, SPF값이 제대로 등록되어 있지 않을 경우 리턴 메시지를 받거나(높은 확률로), 수신되어도 경고 메시지 발생


◈ STEP② DKIM 정책 적용(Amavisd-new)
ⓐ 수신(Received) 적용
※ 이전 포스팅에서는 OpenDKIM을 이용해 적용했었으나 iRedMail에서는 Amavisd-new 오픈 소스를 통해 컨트롤(MTA)하게 됩니다. 자동 구성에서 이미 활성화가 되어 있으므로 설정 체크만 하시면 됩니다.
[root@localhost]# vi /etc/amavisd/amavisd.conf (설정 파일)
# Enable DKIM verification globally. (DKIM 검증 활성화)
$enable_dkim_verification = 1; (1=활성화, 0=비활성화)

$do_syslog = 1; (시스템 로그에 저장 : /var/log/maillog 기록)
$log_level = 2; (로그 레벨, 기본 0 → 2 (최대 5) 변경, DKIM 로그 확인)

[root@localhost]# systemctl reload amavisd (로그 설정만 변경으로 재로드)
[root@localhost]# tail -f /var/log/maillog (실시간 로그 확인)
◇ 추가 내용
※ log_level을 높이면 로그를 보다 자세히 확인할 수 있지만, 정보량이 지나치게 많아 오히려 분석이 어려울 수 있습니다. 평소에는 가장 낮은 로그 레벨로 유지하고, 문제가 발생했을 때만 조정하는 것이 좋습니다. 참고로, 메일 헤더에도 주요 정보가 포함되어 있어 해당 정보를 확인하는 것이 더 효율적일 수 있습니다.
※ 만약 통과하지 못하면 dkim=fail (verification failed) 메시지를 확인할 수 있으며, SpamAssassin과 연동되어 있어 실패에 대한 스팸 점수가 올라가게 됩니다.


ⓑ 발송(Sender) 적용
※ DKIM 생성 관련 내용은 iRedMail 공식 홈페이지 확인(링크)
※ iRedMail 자동 설치 시, 동일하게 도메인에 맞게 개인 키/공개 키 자동으로 생성됩니다.
[root@localhost]# vi /etc/amavisd/amavisd.conf (동일 설정 파일, 위치 설정 캡처 참고)

[root@localhost]# vi /root/iRedMail-1.7.4/iRedMail.tips (설치 정보 파일이 남아있다면)
[root@localhost]# amavisd showkeys (없다면, 공개 키 확인하는 명령어)


◇ DNS 등록(DKIM)
※ 이 값은 DNS 관리 페이지에서 TXT 레코드로 등록해야 합니다.
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | dkim._domainkey | "v=DKIM1; p=공개키값" | 3600(기본값) |
해당 값을 복사하여 그대로 붙여 넣기 하면 되지만, 한 줄로 입력할 경우 문자열이 너무 길어 DNS 관리 사이트의 입력 제한(보통 250자 이하)에 걸려 등록되지 않을 수 있습니다. 이럴 경우 큰 따옴표「" "」로 구분하여 여러 줄로 나누는 multi-line(멀티라인) 형식으로 등록해야 합니다. (보통 최대 500자 이내, 단 관리 사이트마다 다를 수 있음)


※ DKIM 등록 DNS 질의 테스트
Windows CMD(명령 프롬프트)나 Linux(리눅스) 계열에서 동일한 nslookup 명령어를 이용하여 확인합니다. Windows 명령 프롬프트에서 좀 더 깔끔하게 보입니다.
# nslookup -type=txt dkim._domainkey.mydomainhost.com (TXT DKIM 조회)
[root@localhost]# amavisd testkeys (amavis 명령어 인증 확인)
TESTING#1 mydomainhost.com: dkim._domainkey.mydomainhost.com => pass (정상)
※ fail이 나온다면 설정 값 또는 DNS 재 검토


※ 공백이 있어 제대로 처리가 안 되는 것처럼 보일 수 있지만, 검증 사이트를 통해 좀 더 정확하게 확인할 수 있습니다.
MXtoolbox 공식 사이트 : https://mxtoolbox.com/SuperTool.aspx#

◇ 발송 테스트(G메일 수신)


◇ 추가 내용
G메일의 수신 원본 헤더에서 Authentication-Results(인증 결과) 항목을 확인하면, SPF뿐만 아니라 DKIM도 PASS로 표시된 것을 볼 수 있습니다. 이는 메일 서버에서 서명한 DKIM 키와 DNS에 등록된 공개 키가 정상적으로 일치했다는 뜻입니다. 만약 일치하지 않거나 설정에 문제가 있다면 FAIL로 표시됩니다.
특히 구글(Gmail)처럼 중계 서버를 여러 개 거치는 구조에서는, 인증 정보를 보완하고 전달 경로에서도 인증 무결성을 유지하기 위해 ARC(Authenticated Received Chain) 방식의 ARC-Authentication-Results 항목이 추가로 기록되기도 합니다. ARC를 좀 더 설명하면 메일이 여러 서버를 거쳐 전달될 때도, 처음 인증 결과를 보존함으로써 중간 서버가 인증을 손상시키지 않았는지 확인할 수 있도록 해주는 메커니즘입니다.
◈ STEP③ DMARC 정책 적용
ⓐ 수신(Received) 적용(X)
※ iRedMail 오픈소스 메일 서버는 기본적으로 Amavisd-new 필터를 사용하며, DMARC 체크 기능은 포함되어 있지 않습니다. 이 내용은 앞선 포스팅(112)에서도 언급한 바 있습니다. 수신 DMARC까지 처리하려면 Postfix + OpenDKIM + OpenDMARC 구성이 필요합니다.
하지만 DMARC는 SPF와 DKIM 결과를 바탕으로 정책을 평가하는 보조 계층이기 때문에, 단독으로 사용할 수 없고 필수 구성 요소도 아닙니다. 즉 있으면 더 좋지만 없어도 SPF와 DKIM만으로도 기본적인 인증은 충분히 가능합니다. 수신된 DMARC가 어떻게 처리되는지에 대한 자세한 설명은 포스팅(113)을 참고해 주세요.

ⓑ 발송(Sender) 적용
※ 수신 측에서 체크만 할 수 있게 최소한의 등록을 합니다. TXT 레코드에 등록해 주면 됩니다.
※ 패턴은 동일하므로 캡처 위주로 참고하시기 바랍니다.
| 타입 | 호스트 | 값/위치 | TTL |
| TXT | _dmarc | "v=DMARC1; p=none; rua=mailto:foxydog@mydomainhost.com" | 3600(기본값) |


◇ 추가 내용
내용 중 Status「X」라고 해서 문제가 있는 게 아니라, 정책을 비활성화했다는 의미로 받아들이시면 됩니다. 즉 DMARC 분석은 하되, 이 메일을 차단하거나 격리하지 말고, 수신자 메일 서버 정책에 맡기겠다는 뜻입니다. 해당 정책도 여러 가지 옵션이 있지만, 아직까지 제대로 활용하지 않고 있습니다. 내 도메인 DNS에 DMARC 세팅을 해도 수신 측이 해당 정책을 체크하는 옵션을 활성화하지 않았다면 큰 의미는 없습니다. 처음에는 none 세팅으로 모니터링하다가 순차적으로 quarantine → reject 적용하는 게 안전합니다.
| 값 | 설명 | 흐름도 |
| p=none | 분석만 하고 차단/격리 하지 않음(→ 로그/보고서만 수집) | SPF/DKIM 세팅 감지 |
| p=quarantine | DMARC 실패 시 스팸처리함을 권장 | 일부 DMARC 실패한 메일은 격리 (스팸 처리 등) |
| p=reject | DMARC 실패 시 수신자가 아예 메일을 거부하게 요청 | 완전 실패 차단(스푸핑 방지 목적) |

◈ 리버스 도메인(PTR) 참고(캡처 대체)
※ G메일 강화 정책 내용(153)을 다룬 내용에 포함되어 있습니다.

◈ 마치며
전 세계 모든 메일 서버가 스팸, 바이러스, 악성 메일을 효과적으로 막기 위해서는 SPF, DKIM, DMARC, PTR과 같은 인증 정책이 반드시 필요합니다. 하지만 유료 솔루션이 아닌 오픈 소스 기반으로 메일 서버를 구축할 경우, 관리자 입장에서 설정할 항목이 많고, DNS와 같은 개념에 익숙하지 않다면 전체 흐름을 이해하기도 쉽지 않습니다.
특히, 이러한 보안 정책들을 전면적으로 강제 적용하게 되면, 오히려 설정이 되지 않은 서버나 사용자들에게는 메일 송수신이 불가능해지는 등 큰 혼란이 발생할 수 있습니다.
이를 해결하기 위해서는 먼저 대기업이나 주요 기관부터 보안 정책을 선도적으로 적용하고, 그에 따라 관련 관리자나 IT 관계자들에게 지속적인 교육과 안내가 병행되어야 합니다. 아무리 AI 기술이 발전하더라도, 전 세계를 흐르는 이메일을 자동으로 완벽하게 통제하는 것은 불가능에 가깝습니다. 결국에는 사람이 주기적으로 관리하고 점검하며, 변화하는 트렌드에 맞춰 유연하게 대응할 수 있는 능력이 중요합니다.
본 내용이 메일 서버를 직접 운영하거나 관리하는 모든 분들에게 조금이나마 도움이 되기를 바라며, 앞으로도 변화하는 환경 속에서 실용적인 정보들을 계속해서 공유드릴 수 있도록 하겠습니다..
'◈『Open(Source) Solution』 > 메일서버(iRedMail)' 카테고리의 다른 글
| Rocky Linux - iRedMail (Nginx, Postfix, Dovecot) TLS 인증서 적용 (0) | 2025.07.07 |
|---|---|
| Rocky Linux - iRedMail 오픈 소스 메일 서버 솔루션 설치 구축 (2) | 2025.07.05 |