Guide to Sender Policy Framework


A Sender Policy Framework (SPF) is an email validation system. It allows receiving email servers to check that incoming mail from a domain is authorised by the sending domain’s administrators. In other words, an SPF verifies that the email you receive is from the sender and is genuine. Everlytic has a number of SPFs set up to ensure all sent emails are authentic.

This guide is to help you understand how SPFs work in email validation.

Why SPFs Are Important:

Technology is continuously exploited at various angles, but email is always a target. Emails are used for online correspondence, setting up accounts, and receiving important information. This is why email is the focus of cyber-attacks.

Spammers, phishers, and fraudsters attempt to steal or abuse valid email addresses and use them for their illicit activities. You, as the owner of the exploited email address, don’t realise your email address is being misused or stolen.

Spammers, specifically, will use your valid email address to send spam that is accepted by servers. Over time your email address will receive a bad sender reputation, causing all your valid emails to bounce.

How Does an SPF Help?

The Sender Policy Framework specifies which mail servers and domains are being used to send and receive emails. It is a two-way street between the domain owner, and the receiving server. For example: when sends an email to you, your server checks their domain. If the email’s domain (i.e. does not match the sender’s domain) it considers the email fake. The ISP then decides how best to deal with the email. It can either move to your inbox/spam folder anyway, or get bounced.

How Does an SPF Work?

There are technical terms we will need to clarify first before explaining how an SPF works.

Return-Path: This is also known as the envelope sender address. It is a hidden field with the sender’s actual email address. All bounced mails will be sent to this address.

It should end with the domain name of the sender. For example: might have the Return-Path When the Return-Path does not match the domain name, the SPF will think the email is forged.

SPFv1 or SPF Classic: This is the technical method or code, used to protect the Return-Path. It matches the domain name and the sender’s email address.

DNS zone: The Domain Name System (DNS) is a naming system for computers, services, or other resources connected to the Internet or a private network. The naming system is divided and distributed by hierarchical rank.

A record: This is the most basic type of DNS record. It is used to point a domain or subdomain to a specific IP address.

MX record: The mail exchanger record (MX record) is a record stored in the DNS. It specifies which mail server is responsible for accepting email messages on behalf of the recipient's domain.

The mail servers are prioritized by a preference value.

The DNS zone is an administrative tool used to collect all the records (such as domain servers) connected to the main domain. For example: might have the subdomain The DNS zone refers the sever to the correct domain.

The SPF uses all of these together to ensure the validity of an email.

The Process

The owner of the domain specifies which mail servers they use to send emails from. These are specified in an SPF record in their .domain’s DNS zone.

When they send an email, the receiving server checks the sender address, checks the domain, and verifies that the message does come from the specified domain. When domains don’t match, the receiving server checks the SPF records for matching domains specified in the DNS zone. If none match, it bounces the email.

Why it’s Important

Most mail servers do not check the From Address, but rather the Return-Path/Envelope From address. This means when sending an email, you can have different sending values. For example:

Return-Path/Envelope From:

From Address:

Reply Address:

In the example, Joe is the person sending the email. Since the Return-Path is hidden, the recipient doesn’t see this. The From address says the emails comes from Ben and when the recipient replies, their email will go to Replies.

This is how phishing works. Phishing is a way of stealing sensitive information such as usernames, banking details, passwords, etc., by sending an email that appears to be from someone you trust. This could be a bank, an online shop, or family.

SPF checks the Return-Path/Envelope From address and verifies it is from a legitimate sender. If not, it bounces the mail or sends it to your spam folder.

The SPF Record

The SPF record is published by the domain owner in the DNS zone. The example below is one way you can set your SPF records. Only the system administrator with access to the DNS zone will be able to publish an SPF record.

The SPF record may vary by use. The general code will look like this:

v=spf1 a mx ~all"

  • The initial part of the code refers to the version of the SPF. In this case, SPF1.

v=spf1 a mx ~all"

  • The second part points to the MX records of the domain authorized to send mail.

v=spf1 a mx ~all"

  • The third tells server that anything considered legitimate by will be legitimate for the domain.

v=spf1 a mx ~all"

  • The last part states that all other domains are not authorized.

v=spf1 a mx ~all

Everlytic’s SPF Compliancy

Everlytic ensures it is SPF compliant. Combined with various other techniques, the system works to safeguard recipients from receiving SPAM from us.

  1. Publish an SPF Policy: We have identified the domains authorised to send emails. The SPF record ensures that domains/IPs sending through the system are legitimate.
  2. Whitelisting: When an email is marked as spam often, the email address is added to a blacklist. All emails from that list get automatically marked as spam. Whitelisting is the opposite. These are approved email and IP addresses of safe senders.
  3. IP Check: Receiving servers discover and interpret the IP address of the sending machine. The server uses DNS queries to decide what happens to the received message.
  4. Sender Rewriting Scheme/Mail Transfer Agent:

Everlytic uses a MTA (Mail Transfer Agent) to send transactional mail. While the SPF does not allow email forwarding, we get around it using SRS (Sender Rewriting Scheme). SRS uses the Mail Transfer Agent to rewrite the sender address. This allows us to forward the mail without breaking SPF rules. For example:

Ben sends an email from a legitimate and approved domain but the email bounces. The SRS will change the Return-Path address. The rewritten Return-Path will still contain the original Return-Path. For example:



Mail From: <>


After SRS implementation:

Mail From: <>

This still allows Ben’s email to be forwarded. While it may look like it’s sending from a different email address, the SRS code will revert any replies back to the original sender’s address.

Here is what the code means:

  • SRS0 is a marker that verifies regular email addresses from rewritten addresses. The sending server will check that no email address begins with SRS0. If the message was already sent using SRS0, it will change it to SRS1 and apply everything else as is.

  • Yf09 is a hash-based message authentication code. Each domain will have its own hash system. The hash is authenticated by the domain generating it should the message bounce.

  • Cw is a time stamp which causes the email address to expire after a certain period of time. This also helps rid the SRS0 address from the system should another message need to be forwarded in the future.

While email exists, spam, phishing, and email fraud will always be a reality. Thankfully, most ISPs and mail hosts such as Gmail, Outlook, and Hotmail support SPF. Everlytic also implements SPF records and other methods to the domain, marking the sending servers as reputable. This way, less mail sent via the system is marked as spam, and mail deliverability is ensured.

Translate »