परिभाषा
एक SPF Record (Sender Policy Framework record) एक domain के public DNS zone में published एक DNS TXT resource record है जो उस domain की ओर से email भेजने के लिए authorised IP addresses, IPv6 prefixes, और mail server hostnames enumerate करता है। जब एक receiving mail server एक inbound message accept करता है, तो वह sender के DNS से SPF record के लिए query करता है और connecting IP address को policy के विरुद्ध compare करता है। यदि IP listed नहीं है, तो receiving server message को softfail के रूप में mark कर सकता है, इसे outright reject कर सकता है, या आगे evaluation के लिए flag कर सकता है — domain owner द्वारा set की गई policy qualifier पर depending।
SPF पहली बार IETF standard के रूप में RFC 4408 (2006) में formalised हुआ था और बाद में current authoritative specification में RFC 7208 में updated हुआ, अप्रैल 2014 में Internet Engineering Task Force (IETF) द्वारा published। यह तीन complementary email authentication standards में से एक है, DKIM (DomainKeys Identified Mail) और DMARC (Domain-based Message Authentication, Reporting, and Conformance) के साथ।
यह कैसे काम करता है
SPF evaluation process में SMTP handshake के MAIL FROM phase के दौरान receiving mail server के SMTP engine द्वारा perform किए गए कई sequential steps शामिल हैं।
Domain owner DNS में एक SPF TXT record publish करता है। एक typical record इस syntax का अनुसरण करता है: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all। Components हैं: v=spf1 (version identifier), एक या अधिक mechanisms (include, ip4, ip6, a, mx, exists), और एक final qualifier (+all, -all, ~all, ?all)। -all qualifier का अर्थ है एक hard fail — कोई भी server जो explicitly listed नहीं है authorised नहीं है। ~all qualifier (softfail) message को pass करता है लेकिन policy discrepancy note करता है, आमतौर पर migration periods के दौरान उपयोग किया जाता है।
जब एक message आता है, तो receiving MTA (Mail Transfer Agent) envelope sender domain (MAIL FROM address, जिसे RFC5321.MailFrom address भी कहा जाता है) extract करता है और _spf.<domain> के लिए या directly domain root पर एक DNS TXT lookup करता है। SPF library प्रत्येक mechanism को order में evaluate करती है जब तक कि एक match नहीं हो जाता या दस DNS lookups की limit नहीं पहुंच जाती (RFC 7208 section 4.6.4 में defined “SPF PermError” limit)। Result — Pass, Fail, SoftFail, Neutral, TempError, या PermError — message के Received-SPF header में inserted होता है और spam filter तथा किसी भी DMARC policy engine को pass किया जाता है।
यह note करना critical है कि SPF envelope sender (MAIL FROM) को authenticate करता है, message body में visible From header को नहीं। यह distinction का अर्थ है कि अकेले SPF email clients में display-name spoofing को नहीं रोकता, यही कारण है कि DMARC alignment — RFC5322.From domain से match करने के लिए दोनों SPF और/या DKIM results की आवश्यकता — complete protection के लिए necessary है।
आप इसे कहाँ देखते हैं
SPF records उन सभी contexts में appear होते हैं जहां email deliverability और sender reputation matter करती है। Amazon SES, SendGrid, Mailgun, Postmark, और SparkPost जैसी services द्वारा operated transactional email infrastructure में messages के authentication checks pass करने से पहले domain owners को provider के sending infrastructure की ओर pointing करने वाले SPF include mechanisms add करना required है।
Email confirmation votes भेजने वाले Contest platforms — जिनमें Woobox, ShortStack, और Mailchimp Transactional (Mandrill) का उपयोग करने वाले custom-built systems शामिल हैं — sending domain के पास एक valid SPF record होने पर rely करते हैं। Google (Gmail), Microsoft (Outlook / Exchange Online Protection), और Yahoo Mail सहित mailbox providers SPF को अपनी deliverability algorithms के लिए एक input के रूप में evaluate करते हैं। एक missing या misconfigured SPF record substantially probability बढ़ाता है कि confirmation emails silently spam folders में delivered होंगे या entirely rejected किए जाएंगे, जिससे votes unconfirmed जाएंगे।
Cloudflare, AWS Route 53, GoDaddy, और Namecheap जैसे providers से DNS hosting panels अपनी management interfaces के माध्यम से SPF TXT record editing expose करते हैं। MXToolbox SPF Lookup, Google Admin Toolbox, और DMARCIAN के SPF Surveyor जैसे diagnostic tools domain owners को published records को inspect और validate करने की अनुमति देते हैं।
व्यावहारिक उदाहरण
एक contest platform [email protected] से vote-confirmation emails भेजता है। Domain votes.example.com के पास SPF record v=spf1 include:sendgrid.net -all है। जब Gmail एक confirmation message receive करता है, तो उसका inbound SMTP server votes.example.com के SPF record के लिए DNS query करता है, sendgrid.net include mechanism को expand करता है, और connecting IP को SendGrid की authorised server list के विरुद्ध check करता है। यदि IP match होता है, तो SPF result Pass है और message inbox में आगे बढ़ता है। यदि domain के पास कोई SPF record नहीं होता, तो Gmail का filter message को unauthenticated के रूप में treat करेगा, inbox placement probability को कम करते हुए।
एक regional newspaper contest अपने SPF record को update किए बिना अपने transactional email provider को Mailchimp से Amazon SES में बदल देती है। Confirmation emails Microsoft Outlook पर SPF checks fail होने लगते हैं और bulk-foldered होते हैं, voters को confirmation window miss करवाते हुए। Contest administrator MXToolbox का उपयोग करके issue diagnose करता है, SPF record में include:amazonses.com add करता है, और deliverability DNS propagation window (आमतौर पर TTL settings पर depending 0-48 hours) के अंदर recover होती है।
संबंधित अवधारणाएँ
SPF three-standard email authentication stack का एक pillar है: cryptographic signature verification के लिए DKIM और SPF और DKIM results पर action करने वाली policy layer के लिए DMARC देखें। Contest operations पर practical impact Email Confirmation Vote में describe किया गया है, जहां confirmation message की deliverability सबसे critical operational dependency है। BIMI (Brand Indicators for Message Identification), DMARC पर building एक newer standard, verified senders को supporting mailbox providers में एक brand logo display करने की अनुमति देता है — एक emerging trust signal जो यहां cover नहीं किया गया।
