Last updated: July 2026

In short: The a and mx mechanisms in an SPF record dynamically authorize sending servers by comparing their IP addresses against your domain’s existing DNS A, AAAA, and MX records.

When a mail server receives an incoming email, Sender Policy Framework (SPF) evaluates whether the connecting host’s IP address is authorized to send on behalf of the domain. Instead of hardcoding every static IP address directly into your record, you can use the a and mx mechanisms to reference the DNS records published for your web and mail infrastructure.

How the a mechanism works

The a mechanism verifies whether the connecting mail server is running on the primary IP address of your website or a specified hostname. Under RFC 7208, this mechanism matches if <ip> is one of the <target-name>’s IP addresses. For clarity, the standard explicitly notes that the a mechanism also matches AAAA records (IPv6 addresses).

When published by itself without an argument, it evaluates against the queried domain name:

v=spf1 a mx ~all

You can also point the mechanism to a specific subdomain or server hostname:

v=spf1 a:mail.example.com -all

If your web application, WordPress site, or CRM sends order confirmations and system alerts directly from your web server’s primary IP address, the a mechanism ensures that host passes authentication.

How the mx mechanism works

The mx mechanism authorizes your domain’s receiving mail servers to send outgoing email as well. Under RFC 7208, this mechanism matches if <ip> is one of the MX hosts for a domain name:

v=spf1 mx -all

During evaluation, the receiving server queries your domain’s MX records, resolves those target hostnames into IP addresses, and checks whether the connecting server matches any of them. This is widely used across shared hosting environments and traditional mail setups where inbound and outbound mail travel through the same server cluster.

DNS lookups and performance

While a and mx provide convenience by automatically adapting when you migrate servers or update your DNS records, they incur a performance cost: they trigger DNS queries during evaluation.

RFC 7208 establishes that terms causing DNS queries at evaluation time (include, a, mx, ptr, exists, and redirect) must be strictly limited. SPF implementations must limit the total number of those terms to 10 lookups during evaluation to prevent excessive load on the Domain Name System. If an evaluation exceeds this threshold, the receiving server aborts processing and returns permerror (permanent error).

A basic v=spf1 a mx ~all record immediately consumes two lookups (one for the A/AAAA query and one for the MX query). If your MX records point to multiple hostnames that each require resolution, the lookup count grows further. For static, long-term server IP addresses, direct ip4 or ip6 mechanisms are more efficient because they do not cause DNS lookups. Additionally, a domain must not publish multiple separate SPF records, which would also cause an immediate permerror.

Verifying your configuration

To check how many DNS lookups your a, mx, and include mechanisms consume in total, analyze your domain with the free MXAudit scanner. It reveals the exact query chain and confirms that all hostnames resolve cleanly.

To learn more about structuring your authentication stack or setting up provider-specific records, explore the SPF hub and practical guides like IONOS SPF setup.

Further reading