Approve email senders with SPF

SPF helps inbox providers verify whether an email claiming to come from your domain is actually sent from a server you’ve approved.

Why SPF matters

Sending an email works a lot like sending physical mail. You can write any name and address you want on the envelope, even if it isn’t really yours. The “Envelope From” address in email works the same way: Anyone could send mail pretending to come from your domain.

SPF changes that by letting domain owners publish a list of servers that are allowed to send email for their domain. If a message comes from somewhere else, inbox providers treat these mismatches as a signal to be cautious.

How SPF works

An SPF record is a small note you add to your domain’s DNS that tells the world from what IP addresses servers are allowed to send email on behalf of your domain.

Here's an example: v=spf1 ip4:192.168.0.0/16 include:_spf.example.com ~all.

This record starts by identifying itself as an SPF record (v=spf1). It then says that mail is allowed if it comes from any IP address within 192.168.x.x (ip4:192.168.0.0/16) or from a server approved by another domain’s SPF record (include:_spf.example.com). Finally, it adds a rule (~all) to mark any other mail as suspicious. The exact SPF record to configure depends on your senders and their configuration.

When an inbox provider receives a message claiming to be from your domain, it looks up the list you’ve published from your SPF record using the domain in the Envelope From address. Then it checks if the sending server’s IP address is on the list.

If the address matches, the SPF check “passes,” signaling that the message likely came from a trusted source. If it doesn’t, the inbox provider may treat the message as less trustworthy.

Understanding the two “from” addresses

As with physical mail, an email carries two “from” addresses:

  • Envelope From is the address announced when one mail server delivers a message to another. In physical mail terms, it’s like the name and address written on the outside of the envelope, the one postal services use to return undeliverable mail. Email works the same way: The Envelope From is where delivery notifications and bounces are sent if a message can’t be delivered. You might also see it called Return-Path, MAIL FROM, RFC5321.MailFrom, or bounce address.
  • Header From is the address you see in your inbox, the one in the “From:” line of the message. It’s like the sender’s name printed on the letterhead inside the envelope. This is what people usually recognize as the “sender”. It’s also called RFC5322.From.

These two addresses don’t always match. Many email providers send messages on behalf of your domain (meaning with your domain in the Header From) but use their own domain in the Envelope From. To the recipient, it looks like the message came from your domain, while delivery notices and bounces go back to the provider.

Providers do this for practical reasons. Using their own domain in the Envelope From makes sending mail and receiving delivery notifications easier to manage on their side and removes extra setup steps for their customers.

Achieve DMARC compliance with SPF alignment

SPF only validates the domain in the Envelope From and checks it against the list of servers authorized to send on behalf of that domain. It doesn’t look at the Header From, the address that’s usually shown to the user.

This can be a problem. An attacker could send a message with an Envelope From domain they control, but use a different Header From address to impersonate someone else. Since the attacker’s domain authorizes their own servers, SPF would pass — even though the message appears to come from another domain. The user, however, only sees the spoofed Header From.

DMARC solves this by connecting the two “from” addresses through a concept called “alignment”. Alignment means the domains in the Envelope From and Header From must match before a message with a passing SPF result is considered DMARC compliant.

Resources