SPF và DMARC cho tên miền chỉ nhận: chặn giả mạo email

Hai chiều, và bạn mới cấu hình một chiều

Trỏ một tên miền về đây chỉ cần một bản ghi DNS. Bản ghi đó — MX — trả lời đúng một câu hỏi: thư gửi đến tên miền này sẽ đi đâu? Đó là tất cả những gì một catch-all cần, và ngay khi nó phân giải được, tên miền đã hoạt động. Nhưng cũng ngay lúc đó, nó mới chỉ được cấu hình một nửa, vì một tên miền được dùng theo hai chiều, và bản ghi MX không nói gì về chiều thứ hai.

Chiều thứ hai mới là chiều đáng chú ý. Không có gì trong giao thức thư điện tử ngăn một người lạ viết tên miền của bạn vào dòng From: của một thư mà họ gửi từ máy của chính họ. Họ không cần quyền truy cập vào DNS, nhà đăng ký tên miền hay hộp thư của bạn — địa chỉ trong một thư chỉ là một lời tự nhận, không phải một bằng chứng, và nó luôn luôn như vậy. Điều quyết định lời tự nhận đó có được tin hay không chính là những gì tên miền của bạn nói về việc ai được phép đưa ra lời tự nhận ấy:

Tên miền không nói gì cả

Một máy chủ nhận thư không tìm thấy chính sách SPF hay DMARC nào, và phải dựa vào suy đoán riêng của nó: uy tín, nội dung, cách tên miền đã từng hành xử trước đây. Một tên miền hoàn toàn mới, không có lịch sử và không có chính sách, gần như là mục tiêu lý tưởng để giả mạo, vì không có gì để phản bác lại sự giả mạo đó và không có gì để quy trách nhiệm sau đó.

Tên miền nói không

Cũng máy chủ đó tìm thấy một chính sách đã được công bố, nói rằng không có máy nào ở bất cứ đâu được phép gửi thư nhân danh tên miền này, và rằng những thư thất bại phải bị từ chối. Nó không còn là một quyết định cảm tính nữa. Thư bị từ chối ngay từ cửa, thường là không bao giờ chạm tới cả thư mục spam.

Đây không phải một giả định về các thương hiệu lớn. Những tên miền không gửi thư ra ngoài bị nhắm đến chính vì chúng không có chính sách nào cả — một cái tên không ai bảo vệ, dùng trong hai tuần rồi bỏ đi, có giá trị với kẻ gửi thư rác hơn nhiều so với một cái tên biết chống trả.

Vì sao bạn có thể bỏ qua phần mà ai khác cũng mất sáu tháng

Nếu bạn từng đọc gì đó về DMARC trước đây, hẳn bạn đã đọc rằng đó là một dự án dài hơi và cần thận trọng. Lời khuyên đó đúng, nhưng nó không nói về trường hợp của bạn. Nó được viết cho một tên miền có gửi thư, và nó dài vì một lý do duy nhất: trước khi bạn có thể bảo cả thế giới từ chối mọi thư thất bại, bạn phải tìm ra từng hệ thống thực sự gửi thư nhân danh bạn và khiến từng hệ thống đó vượt qua kiểm tra. Ở một tổ chức bình thường, danh sách đó dài hơn bất kỳ ai tưởng tượng, và nó được phát hiện dần ra chứ không phải đã biết sẵn từ đầu:

1. Công bố một chính sách không làm gì cả. p=none yêu cầu bên nhận báo cáo lại nhưng không thay đổi gì, để một người gửi bị bỏ sót không bị chính sách này cắt đứt.
2. Đọc báo cáo trong nhiều tuần. Hệ thống xuất hóa đơn, bộ phận hỗ trợ, công cụ gửi bản tin, nền tảng tuyển dụng mà ai đó đã đăng ký từ năm 2019 — mỗi thứ đều xuất hiện như một nguồn gửi thư bị thất bại, và mỗi thứ đều phải được cấp phép hoặc bị loại bỏ.
3. Siết chặt theo từng giai đoạn. Chuyển sang quarantine, chờ, theo dõi, rồi mới chuyển sang reject, vì mỗi bước siết chặt đều có thể âm thầm chặn đứng những thư mà ai đó đang trông cậy vào.

Mỗi bước trong số đó tồn tại để bảo vệ những người gửi hợp lệ khỏi chính chính sách của bạn. Một tên miền đã được trỏ về một hộp thư chỉ nhận thì không có người gửi hợp lệ nào cả. Danh sách đó không dài, không khó phát hiện, cũng không phải một phần chưa biết — nó trống rỗng. Và một chính sách từ chối mọi thứ thì không thể làm hỏng một người gửi không hề tồn tại.

Còn có một lý do bậc hai để đi thẳng đến trạng thái cuối cùng. Một tên miền dừng lại ở p=none đang công bố một chính sách không yêu cầu gì cả, và một máy chủ nhận thư sẽ đối xử với nó gần như y hệt một tên miền không có chính sách nào. Bản ghi đó tồn tại, nên trông như đã được xử lý xong — điều này còn tệ hơn cả việc rõ ràng chưa hoàn thành, vì sẽ chẳng ai quay lại để hoàn thành nó nữa.

Ba bản ghi

Cả ba đều là bản ghi TXT, và cả ba đều được thêm vào bên cạnh bản ghi MX bạn đã có sẵn. Tên bản ghi được viết theo cách hầu hết các bảng điều khiển DNS yêu cầu — tương đối so với vùng (zone), trong đó @ nghĩa là chính tên miền đó. Nếu bảng điều khiển của bạn yêu cầu tên đầy đủ, hãy viết yourdomain.com, _dmarc.yourdomain.com và *._domainkey.yourdomain.com thay vào đó.

Nếu nhà cung cấp của bạn yêu cầu giá trị phải đặt trong dấu ngoặc kép, hãy đặt nó vào. Một số bảng điều khiển tự thêm dấu ngoặc kép cho bạn rồi vô tình lưu chúng hai lần, tạo ra một bản ghi mà không công cụ kiểm tra nào đọc được — nếu một giá trị trả về từ dig có hai lớp dấu ngoặc kép bao quanh, đó chính là điều đã xảy ra.

Ba giá trị này, sẵn sàng để dán vào. Hãy sao chép thay vì gõ lại: thiếu một dấu chấm phẩy trong bản ghi DMARC khiến toàn bộ danh sách thẻ không thể phân tích được, và một chính sách không phân tích được thì bị coi như không có chính sách nào cả.

SPF — trên chính tên miềnv=spf1 -allSao chép

DMARC — trên tên _dmarcv=DMARC1; p=reject; sp=reject; adkim=s; aspf=sSao chép

DKIM — trên tên *._domainkeyv=DKIM1; p=Sao chép

Mỗi từ trong các bản ghi đó thực sự làm gì

Năm quyết định, và đáng để biết rõ cái nào là cái nào — chủ yếu để sau này, nếu tên miền bắt đầu gửi thư, bạn nhận ra được nên nới lỏng cái nào.

-all

Phần cuối của bản ghi SPF, và cũng là phần duy nhất quan trọng ở đây. Nó có nghĩa là bất cứ thứ gì không được liệt kê ở trên đều là giả mạo, mà ở trên thì chẳng có gì được liệt kê cả. Lựa chọn phổ biến khác, ~all, có nghĩa là có thể là giả mạo, nhưng vẫn cứ gửi và đánh dấu lại — đây là câu trả lời đúng khi bạn vẫn đang tìm ra hết những người gửi của mình, và là câu trả lời sai khi bạn đã chắc chắn không có người gửi nào cả.

p=reject

Việc một máy chủ nhận thư nên làm với thư tự nhận là tên miền này nhưng thất bại kiểm tra. none nghĩa là chỉ báo cáo, quarantine nghĩa là coi như đáng ngờ, reject nghĩa là từ chối ngay trong phiên trao đổi SMTP. Reject là lựa chọn duy nhất giữ thư đó hoàn toàn ngoài tầm mắt con người.

sp=reject

Điều tương tự, áp dụng cho mọi tên miền phụ — kể cả những tên miền phụ chưa hề tồn tại. Nếu thiếu thẻ này, kẻ giả mạo sẽ dùng billing.yourdomain.com, vốn không có bản ghi riêng, và không kế thừa gì để ngăn chặn nó. Thẻ này mặc định lấy giá trị của p, nên bản ghi vẫn hoạt động y hệt dù không viết ra; nó được viết ra rõ ràng vì một chính sách bạn không thấy khi đọc lại bản ghi là một chính sách bạn sẽ cho là không tồn tại.

adkim=s, aspf=s

Căn chỉnh nghiêm ngặt. Nó yêu cầu tên miền đã xác thực phải chính xác là tên miền trong dòng From:, chứ không chỉ là một tên miền có liên quan — nên một thư từ anything.yourdomain.com không thể mượn kết quả vượt kiểm tra vốn thuộc về tên miền cha. Chế độ nới lỏng (relaxed) là mặc định, còn nghiêm ngặt (strict) là điều mà một tên miền không có gì để cấp phép nên tuyên bố.

v=DKIM1; p=

Một khóa công khai DKIM nhưng không chứa khóa nào bên trong. Đặc tả kỹ thuật nói rõ rằng một khóa rỗng có nghĩa là đã bị thu hồi, nên bất kỳ chữ ký nào nêu tên một selector thuộc tên miền này đều thất bại khi xác minh thay vì bị bỏ qua. Bản ghi dạng wildcard bao phủ mọi tên selector mà kẻ giả mạo có thể nghĩ ra, vì chính họ là người chọn cái tên đó.

Và bản ghi phải giữ nguyên y như cũ

Không điều gì ở trên đụng đến thư gửi đến, và cũng không điều gì nên đụng đến. Bản ghi MX mới là thứ khiến mọi địa chỉ trên tên miền trở thành một hộp thư ở đây, và nó không hề thay đổi bởi bất cứ điều gì kể trên:

Bản ghi MX — không đổi10 smtp.grabmail.ioSao chép

Ba bản ghi mới và bản ghi này trả lời những câu hỏi khác nhau, nên chúng không can thiệp vào nhau: SPF và DMARC được các máy chủ đọc để quyết định có nên chấp nhận thư tự nhận là bạn hay không, còn MX được các máy chủ đọc để quyết định chuyển thư gửi đến bạn về đâu. Một tên miền có đủ cả bốn bản ghi là một tên miền nhận mọi thứ và không bảo lãnh cho bất kỳ ai.

Kiểm tra lại thành quả, chỉ với ba câu lệnh

DNS không phải nơi để phỏng đoán. Mỗi bản ghi này được công bố ra để người lạ đọc được, nghĩa là bạn cũng có thể đọc nó y hệt như cách họ sẽ đọc — không cần tài khoản, không cần công cụ, không cần trang web nào để dán tên miền vào:

$ dig +short TXT      yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX       yourdomain.com

Thay bằng tên miền của chính bạn. Điều bạn cần tìm là như sau, có thể xê xích chút ít tùy vào những bản ghi TXT khác bạn đã có sẵn trên tên đó:

"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.

Bốn cách mọi thứ có thể sai, xếp theo tần suất gặp phải từ nhiều đến ít:

Câu lệnh đầu tiên không trả lời gì cả

Bản ghi chưa lan truyền xong, hoặc nó đã được thêm vào sai tên. Bản ghi TXT trên chính tên miền phải đặt ở @, không phải ở www — một bảng điều khiển mặc định quay lại tên cuối cùng bạn từng chỉnh sửa thường chính là thủ phạm.

Hai bản ghi SPF cùng xuất hiện

Một tên miền chỉ được phép có đúng một bản ghi SPF. Hai bản ghi không nghiêm ngặt hơn một — đó là một lỗi cố định, và một máy chủ nhận thư khi thấy hai bản ghi sẽ coi việc kiểm tra SPF là bị hỏng chứ không phải là thất bại. Nếu bạn đã có sẵn một bản ghi SPF, hãy sửa bản ghi đó thay vì thêm một bản ghi thứ hai.

Dòng DMARC trả về nhưng không có gì thực thi nó

Hãy đọc kỹ giá trị đó: nó phải bắt đầu bằng v=DMARC1, và các thẻ phải được phân tách bằng dấu chấm phẩy. Một bản ghi thiếu thẻ phiên bản, hoặc một bản ghi mà dấu chấm phẩy vô tình thành dấu phẩy, không phải là một chính sách yếu hơn — đó là một chính sách không phân tích được, và bị coi như không hề có chính sách nào.

Câu trả lời MX đã thay đổi

Điều đó lẽ ra không nên xảy ra. Nếu dòng MX giờ đây biến mất, hoặc chỉ còn một dấu chấm trơ trọi, hoặc liệt kê một host không phải là smtp.grabmail.io, hãy dừng lại và khôi phục nó trước khi làm bất cứ điều gì khác — đó là bản ghi mà hộp thư của bạn phụ thuộc vào.

Phần mà hầu như ai cũng bỏ sót: tên miền phụ

DMARC và SPF không chia không gian tên miền theo cùng một cách, và sự khác biệt đó chính là nơi một tên miền được bảo vệ cẩn thận vẫn có thể rò rỉ. sp=reject thực sự bao phủ mọi tên miền phụ, dù đã tồn tại hay chưa. SPF thì hoàn toàn không hoạt động như vậy: nó được tra cứu trên đúng cái tên xuất hiện trong envelope, và một tên không có bản ghi SPF riêng thì đơn giản là không có bản ghi SPF nào cả — nó không kế thừa bản ghi của tên miền cha.

DMARC tự nó đã bao phủ được hàng thứ hai, nên đây là một lớp phòng thủ kép chứ không phải một lỗ hổng — nhưng một bản ghi SPF dạng wildcard chỉ tốn một dòng và cũng đóng luôn khoảng trống ở tầng SPF, điều này quan trọng với những bên nhận có kiểm tra SPF nhưng không triển khai DMARC:

SPF dạng wildcard — thêm một bản ghi TXT nữa* TXT v=spf1 -allSao chép

Một wildcard DNS chỉ trả lời cho những tên không có bản ghi riêng của chính nó. Nếu mail.yourdomain.com đã có sẵn bất kỳ bản ghi TXT nào, wildcard sẽ không được tham chiếu đến cho tên đó nữa và bạn sẽ cần công bố bản ghi SPF ở đó một cách tường minh. Với một tên miền chỉ dùng làm catch-all, tình huống đó đủ hiếm để đáng biết đến chứ không đáng để lên kế hoạch phòng trước.

Báo cáo, và liệu chúng có đáng để bật lên không

DMARC có một khía cạnh báo cáo: thêm thẻ rua vào, và các bên nhận tham gia sẽ gửi cho bạn một bản tóm tắt hằng ngày về mọi thứ đã tự nhận là tên miền của bạn cùng những gì đã xảy ra với chúng. Đây là phần duy nhất của DMARC cho bạn biết điều gì đó bạn chưa từng biết, và trên một tên miền trỏ về đây, việc thu thập báo cáo này không tốn kém gì cả, vì địa chỉ nhận báo cáo hoàn toàn có thể là một địa chỉ trên chính tên miền đó:

DMARC kèm báo cáo — thay tên miền của bạn vàov=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.comSao chép

Gửi báo cáo đến một địa chỉ trên cùng tên miền giúp tránh được một chi tiết trong đặc tả kỹ thuật hay khiến người ta mắc bẫy: nếu rua nêu tên một địa chỉ ở một tên miền khác, tên miền đó phải công bố một bản ghi cho phép nhận báo cáo của bạn, và chừng nào chưa làm vậy thì hầu hết các bên gửi sẽ không gửi báo cáo nào cả. Cùng một tên miền thì không cần bản ghi như vậy, không có gì để sai sót. Trước khi bật tính năng này lên, cũng nên biết trước những gì sẽ đến là gì:

• Chúng là XML, nén gzip, dưới dạng tệp đính kèm. Không phải một bản tóm tắt bạn có thể vừa nhâm nhi cà phê vừa đọc. Các tên miền nhỏ nhận được vài báo cáo mỗi ngày từ các nhà cung cấp hộp thư lớn, mỗi báo cáo vài kilobyte; bạn sẽ cần một công cụ để giải nén và đọc chúng.
• Trống rỗng chính là kết quả tốt. Một tên miền không gửi thư nào thì nên tạo ra những báo cáo chỉ toàn liệt kê thất bại, và một tuần yên ắng nghĩa là hiện không ai đang giả mạo bạn — đó là một thông tin, và đây là cách duy nhất để biết được nó.
• Chúng đến dưới dạng thư bình thường. Ở đây điều đó nghĩa là một hộp thư bình thường: đọc được trên trình duyệt và qua API giống như mọi thứ khác, và bị xóa sau 5 ngày cùng với mọi thứ khác.

Nếu bạn thà không thu thập báo cáo nào cả, hãy bỏ hẳn thẻ đó đi. Một bản ghi DMARC không có rua vẫn là một bản ghi hoàn toàn hợp lệ và bảo vệ hiệu quả y hệt; báo cáo là cách bạn biết được điều gì đang xảy ra, chứ không phải cách chính sách được thực thi.

Những gì các bản ghi này không làm được

Các bản ghi này có phạm vi hẹp, và việc hiểu rõ ranh giới đó chính là khác biệt giữa một biện pháp kiểm soát bạn tin cậy đúng cách và một biện pháp bạn tin cậy sai cách. Bốn điều chúng không bao phủ:

Chúng không lọc hộp thư của chính bạn

SPF và DMARC trên tên miền của bạn là chỉ dẫn dành cho các máy chủ nhận thư từ bạn. Chúng được hệ thống thư của người khác đọc, chứ không bao giờ là hệ thống của bạn, và chúng không có tác động gì đến những gì xuất hiện trong catch-all. Những gì đến hộp thư vẫn là bất cứ thứ gì thế giới gửi tới một địa chỉ mà bằng chứng duy nhất để dùng nó chỉ là biết đến nó.

Chúng không chặn được một cái tên trong dòng From

Một thư ghi Your Company <attacker@gmail.com> vượt qua mọi kiểm tra, vì tên miền đã được xác thực thực sự là tên miền của kẻ tấn công. DMARC bảo vệ tên miền, chứ không bảo vệ tên hiển thị đứng trước nó — và trên điện thoại, tên hiển thị thường là thứ duy nhất được hiển thị ra.

Chúng không đụng đến một tên miền giả dạng

Một tên miền chỉ khác tên miền của bạn đúng một ký tự vẫn là tên miền của người khác với bản ghi của người khác. Không có gì bạn công bố chạm được đến nó. Đó là vấn đề của nhà đăng ký tên miền và việc giám sát, và đó thực sự là một vấn đề khác hẳn.

Chúng không khiến hộp thư trở nên riêng tư

Vẫn không có mật khẩu nào cho một địa chỉ ở đây: ai biết địa chỉ đó đều đọc được nó, đó là thỏa thuận mà toàn bộ dịch vụ này đưa ra. Tên miền riêng của bạn loại bỏ việc phải đoán mò, chứ không loại bỏ việc bị đọc trộm — phiên bản trung thực của điều đó nằm trong hướng dẫn về tên miền catch-all.

Thực hiện toàn bộ, từ đầu đến cuối

Toàn bộ công việc, theo đúng thứ tự giữ cho tên miền vẫn hoạt động ở mọi bước:

1. Xác nhận MX trước tiên. dig +short MX yourdomain.com phải trả về smtp.grabmail.io và không gì khác. Hãy sửa điều đó trước khi thêm bất cứ gì, vì phần còn lại vô nghĩa trên một tên miền không nhận được thư.
2. Thêm bản ghi SPF tại @, trừ khi đã có sẵn một bản ghi — trong trường hợp đó hãy sửa nó, vì có hai bản ghi là một lỗi chứ không phải một thiết lập nghiêm ngặt hơn.
3. Thêm bản ghi DMARC tại _dmarc, đi thẳng đến chính sách nghiêm ngặt nhất. Ở đây không có lộ trình triển khai nào cần chia giai đoạn và cũng không có gì để làm hỏng khi bỏ qua nó.
4. Thêm bản ghi DKIM dạng wildcard tại *._domainkey, và bản ghi SPF dạng wildcard nếu bạn muốn tầng tên miền phụ được khóa chặt hai lớp.
5. Đọc lại cả bốn bản ghi bằng dig, nhắm vào một trình phân giải công khai, sau khi TTL đã có đủ thời gian để hết hạn.
6. Tự gửi cho mình một thư. Gửi thư đến một trong các địa chỉ của bạn trên tên miền đó từ bất cứ đâu rồi mở hộp thư ra xem. Nếu thư đến nơi, phía nhận thư đã sống sót qua thay đổi này, và đó là điều duy nhất đáng để kiểm tra xem có bị ảnh hưởng ngược hay không.

Vậy là tên miền đã hoàn tất: nó chấp nhận mọi địa chỉ bạn sẽ từng nghĩ ra trên đó, và nó không bảo lãnh cho bất kỳ ai cả. Nếu bạn chưa kết nối tên miền, hãy bắt đầu với hướng dẫn catch-all — chỉ một bản ghi và cũng mất năm phút tương tự — rồi quay lại trang này sau, đó là thứ tự không để lại việc gì dang dở.

Câu hỏi