SPF (Sender Policy Framework) | Computing for Arts + Sciences

COVID-19—CAS's offices are closed on-campus, but we're open for business with some restrictions and working remotely to serve your academic IT needs.

Get IT help related to COVID-19 Access software for courses Use the computer labs remotely

UNT Banner

SPF (Sender Policy Framework)


Common Types of E-Mail Abuse where the Sender Address is Forged

Spammers want to avoid receiving non-delivery notifications (bounces) to their real addresses.

Fraudsters want to cover their tracks and remain anonymous.

Computer worms want to cause confusion or just don't care about which sender addresses they use.

Phishers (password fishers) want to impersonate well-known, trusted identities in order to steal passwords from users.

Sender Addresses in E-Mails

Like paper mail letters, e-mail messages have at least two kinds of sender addresses: one on the envelope and one in the letterhead.

The envelope sender address (sometimes also called the return-path) is used during the transport of the message from mail server to mail server, e.g. to return the message to the sender in the case of a delivery failure. It is usually not displayed to the user by mail programs.

The header sender address of an e-mail message is contained in the "From" or "Sender" header and is what is displayed to the user by mail programs. Generally, mail servers do not care about the header sender address when delivering a message.

The Problem: Sender Address Forgery

"Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or waste their time sorting out misdirected bounce messages." [1] This is typically the burden of the system administrators of the domain (ie: unt.edu), and is difficult to keep up with.

"You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.

Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.

But it does not have to be this way!" [1]

The Solution: SPF

"The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF -- called SPFv1 or SPF Classic -- protects the envelope sender address, which is used for the delivery of messages. See the box on the right for a quick explanation of the different types of sender addresses in e-mails.

(There are other solutions that protect the header sender address or that do not care at all about who sent the message, only who originally wrote it.)

Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.

Once you are confident about the authenticity of the sender address, you can finally "take it for real" and attach reputation to it. While IP-address-based reputation systems like Spamhaus or SpamCop have prevailed so far, reputation will increasingly be based on domains and even individual e-mail addresses in the future, too. Furthermore, additional kinds of policies are planned for a future version of SPF, such as asserting that all of a domain's outgoing mail is S/MIME or PGP signed." [1]

Receiver-side Checking

"The domain sender policies alone are not worth much -- it is the receiving mail servers that need to enforce them. Most mail servers support SPF checking either natively or through extensions. You can get community support." [1]

UNT's SPF Policy

UNT owns the domain unt.edu and untsystem.edu. (Note: As owners of the domain, UNT also own all sub-domains, such as: cas.unt.edu, jour.unt.edu, etc.) UNT decided to publish an SPF record in order to reduce the abuse of our domain in e-mail envelopes (We do not explore the configuration of untsystem.edu here, but you can o\n[2] TXT Info accurate as of: November 6, 2012

The parts of the SPF record mean the following:

[3] MX Info accurate as of: November 6, 2012

v=spf1 SPF version 1
mx the incoming mail exchangers/servers (MXs) of the domain are authorized to also send mail for unt.edu [3]
-all all other machines are not authorized

This doesn't mean we have one server handling all of the mail for the unt.edu domain. Mailhost is a cluster and load balanced for efficiency.


In layman terms, only our MXs (Mail Exchangers/Servers) [3] are allowed to send e-mail with an envelope sender address of @unt.edu. What this means for you is:

Configure Your Client

Unfortunately, there are hundreds of types of devices running dozens of mail clients around campus. This makes creating a one-stop shop for all your mail client configurations very difficult! We've summarized some key points here though and provided some links where you get more information.

You have two options for configuring how your mail client sends e-mail:

Alternatively, you can access your e-mail from home (off-campus) via webmail. If you're not able to find your answer in the links provided, contact our Help Desk. It's why we're here!

SPF Failures: Quarantined Messages

If your mail client is not configured correctly, you will get a message from Bahram P. (UNT's E-mail Gateway Manager) telling you that your e-mail has been quarantined:

*** Your email is being Quarantined and was not delivered to your recipients at unt.edu -- I strongly suggest that you contact your network manger ASAP to correct the problem -- I am not actively monitoring this any more and your contacts might lose your important E-mail ***

As of November 7th, you will get an e-mail from CAS IT Services when one or more of your e-mails are quarantined.

Quarantined is defined as: a state, period, or place of isolation in which people or animals that have been exposed to infectious or contagious disease are placed. What this means for your e-mail is: your e-mail is being held due to security violations in the way it was sent; it wasn't delivered or delivery was delayed significantly.

You got this message because one of your mail clients is configure incorrectly. Please check all of your mail clients and confirm the settings you are using are configured correctly. This means that when you send an e-mail with an @unt.edu envelope sender address, it must go through and Exchange connection or through mailhost.unt.edu (for SMTP connections). If you're sending e-mail with an @unt.edu envelope sender address, and you're using an SMTP server other than mailhost.unt.edu (ie: smtp.mail.yahoo.com, smtp.gmail.com, outgoing.verizon.net, smtp.sbcglobal.net, etc.), your e-mail will not always be delivered to recipients outside of UNT, and may never be delivered to recipients inside of UNT. Remember, SPF was implemented to protect you from the problem.


  1. OpenSPF - Introduction
  2. MXToolbox - SuperTool=spf:unt.edu
  3. MXToolbox - SuperTool=mx:unt.edu