The SPF "a" Mechanism Explained

When you're building an SPF record, you need to tell the world which servers are allowed to send email for your domain. The a mechanism, defined in RFC 7208, is one way to do that. It authorizes the IP addresses associated with a domain's DNS A record (or AAAA record for IPv6) to send email on your behalf.

This guide explains what the a mechanism does, when you should use it, and how it compares to the related mx mechanism.

What the "a" Mechanism Does

Every domain that hosts a website has at least one A record in DNS. This record points the domain name to an IP address, so when someone types your domain into a browser, their computer knows which server to connect to.

The a mechanism in SPF says: "The server at my domain's A record is also allowed to send email for this domain."

Here's what that looks like in practice:

v=spf1 a ~all

This record tells receiving mail servers: "Look up the A record for my domain. Whatever IP address you find there is authorized to send email for me. Anything else should softfail."

When a receiving server evaluates this record, it resolves your domain's A record to get the IP address (say, 203.0.113.10), then checks whether the email was sent from that IP. If it matches, SPF passes.

Syntax: With and Without a Domain Argument

The a mechanism can be used in two ways.

Without a domain argument

v=spf1 a ~all

When you write just a with no domain after it, SPF uses the domain being evaluated. If your SPF record is on example.com, then a means "look up the A record for example.com."

This is the most common usage. It's a shorthand that works well when your web server and mail server share the same IP address.

With a domain argument

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

You can also specify a different domain. Here, a:mail.example.com means "look up the A record for mail.example.com and authorize that IP." This is useful when you have a dedicated mail server on a subdomain.

You can even use CIDR notation to authorize a range of IP addresses:

v=spf1 a:mail.example.com/24 ~all

This authorizes the entire /24 subnet (256 addresses) around whatever IP mail.example.com resolves to. Use this carefully, as it can authorize more servers than you intend.

When to Use the "a" Mechanism

The a mechanism makes sense in a few specific scenarios:

Your web server sends email directly. If you run a web application that sends transactional emails (order confirmations, password resets, notifications) from the same server that hosts your website, the a mechanism authorizes that server. This is common with self-hosted applications, WordPress sites with SMTP plugins sending from the server itself, or custom applications on a VPS.

You have a dedicated mail server with an A record. If mail.yourdomain.com points to your mail server, a:mail.yourdomain.com authorizes it.

You want a simple record for a basic setup. For small businesses with a single server handling both web and email, a keeps the SPF record clean and easy to understand.

When NOT to Use the "a" Mechanism

The a mechanism is not always the right choice.

When you use a third-party email service. If you send email through Google Workspace, Microsoft 365, or SendGrid, their servers have their own IP addresses that have nothing to do with your domain's A record. Use include instead:

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

When your web server doesn't send email. If your website is on Squarespace, Wix, or behind a CDN like Cloudflare, the A record points to their infrastructure. Adding a would authorize those platforms to send email as you, which is not what you want.

When you want to authorize specific IPs. If you know the exact IP addresses, use ip4 or ip6 instead. They're more explicit and don't require DNS lookups.

The "a" Mechanism vs the "mx" Mechanism

The a and mx mechanisms are related but serve different purposes. They're often confused because both reference your domain's DNS records.

The mx mechanism authorizes the IP addresses of servers in your domain's MX records. The logic is: if a server receives your email, it's probably authorized to send it too (for auto-replies, bounces, etc.).

v=spf1 mx ~all

When to use mx over a: Use mx when your mail server is different from your web server and you want to authorize the mail server to send. Use a when you specifically want to authorize the web server. You can use both together:

v=spf1 a mx include:_spf.google.com ~all

Be mindful that each mechanism adds to your DNS lookup count.

Common Mistakes with the "a" Mechanism

Using a when you should use include. This is the most common mistake. If you use Google Workspace, adding a does nothing useful because Google's servers aren't at your domain's A record IP. You need include:_spf.google.com instead.

Authorizing a CDN by accident. If your A record points to Cloudflare or another CDN, the a mechanism authorizes their IPs. Those servers don't send email for you.

Forgetting that A records can change. If you move hosts, the a mechanism silently authorizes a different server.

Using a with CIDR on a shared host. Writing a/24 on shared hosting authorizes 256 IP addresses, many belonging to other customers.

Real-World Examples

Simple self-hosted setup where the web server also sends email:

v=spf1 a mx ~all

Web server plus Google Workspace -- only use a if your application sends email from the server:

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

Dedicated mail server on a subdomain with a transactional email provider:

v=spf1 a:mail.example.com include:sendgrid.net ~all

If you need help building a record, SPF Creator generates records with the correct syntax. To verify your existing record, use the checker above or run a full check at Deliverability Checker.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification, including the a mechanism definition
• RFC 7208, Section 4.6.4: DNS Lookup Limits — The 10 DNS lookup limit