Bản ghi SPF chi tiết máy chủ nào được phép gửi thư cho miền của bạn.
Câu hỏi 1-3 thực sự tóm tắt toàn bộ quan điểm của SPF: Bạn nên liệt kê địa chỉ của tất cả các máy chủ được phép gửi thư đến từ miền của bạn.
Nếu bạn không có một danh sách đầy đủ tại thời điểm này, nói chung không nên thiết lập một bản ghi SPF. Ngoài ra, một tên miền chỉ có thể có một bản ghi SPF, vì vậy bạn sẽ cần kết hợp tất cả thông tin vào một bản ghi.
Các câu hỏi cá nhân thực sự chỉ giúp phá vỡ danh sách cho bạn.
- yêu cầu bạn cho các tên miền khác mà máy chủ thư có thể chuyển tiếp thư từ bạn; nếu bạn có một máy chủ MX phụ tại mail-relay.example.org và đó là máy chủ thư chính (bản ghi MX) cho tên miền
example.org
, thì bạn nên nhập mx:example.org
. Bản ghi SPF của bạn phải bao gồm bản ghi MX của tên miền của bạn trong gần như mọi trường hợp ( mx
).
- yêu cầu bạn cho netblocks ip của bạn. Nếu bạn có máy chủ colocated tại 1.2.3.0/28 và không gian địa chỉ văn phòng của bạn là 6.7.8.0/22, hãy nhập
ip4:1.2.3.0/28 ip4:6.7.8.0/22
. Không gian IPv6 nên được thêm vào như ví dụ ip6:2a01:9900:0:4::/64
.
- nếu (ví dụ) bạn cũng có một máy tắt trong văn phòng của người khác phải được phép gửi thư từ tên miền của bạn, hãy nhập nó, ví dụ như
a:mail.remote.example.com
.
Người dùng điện thoại di động của bạn có vấn đề. Nếu họ gửi email bằng cách kết nối với máy chủ thư của bạn bằng cách sử dụng SMTP AUTH và gửi qua máy chủ đó, thì bạn đã xử lý chúng bằng cách liệt kê địa chỉ của máy chủ thư trong (2). Nếu họ gửi email bằng cách chỉ kết nối với bất cứ điều gì mail server cung cấp các nhà cung cấp của 3G / HSDPA, sau đó bạn có thể không làm SPF có ý nghĩa cho đến khi bạn đã tái xây dựng lại cơ sở hạ tầng email của bạn để bạn làm kiểm soát tất cả các điểm mà từ đó email dường như là từ bạn chạm Internet.
Câu hỏi 4 hơi khác một chút và hỏi người nhận nên làm gì với email tuyên bố là từ miền của bạn không đến từ một trong các hệ thống được liệt kê ở trên. Có một số câu trả lời hợp pháp, nhưng những câu trả lời thú vị duy nhất là ~all
(thất bại mềm) và -all
(thất bại cứng). ?all
(không có câu trả lời) cũng vô dụng như ~all
(qv), và +all
là một sự gớm ghiếc.
~all
là sự lựa chọn đơn giản; nó nói với mọi người rằng bạn đã liệt kê một loạt các hệ thống được ủy quyền để gửi thư từ bạn, nhưng bạn không cam kết danh sách đó là đầy đủ, vì vậy thư từ miền của bạn đến từ các hệ thống khác vẫn có thể hợp pháp. Tôi mong bạn không làm điều đó. Nó không chỉ làm cho SPF hoàn toàn vô nghĩa, mà một số quản trị viên thư trên SF còn cố tình định cấu hình máy thu SPF của họ để coi ~all
là huy hiệu của người gửi thư rác. Nếu bạn không định làm gì -all
, đừng bận tâm đến SPF .
-all
là sự lựa chọn hữu ích; nó nói với mọi người rằng bạn đã liệt kê các hệ thống được phép gửi email từ bạn và không có hệ thống nào khác được phép làm như vậy, vì vậy họ có thể từ chối email từ các hệ thống không được liệt kê trong bản ghi SPF của bạn. Đây là điểm của SPF, nhưng bạn phải chắc chắn rằng bạn đã liệt kê tất cả các máy chủ được ủy quyền để tạo hoặc chuyển tiếp thư từ bạn trước khi bạn kích hoạt nó .
Google được biết là khuyên rằng
Xuất bản bản ghi SPF sử dụng -all thay vì ~ tất cả có thể dẫn đến các vấn đề giao hàng.
tốt, vâng, nó có thể; đó là toàn bộ điểm SPF . Chúng tôi không thể biết chắc chắn tại sao google đưa ra lời khuyên này, nhưng tôi cực kỳ nghi ngờ rằng đó là để ngăn chặn những người quản trị hệ thống không biết chính xác email của họ bắt nguồn từ việc gây ra vấn đề giao hàng. Nếu bạn không biết tất cả email của mình đến từ đâu, đừng sử dụng SPF . Nếu bạn đang sử dụng SPF, hãy liệt kê tất cả các địa điểm xuất phát và nói với thế giới rằng bạn tự tin trong danh sách đó -all
.
Lưu ý rằng không ai trong số này ràng buộc trên máy chủ của người nhận; thực tế là bạn quảng cáo một bản ghi SPF theo cách không bắt buộc ai khác phải tôn vinh nó. Tùy thuộc vào quản trị viên của bất kỳ máy chủ thư cụ thể nào mà email họ chọn chấp nhận hoặc từ chối. Những gì tôi nghĩ SPF làm là cho phép bạn từ chối mọi trách nhiệm hơn nữa đối với email được cho là từ miền của bạn, nhưng không phải vậy. Bất kỳ quản trị viên thư nào đến gặp bạn đều phàn nàn rằng tên miền của bạn đang gửi cho họ thư rác khi họ không muốn kiểm tra bản ghi SPF mà bạn quảng cáo sẽ nói với họ rằng email nên bị từ chối có thể được gửi đi bằng một con bọ chét trong tai họ.
Vì câu trả lời này đã được chuẩn hóa, tốt hơn tôi nên nói một vài từ về include
và redirect
. Cái sau đơn giản hơn; nếu bản ghi SPF của bạn, giả sử example.com
, nói redirect=example.org
, thì example.org
bản ghi SPF thay thế cho bản ghi của bạn. example.org
cũng được thay thế cho tên miền của bạn trong các lần tra cứu đó (ví dụ: nếu example.org
bản ghi của nó bao gồm mx
cơ chế, việc MX
tra cứu nên được thực hiện example.org
chứ không phải trên miền của chính bạn).
include
bị hiểu lầm rộng rãi, và như các tác giả của tiêu chuẩn lưu ý " tên 'bao gồm' được lựa chọn kém ". Nếu bản ghi include
của bản ghi SPF của bạn example.org
, thì example.org
bản ghi của người nhận nên được kiểm tra để xem liệu nó có đưa ra bất kỳ lý do nào (bao gồm +all
) để chấp nhận email của bạn không . Nếu có, thư của bạn sẽ vượt qua. Nếu không, người nhận nên tiếp tục xử lý bản ghi SPF của bạn cho đến khi hạ cánh trên all
cơ chế của bạn . Do đó, -all
hoặc thực sự là bất kỳ việc sử dụng nào khác all
ngoại trừ +all
, trong một include
bản ghi d, không ảnh hưởng đến kết quả xử lý.
Để biết thêm thông tin về các bản ghi SPF http://www.openspf.org là một tài nguyên tuyệt vời.
Xin đừng hiểu sai cách này, nhưng nếu bạn nhận được một bản ghi SPF sai, bạn có thể ngăn một phần đáng kể của internet nhận email từ bạn cho đến khi bạn sửa nó. Câu hỏi của bạn cho thấy bạn có thể không hoàn toàn au fait với những gì bạn đang làm, và nếu đó là trường hợp, sau đó bạn có thể muốn xem xét việc nhận hỗ trợ chuyên nghiệp trước khi bạn làm điều gì đó mà dừng lại bạn gửi email đến một awful nhiều người.
Chỉnh sửa : cảm ơn bạn vì những lời tốt đẹp của bạn, họ được đánh giá cao.
SPF chủ yếu là một kỹ thuật để ngăn chặn joe-jobbing , nhưng một số người dường như đã bắt đầu sử dụng nó để cố gắng phát hiện thư rác. Một số trong số đó thực sự có thể gắn một giá trị âm với việc bạn không có bản ghi SPF nào cả, hoặc bản ghi vượt mức (ví dụ a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2
, khá lén lút tương đương +all
), nhưng điều đó tùy thuộc vào họ và bạn không thể làm gì nhiều về nó.
Cá nhân tôi nghĩ rằng SPF là một điều tốt và bạn nên quảng cáo một bản ghi nếu cấu trúc thư hiện tại của bạn cho phép, nhưng rất khó để đưa ra một câu trả lời có thẩm quyền, hợp lệ cho toàn bộ internet, về cách mọi người đang sử dụng bản ghi DNS được thiết kế cho mục đích cụ thể, khi họ quyết định sử dụng nó cho một mục đích khác. Tất cả tôi có thể nói một cách chắc chắn là nếu bạn làm quảng cáo một bản ghi SPF với một chính sách -all
, và bạn nhận được nó sai, rất nhiều người sẽ không bao giờ thấy mail của bạn.
Chỉnh sửa 2 : đã xóa theo bình luận và để cập nhật câu trả lời.