We receive hundreds of emails every day, donāt we? But how do we know that the corresponding sender sends the received email?
For example, you have received an email from Microsoft or Google. Are you sure that corresponding companies sent it?
SPF is one of the core email authentication methods to identify unauthorized email senders. In this way, you can determine if the email is a phishing or forged email.
Itās essential to understand the SPF email authentication method with all aspects and apply it correctly to your sender domains. Otherwise, you will have serious email deliverability problems.
What if you donāt set SPF email authentication for your sender domains?
Well, the recipient mail server will mostly reject your emails. Or even if they accept your emails, your emails will not be delivered to the inbox of recipients. Your email will go the spam folder of the recipient, or it will go the blackhole.
SPF is the acronym for the āSender Policy Framework.ā SPF is defined in RFC 7208.
SPF is a DNS record that is for sender domains. In this way, the sender domain defines authorized networks and hosts to send an email with the sender domain.
At the end of this post, you will have a detailed understanding of how to set SPF record for your sender domains, how to set your sender domains properly inside outgoing emails, and the importance hierarchy of domain names in outgoing emails.
SPF has no relationship to the email content. Receiving mail servers use the SPF email authentication method to validate if the path that email has arrived is appropriately authorized.
When the sender mail server initiates a connection to the recipient mail server (via SMTP protocol), the receiving mail server will validate the sending server for sender domains.
How do you set an SPF policy for your sender domain?
Setting up an SPF policy for your sender domain is pretty straight forward and takes only a few minutes. What you need is the SPF record to set and access to the sender domain DNS control panel.
Hereās an example SPF record for a sender domain:
"v=spf1 a mx include:test.com -all"
This SPF record gives the following message to the receiving mail server:
Check the A record of the sender domain, MX record of the sender domain, and SPF record of test.com to make sure that the sender IP address is authorized for sending an email for the sender domain. If the SPF check fails, reject the email.
Letās break down the SPF policy record into components and examine one by one:
-
"v=spf1": This is the beginning of an SPF policy record. Keep it as it is. This component declares that the DNS record is an SPF record. -
"ip4, ipv6": Specify authorized IP addresses and networks (CIDR) that are allowed to send emails for the sender domain. -
"a": Check the A record of the sender domain and compare it to the sender IP address. -
"mx": Check MX records of the sender domain and compare it to the sender IP address. -
"include": If youāre sending emails through a third party service (ex: Sendloop, Mailchimp, Sendgrid, etc.), you can inherit their mail server IP addresses. Be careful with this declare. More than ten include directives that will be rejected. -
"redirect": If you have multiple sender domains and want to setup SPF policy on one domain for easy maintenance, use this component to redirect SPF lookup to the target domain. -
"exists": Maximum 512 bytes for the DNS response. This can be used for lots of small and non-contiguous network blocks. -
"ptr": Do not use PTR. It exists in RFC specification but not honored anymore. -
"all": This component must be set as the last one in SPF policy records. It can be one of these;-
"-all": Reject all emails which donāt comply with the set SPF policy record. -
"~all": Emails that cannot be validated, soft fail, accept the email, but be careful. -
"?all": Use your own decision for SPF checked failed emails. -
"+all": Donāt check SPF, pass the email (this doesnāt guarantee success email delivery)
-
How does SPF authentication work?
When you create an email and hit the send button, your mail server (client) checks the MX record of the recipient domain to identify where the recipient mail server is. Once the recipient mail server is identified, it connects to it through SMTP protocol.
When the connection is made, the recipient mail server identifies the client-server IP address. Each server handshake and say hello to each other. This process includes the HELO hostname of the client-server.
Then the client-server initiates the MAIL FROM command and proceeds with the email delivery.
The receiving server can look up SPF record of;
- MAIL FROM domain
- HELO hostname
It can check one of these or both of them. The connecting IP address will be verified in the SPF record of these domains.
Based on the check result, the recipient mail server will determine to reject the message, send it to blackhole or delivery to the mailbox of the recipient.
What domain to check?
MAIL FROM domain and HELO hostname are two valuable domains when it comes to SPF check. But we strongly recommend the SENDER/FROM domain to comply with the SPF check as well.
- HELO hostname
- MAIL FROM domain
- SENDER domain (if it exists)
- FROM domain
Some SPF record examples
v=spf1 mx ipv4:10.10.10.10/29 ~all
Check the MX record, /29 IP block and soft fail everything else
v=spf1 a ipv4:10.10.10.10/31 -all
Check the A record, /31 IP block, reject everything else
v=spf1 -all
The domain doesnāt send any emails. Reject all emails with this domain.
v=spf1 +all
Donāt check SPF for this domain.
v=spf1 redirect:spf.anotherdomain.com
Check the SPF record of another domain.
SPF is only the beginning
SPF is straightforward to set up an email authentication mechanism, but itās enough alone. Time to time, itās vulnerable to failure and may cause false negatives.
SPF is the first email authentication scheme to achieve, but itās just the beginning. In addition to SPF email authentication, you must also set up DKIM and DMARC authentication mechanisms too.
- The article was helpful
- The article was not helpful
0 voters