SPF: Its Functionality and How To Use It On Your Server - SPF Basics
(Page 2 of 4 )
There are two sides to an SPF implementation. First, a domain owner must publish that domain’s authorized mail servers in a DNS TXT record. The second part is performed by a mail-server enforcing these records when accepting email. Since the first part is relatively simple, we’ll focus on the second part for further explanation here.
When an SPF enabled email server receives a HELO or EHLO connect request from a remote server wishing to deliver mail, the local server can choose whether or not to perform an SPF check on that server’s domain name and IP address. If certain domains are listed in a “whitehole” list, the server may choose not to perform an SPF check. At this point, the local server will take the purported credentials of the remote server and perform a DNS lookup for that domain. It will then check the TXT DNS records for an SPF specification. If it finds one, it will then check to see if the IP of the remote server matches any of the IP’s specified in the SPF record. If the remote server IP is contained in the SPF record, or if there was no SPF record present, it will proceed as normal, to the next step in the mail transfer process. If the remote server IP isn’t contained in the domain SPF record, then there are several possibilities. The server could proceed as normal and simply receive the mail message. Alternately, it could refuse the remote server there and not accept connections from it. Finally, it could also mark any mail messages received from that server as being suspect by adding an SPF header to the mail messages. Users’ mail clients could be configured to check for this special header and filter out this mail at the user’s choice.
Depending on the configuration of the server and acceptance of the connection with the remote server, the next step is to perform an SPF lookup on the “MAIL FROM” identity. This is the required check in order for a server to truly implement SPF. Normally, this would be the sender’s mailbox, where the local server would send notifications if there were problems in delivering the message. However, spam and phishing messages often change this field to impersonate servers that would otherwise be trusted. This check proceeds substantially as the HELO/EHLO check does.
Assuming the originating domain has a correct published SPF record, once the local mail server has completed the check of both the HELO/EHLO connect identity and the “MAIL FROM” identity, it should know definitively if the IP address is authorized to send mail from the domain.
More Web Hosting Articles Articles
More By Michael Swanson