Sender Policy Framework Records

The SPF checking is turned off by default; however, as this device will be sending NDR's and errors (and optionally, all email) you will need to have a valid RDNS (reverse DNS) that matches the forward DNS record.

If you enable SPF checking for incoming email, the SpammerTrap will add additional 'spam points' to the email score if the SPF records don't match.  Enabling or disabling SPF checking on the SpammerTrap has no affect on YOUR SPF records, but below is some general information on using SPF records for your domain (note: publishing SPF records can help cut down on bounced bounces forged in your name, as well as spam send out in your name, assuming the recipient server also checks SPF records) 

Note, if you send email to anyone using SPF, you should include the SpammerTrap in the IP address. This allows the SpammerTrap to send email from your domain. If an AOL user spams from AOL, SPF says 'ok'. The same thing will happen if myhobasedbusinessscam.com spams you and is smart enough to add SPF records.

Setting SPF (and SRS) to work correctly assumes the ISP or mail administrator has communicated with the DNS administrator and correctly put SPF records in. Many LARGE companies don't even have correct 'helo' or RDNS records on their mail servers; some don't even have MX records.

If I have a ' This e-mail address is being protected from spambots. You need JavaScript enabled to view it ' account and go to 'www.newssomething.com' and they have a button 'email this to a friend', there can be a problem. The SECNAP DNS administrator did not authorize newssomething.com as a valid SPF record.

Another example would be if I have road warriors who have a Comcast home cable modem. They send through Comcast MX (as This e-mail address is being protected from spambots. You need JavaScript enabled to view it ). The received might bounce them since SPF records aren't correct.