SPF Macros Explained: Dynamic Variables in SPF Records

If you've been reading about SPF records, you might have come across something like %{i} or %{d} in an SPF record and wondered what those symbols mean. These are SPF macros — dynamic variables defined in RFC 7208 that get replaced with real values when a receiving server evaluates the record. They're a powerful feature, but they're also one of the least understood parts of SPF.

This guide explains what macros are, what each one does, when they're actually useful, and why most small businesses can safely ignore them. For a general overview of SPF, start with our complete SPF guide.

What Are SPF Macros?

A standard SPF record is static. It lists specific servers and domains that are allowed to send email for you, and that list is the same no matter who's sending or from where. Macros change that by inserting dynamic information into the SPF record at evaluation time.

When a receiving mail server checks your SPF record and encounters a macro, it replaces the macro variable with a real value from the email being evaluated — like the sender's IP address, the sending domain, or the local part of the email address.

For example, an SPF record containing %{i} would have that placeholder replaced with the actual IP address of the server sending the email. This lets you create SPF records that behave differently depending on the context of each individual email.

Available SPF Macros

RFC 7208 defines several macro variables, each representing a different piece of information about the email transaction. Here's what each one does:

Macros can also be modified with transformers. You can reverse the order of components using r (so %{ir} reverses the IP address octets), truncate with a number (like %{d2} to take only the last two parts of a domain), or change the delimiter. But these details matter mainly to engineers building complex mail systems.

How Macros Work in Practice

To understand macros, it helps to see how they're used. The most common real-world use of macros is with the exists mechanism, which checks whether a specific DNS A record exists.

Here's an example:

v=spf1 exists:%{i}._spf.example.com ~all

When a server at IP address 192.0.2.1 sends an email, the receiving server replaces %{i} with the actual IP and checks whether an A record exists for 192.0.2.1._spf.example.com. If that A record exists, SPF passes. If it doesn't, SPF moves on to the next mechanism (in this case, ~all).

This approach lets the domain owner authorize individual IP addresses by creating or removing A records, without ever changing the SPF record itself. For organizations managing hundreds of sending IPs, that's a real advantage.

Another common pattern uses the sender macro for per-user policies:

v=spf1 exists:%{l}._spf.example.com ~all

This checks for an A record based on the local part of the sender's address. So sales@example.com would trigger a lookup for sales._spf.example.com. This lets organizations define different sending rules for different mailboxes — though in practice, this is rarely worth the complexity.

When Macros Are Useful

Macros solve specific problems that most organizations never encounter. Here are the scenarios where they genuinely add value:

Large organizations with many sending IPs. If you have dozens or hundreds of servers sending email, maintaining a single SPF record with all their IP addresses is impractical (especially given the 10 DNS lookup limit). The exists mechanism with %{i} lets you authorize IPs through individual A records instead.

Email service providers. Companies that send email on behalf of many customers use macros to create a single SPF mechanism that works across thousands of domains. This is infrastructure-level work, not something most businesses need to configure.

Dynamic IP authorization. Some organizations need to authorize or revoke sending IPs frequently. Macros with the exists mechanism make this possible through simple A record changes rather than editing the SPF record each time.

Avoiding the 10-lookup limit. Because the exists mechanism only counts as one DNS lookup regardless of how many IPs you authorize through A records, macros can help organizations work within the lookup limit.

Why Most Small Businesses Don't Need Macros

For the vast majority of small and medium businesses, macros add complexity without meaningful benefit. Here's why:

Standard include statements handle most setups. If you use Google Workspace, Microsoft 365, Mailchimp, or any common email service, a simple include statement covers all their sending servers. You don't need to manage individual IPs.

Macros are hard to debug. When something goes wrong with a macro-based SPF record, figuring out the problem is significantly harder. The record itself doesn't show which IPs are authorized — you'd need to check the A records that the macro references. Standard SPF records are much more transparent.

Not all receivers handle macros well. While major email providers support macros correctly, some smaller mail servers or security appliances may not evaluate them properly. A straightforward SPF record is universally understood.

They increase DNS dependency. Macro-based records generate additional DNS queries during evaluation. If any of those queries fail or time out, SPF evaluation can fail too.

Checking Your SPF Record for Macros

If you've inherited a domain or are auditing an existing setup, it's worth checking whether your SPF record uses macros. Look for percent signs followed by curly braces (%{...}) in the record. Use the tool below to pull up your current SPF record and inspect it.

If your record does use macros and you're not sure why, it may have been set up by a previous administrator or an email provider. Before changing it, make sure you understand what the macros are doing — removing them without adding equivalent standard mechanisms could break your email authentication.

Macros and the Bigger Picture

SPF macros are just one piece of the email authentication puzzle. Regardless of whether your SPF record uses macros or standard mechanisms, you still need DKIM and DMARC for complete protection. Verify your DKIM setup with a DKIM checker and check your DMARC policy at DMARC Record Checker.

For a full overview of how SPF fits with DKIM and DMARC, read our guide on SPF, DKIM, and DMARC explained.

Monitor Your SPF Records

Whether your SPF record uses macros or straightforward includes, monitoring ensures it stays valid. DNS changes, provider updates, and accidental edits can all break your email authentication without warning.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification, including macro definitions and syntax