Skip to main content

What Are Sender Policy Framework Records? What to Know About SPF

Creating an SPF record provides your email recipients with a tool to verify whether or not a sender is cleared to send an email in your name.

A sender policy framework (SPF) functions like an event guard stationed in your lobby. You provide a guest list, and the guard welcomes those with names on the list while everyone else waits for approval or gets turned away. For example, a small business owner usually knows customers and suppliers by name, and you've seen their company logos, personnel, and other identifiers. However, email exchanges lack those visual cues of legitimacy.

The VP of Marketing for a medium-sized company may only know a handful of customers and suppliers by sight. So instead, the VP relies on a receptionist to screen calls and visitors, only allowing those whose concerns cannot be delegated to junior staff members to speak directly.

In contrast, the CEO or owner of an international import/export company might only speak to someone scheduled well in advance. Moreover, anyone permitted to have an appointment must also have a concern vital to the entire company that only the CEO can handle, such as a VIP customer with a complicated contract.

In each of these situations, businesses must have some way to distinguish the genuine sender. Otherwise, your company could suffer a significant loss of reputation if a spammer, scammer, or bot impersonated you and gained access to your customer list or email server. Your sender policy framework provides that distinguishing factor.

Learn more about SPFs, including answers to your questions such as "What is a SPF record" and "how do you create an SPF record?", so you can leverage this security measure for your own company.

What Are Sender Policy Framework Records?

A sender policy framework record, or SPF, is a line of computer code that tells your email recipients that your message originated from you, your company, or an authorized email distributor working on your behalf. An SPF record provides the instructions a message recipient can use:

  • to identify the sender of a message,
  • to verify that the sender has the authority to send emails from your company,
  • as a possible return route to the message source if they have objections to your use of their data
Illustration of an envelope with text below it that reads, “A SPF record ensures that only authenticated emails are sent on your business's behalf.”

Limitations of SPF: What SPF Can't Do

Now that we've answered "what is an SPF record?", we should discuss what sender policy framework records cannot do. SPF authentication provides the bare minimum of safety for your email campaigns.

Some of the limitations to consider include:

  • SPF does not encrypt messages.
  • These frameworks do not provide any privacy enhancements.
  • Forwarding an email breaks the SPF because the forwarder becomes the new sender.
  • An SPF does not generate reports.
  • SPF alone does not provide enough protection.

What Do You Need to Know About SPF?

Using sender policy framework records tells your recipient that your message is not spoofing, spamming, or attempting to scam them. Every company faces challenges when establishing trust. When you increase confidence through this verification process, you decrease resistance to your message. Using SPF also helps improve cybersecurity for the recipient.

Here are some important things to note about SPFs:

  1. An (SPF) sender policy framework is a list of IP addresses and instructions for internet service providers to follow when handling your outgoing email.
  2. Your SPF provides a layer of protection that makes your messages more likely to reach the intended receiver.
  3. An SPF email record does not encrypt your messages.
  4. SPF records appear in the full headers of your message.
  5. The SPF domain listed first in the "include" mechanism demonstrates that you have taken at least some minimum precautions to protect your personal and business data.

SPF vs. DMARC vs. DKIM

The Internet Engineering Task Force published the current SPF protocol in RFC 7208 in April 2014. The purpose was to create a consensus on keeping hackers and phishers from sending emails that supposedly come from a known, trusted organization. That consensus became spf1, and from that point forward, v=spf1 became the standard format for the beginning statement of every SPF record. However, forwarding a message invalidates the SPF. Consequently, two additional strategies have come into play: DKIM and DMARC.

What Is DKIM?

DKIM is an acronym for DomainKeys Identified Mail. Like SPF, DKIM is a TXT record in the DNS. However, DKIM records remain valid even when forwarded. Current DKIM standards arose from efforts by Yahoo! and Cisco, who had each created their email authorization standards. Think of DKIM as the wax seal once applied to official documents. These wax seals were recognizable; if a message arrived with a missing or broken seal, it was not considered trustworthy.

Every dispatching email server has a two-part DKIM: the private DKIM key and a public key. Every receiving server accesses the public half of that key. The receiving email server performs a lookup in the DNS when you send your email message. If that email server finds your public DKIM key, it opens the DKIM signature. If the signature in the message matches the signature you published in your DNS, the receiving email server considers that message valid. If not, that message bounces, which means it does not reach the intended receiver's inbox. Instead, it might not get delivered, go to the spam folder, or go to whatever other folder the user has set up to deal with such messages.

The correct format for DKIM records looks like this:

<selector(s=)._domainkey.domain(d=)>.   TXT v=DKIM1; p=\<public key>

Here is a sample DKIM public key in the correct format: 

dk5182-3458._domainkey.mydomainexample.com. IN TXT "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;"

What Does Each Part of a DKIM Record Do?

In this example, dk5182-3458 represents the selector (s=). The (d=) represents the specified domain, mydomainexample.com. The version must always appear as "v=DKIM1'' in every DKIM record. The "p" mechanism represents the public code, a string of letters, numbers, and symbols.

What Is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. DMARC prevents malicious activity by blocking messages from spoofers before they reach your inbox. Spoofers pretend to represent you to glean the information they can use for ID theft or other types of fraud.

When you use DMARC, you slam the door shut on these attempted intrusions. DMARC uses open-source, free-to-use code. However, your email service provider must also use DMARC protection. DMARC provides a third layer of protection after SPF and DKIM.

DMARC allows you to tell your email service provider whether to reject or quarantine emails from untrustworthy or unknown sources based on information received after DKIM and SPF queries.

Illustration of a thumb’s up with text that reads, “Benefits of SPF Records: Increased domain reputation; Increased email deliverability; Decreased spoofing and phishing”.

SPF Record Parts

A correctly formatted SPF record is a text file (TXT) containing two vital elements. First, the record must include the SPF version. Second, the rest of the record consists of the mechanisms required to verify which host names and IP addresses are authorized to send messages from your domain.

An example of an SPF record in an email authentication statement might look like this:

"v=spf1 a MX include:spf.yourbusinessdomainname.com ~all"

The v=spf1 statement tells the receiving email server that this TXT record is a sender policy framework record. The "a'' mechanism tells that server to match the sender's IP address to the "a" tool of the "from" domain before allowing the entire message to download. The MX mechanism refers to the mail exchange server or "host" you use to store your email messages, such as Google Workspace or Microsoft 365 Business Premium. Finally, the "include" mechanism specifies that the example SPF domain, yourbusinessdomainname.com, has the right to send your company's emails.

Important points to remember:

  • The statement v=spf1 is the first tag and must ALWAYS appear at the beginning of your SPF record.
  • The "a" statement must match the "from" record.
  • Your MX is the mail exchange service you use.
  • Every domain authorized to send your business emails must appear in the "include" statement, including any third-party email services, such as Mailchimp, that you use.
  • Include every IP address your company email comes from in your SPF mechanism.
Image of the word “all” inside a circle with text below it that reads, “Using "all" at the end of your SPF record ensures all incoming messages match the domain.”

How to Create an SPF Record

For best results, create your SPF record syntax as a TXT file before you upload it, rather than creating it on your DNS server's dashboard. That way, you can scrutinize it for format errors before testing it.

Follow these steps to create and implement your SPF record:

  1. First, open your domain provider's dashboard.
  2. Go to Settings.
  3. Create your SPF record as a TXT entry
  4. Add it to your DNS settings.
  5. Test the changes.

Any changes to your existing SPF record may take up to 48 hours, so be patient. Then, test your changes again after those two days have passed.

If you only send email from Google Workspace, for example, your SPF record would look like this:

"v=spf1 include:_spf.google.com ~all"

However, if you have additional email service providers, you always need a separate "include:" statement for each one. Consequently, if you also use Mailchimp's Mandrill to send messages, you add "include:mandrillapp.com" after the Google statement and before the ~all element. Thus, your new SPF will look like this:

"v=spf1 include:_spf.google.com include:mandrillapp.com ~all"

Here, you would replace "domainkey.example.com" with your company's domain name.

Protect Your Business with SPF Records

Bad actors such as disgruntled or former employees, spammers, and scammers can ruin your company's reputation by sending fake emails from your company if you do not take steps to secure your communications. SPF authentication gives your customers and contacts a way to verify that a message came from you. While it does not encrypt the message's contents, SPF provides the first line of defense against spoofers. For total security against cyber attacks via email, you should also use DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance).

If you find creating and adding SPF records to your DNS burdensome to do yourself, you can rely on Mailchimp to set up and test your SPF authentication and domain authentication for you.

Laptop screen showcasing 'Unlocking Advanced Email Marketing' Checklist

Get Mailchimp's guide for advanced email marketing

Grow your business with the right knowledge and strategies to improve your emails, capture the attention of audiences, and turn leads into loyal customers.

Fill out the form below to receive the one‑pager

Share This Article