Sender Policy Framework - SPF is an email authentication standard that allows a domain owner to authorize the use of its domain in email messages, with such authorization tied to the physical source of the message. And SPF macros give you more power and flexiblity when creating your SPF records.

This authorization is done by publishing a record in the DNS (Domain Name System). The record must follow a specific format, and most SPF records use various tags, called mechanisms, that explicitly list things such as IP addresses, networks, and hostnames.

Below, we’ll walk you through everything you need to know about SPF macros to take better control over your SPF records.

Further reading: SPF - Sender Policy Framework

What are SPF macros

The SPF standard also defines certain character sequences, referred to as macros, that are meant to be replaced by metadata from the individual message that requires SPF validation . Most SPF records are fairly straightforward, and the mechanisms mentioned above are enough for many domain owners to craft a record that properly authorizes the use of their domain.

However, there are cases where the record is complicated, perhaps due to its sheer size or other factors that just can’t be addressed by those mechanisms. In those situations, these SPF macros provide incredible power and flexibility in crafting SPF records.

SMTP Protocol

Simple Mail Transfer Protocol (SMTP) is the standard that describes the language used by two computer hosts that want to exchange an email message over the internet. SMTP declares the sending host in the SMTP transaction as the client, and the receiving host as the server.

As the name states, the protocol is simple, with only a handful of commands defined. A typical SMTP transaction looks like this:

• Client attempts to connect to server
• Server accepts the connection
• Client issues a greeting (literally EHLO or in some cases HELO) announcing its name
• Server issues a greeting in response
• Client describes the sender of the message using the command MAIL FROM
• Server accepts the sender
• Client describes one or more intended recipients of the message using the command RCPT TO
• Server accepts or rejects each recipient
• Client passes the full body of the message using the command DATA
• Transaction ends with the message accepted or rejected by server

Further reading: example of SMTP communication

Further reading: the difference between an email envelope and an email header

Types of Sender Policy Framework Macros

SPF macros are identified by unique single letters or characters enclosed in curly braces { } and preceded by a percent (%) symbol, signifying distinct components within your SPF record . These are the fundamental macros:

There are numerous additional macros that you can specify in your record, but we have listed some of the commonly used ones here.

How SPF macros work

First, we prepare a information from postfix smtp server log file for email from "support@purestorage.com"

4VpZHT1TxqzsRLp: client=smtp15-ia4-sp2.mta.salesforce.com[13.110.74.222]
4VpZHT1TxqzsRLp: from=<support@purestorage.com>, size=4167, nrcpt=1 (queue active)

• ip address sender's smtp server: 13.110.74.222
• helo/ehlo greeting: smtp15-ia4-sp2.mta.salesforce.com
• senders domain: purestorage.com

Let's look SPF record for domain purestorage.com with spf macro:

v=spf1 include:service-now.com include:purestorage.com._nspf.vali.email include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:stspg-customer.com ~all"

The record makes use of three SPF include directives, which are instructions to go look up the named record and include that lookup’s result in the expansion of this SPF record. The macros are in the second include directive:

include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email

There are three macros here and their meanings are:

• %{i} - The IP address of the client for the message (13.110.74.222)
• %{h} - The EHLO/HELO domain of the client for the message (salesforce.com)
• %{d} - The sender domain from the "MAIL FROM" command (purestorage.com)

The server receiving this message and attempting to validate the SPF record would attempt to look up the following DNS record:

13.110.74.222._ip.salesforce.com._ehlo.purestorage.com._spf.vali.email

first dns query

~] dig TXT 13.110.74.222._ip.salesforce.com._ehlo.purestorage.com._spf.vali.email
;; ANSWER SECTION:
13.110.74.222._ip.salesforce.com._ehlo.purestorage.com._spf.vali.email. 1018 IN TXT "v=spf1 include:_spf.salesforce.com -all"

second dns query

~] dig TXT _spf.salesforce.com
;; ANSWER SECTION:
_spf.salesforce.com.    3600    IN      TXT     "v=spf1 exists:%{i}._spf.mta.salesforce.com -all"

thrid dns query

~] dig A 13.110.74.222._spf.mta.salesforce.com
;; ANSWER SECTION:
13.110.74.222._spf.mta.salesforce.com. 86400 IN A 127.0.0.9

If the customer has properly configured SPF record, the query would yield a positive response indicating that the domain "purestorage.com" is authorized for mail sent from IP address "13.110.74.222".

Use Cases of Sender Policy Framework Macros

As per the expectations of domain owners from email security protocols , SPF macros can untangle an email authentication infrastructure and shorten down the SPF TXT record size. Here are some usual scenarios when macros are introduced in an SPF record:

1. Companies With a Multi-Domain Infrastructure

While SPF macros are especially well-suited for enterprise-level organizations managing multiple domains, they remain a valuable tool for organizations of any size. Macros offer significantly greater flexibility and enhance the efficiency of SPF records when compared to conventional flattening techniques. This ensures the smooth functioning of SPF even in complex multi-domain settings and eliminates the necessity to create multiple SPF records.

2. Large Email Infrastructures

Organizations dealing with intricate email systems may find it necessary to incorporate several SPF mechanisms, with the most efficient approach being the utilization of SPF macros. These macros enable the establishment of references to mechanisms, thereby preventing the SPF record from becoming excessively lengthy and keeping it within the RFC-prescribed limit of 512 octets.