what is an SPF record and why your AI agent's email depends on it

v=spf1 include:_spf.google.com include:sendgrid.net -all
Breaking that down:

- `v=spf1` declares the SPF version.
- `include:_spf.google.com` authorizes Google's mail servers to send on your behalf.
- `include:sendgrid.net` authorizes SendGrid's servers too.
- `-all` means "reject anything from a server not on this list." A softer `~all` means "mark it suspicious but don't outright reject."


That's it. No binary files, no certificates to rotate, no code to deploy. One DNS record. But getting it wrong has outsized consequences.

## Why agents make SPF harder

When a human sends email through Gmail or Outlook, SPF mostly takes care of itself. Google's servers are already authorized, and the human doesn't think about it. Agents break this pattern in a few ways.

**Agents send from infrastructure, not from inboxes.** A typical AI agent runs on a cloud server, a serverless function, or a container. If it connects directly to an SMTP relay or calls a transactional email API, the sending IP might not match anything in the domain's SPF record. The agent's email gets rejected, and the agent has no idea why. It just sees a `550` bounce and moves on (or worse, retries forever).

**Agents use multiple services.** One agent might send verification emails through one provider, notification emails through another, and outbound outreach through a third. Each provider needs its own `include:` entry in the SPF record. Miss one, and a subset of the agent's email silently fails.

**SPF has a 10-lookup limit.** Every `include:` in your SPF record triggers a DNS lookup. Nested includes count too. If your record requires more than 10 DNS lookups to fully resolve, it fails validation entirely, and receiving servers treat the result as a permanent error. Agents that pile on integrations can hit this limit without anyone noticing until deliverability craters.

**Agents don't check their own authentication.** A human who isn't receiving replies might investigate. An agent running a batch workflow might send 500 emails, get 500 bounces, and log them all as "delivery attempted." Without explicit error handling for SPF-related rejections, the problem compounds silently.

## Common SPF mistakes agents make

Beyond the structural issues above, there are several recurring errors that show up when engineering teams wire agents to send mail.

**Hardcoding IPs that change.** Cloud infrastructure rotates IP addresses. If your agent runs on ephemeral compute (Lambda, Cloud Run, Fly.io), the outbound IP may change on every deployment or cold start. Hardcoding those IPs into your SPF record is a losing game. Use your email provider's `include:` mechanism instead, which abstracts away the underlying IPs.

**Forgetting staging and development environments.** Many teams set up SPF correctly in production but overlook staging domains. Agents running in staging still send real emails to real inboxes. If the staging domain's SPF record is empty, those emails bounce, and the team assumes the agent code is broken when the problem is DNS.

**Sharing domains across teams without coordination.** If your agent team adds a new email provider but doesn't update the shared SPF record, the agent's mail fails while the marketing team's mail works fine. SPF records are domain-wide, so every team sending from the same domain needs to coordinate changes.

**Ignoring SPF alignment in forwarding scenarios.** When an email is forwarded, the original sending server's IP is no longer the one delivering the message. The forwarding server's IP gets checked against SPF, and it almost certainly isn't in your record. This is one reason DKIM matters so much as a complement to SPF; DKIM signatures survive forwarding, while SPF checks often don't.

## Setting up SPF for agent email

If you control the domain your agent sends from, you need to publish an SPF record that includes every server your agent uses to send mail. The process is straightforward, but the details matter.

### Step 1: identify all sending sources

List every service, server, or API that sends email on behalf of your domain. This includes transactional email providers (SendGrid, Postmark, Amazon SES), marketing platforms (Mailchimp, ConvertKit), your own mail server if you run one, and any agent infrastructure that connects to SMTP directly.

### Step 2: build the record

Combine them into a single TXT record. Each provider will give you a specific `include:` value in their documentation.

```dns
v=spf1 include:_spf.google.com include:amazonses.com include:sendgrid.net ~all
Use `~all` (softfail) during testing and switch to `-all` (hardfail) once you've confirmed everything works. The difference: softfail marks unauthorized senders as suspicious, hardfail tells receiving servers to reject them.

### Step 3: publish it in DNS

Add the record as a TXT entry on your domain's root (`@`). If you already have an SPF record, don't create a second one. Domains with multiple SPF records fail validation entirely. Merge everything into a single record.

### Step 4: validate

Use a tool like `dig` to confirm the record is published correctly:

```bash
dig +short TXT yourdomain.com | grep spf

You should see your complete SPF record. If you see two records, or none, something went wrong.

### Step 5: count your lookups

Check that your total DNS lookup count stays under 10. Tools like MXToolbox's SPF checker will show you the full lookup chain. If you're over the limit, you might need to flatten your record (replacing `include:` entries with the actual IP ranges they resolve to) or consolidate providers.

### Step 6: monitor ongoing deliverability

Setting up SPF is not a one-time task. Every time you add a new sending service, change cloud providers, or spin up a new agent workflow that sends email, you need to revisit the record. Set a reminder to audit your SPF record quarterly, or any time agent infrastructure changes. Pair this with DMARC aggregate reports (described below) to get automated visibility into authentication failures.

## SPF alone isn't enough

SPF verifies the sending server. It does not verify the content of the message, the From header the recipient sees, or whether the message was tampered with in transit. That's why SPF is one part of a three-layer authentication stack:

- **SPF** checks the sending server's IP against the domain's authorized list.
- **DKIM** (DomainKeys Identified Mail) adds a cryptographic signature to the message headers. The receiving server verifies it against a public key published in DNS. This proves the message wasn't altered after sending.
- **DMARC** (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together and tells receiving servers what to do when checks fail: nothing, quarantine, or reject.

For AI agents sending email at scale, all three matter. SPF without DKIM means messages can be modified in transit. SPF and DKIM without DMARC means you have no control over how failures are handled, and you get no visibility into who's sending email as your domain.

Since February 2024, Google and Yahoo require SPF, DKIM, and DMARC for anyone sending more than 5,000 messages per day. Even if your agent sends fewer, missing authentication increases the odds of landing in spam.

### Using DMARC reports to debug agent email

One underused feature of DMARC is its reporting mechanism. When you publish a DMARC record with a `rua` tag, receiving servers send you aggregate reports showing which IPs sent mail as your domain and whether those messages passed or failed SPF and DKIM. For agent builders, these reports are invaluable. They reveal unauthorized senders (someone spoofing your domain), misconfigured agents (a new service missing from SPF), and forwarding-related failures that need attention. You can use free tools like DMARC Analyzer or Postmark's DMARC monitoring to parse these XML reports into readable dashboards.

## The agent-first alternative

All of this assumes you're managing your own domain, your own DNS records, and your own sending infrastructure. That's fine if you already have the setup and the time to maintain it.

If you'd rather skip the DNS configuration entirely, [LobsterMail](/) gives agents email addresses that come pre-authenticated. SPF, DKIM, and DMARC are already configured on the `lobstermail.ai` domain. Your agent creates an inbox with a single function call and starts sending immediately, with no DNS records to publish and no authentication to debug.

LobsterMail's Free tier lets you test agent email workflows without any commitment. When you're ready to scale, the Builder tier at $9/mo gives you higher sending limits and more inboxes while keeping the same zero-configuration authentication.

## What to do right now

If your agent sends email from a custom domain, check your SPF record today. Run `dig +short TXT yourdomain.com | grep spf` and verify that every sending source is listed, you have only one SPF record, and your total lookup count is under 10. If any of those checks fail, fix it before your next batch goes out. Every email sent without proper SPF is an email that might never arrive.

<FAQ>
  <FAQItem question="What is an SPF record?">
    An SPF record is a DNS TXT record that lists the servers authorized to send email on behalf of a domain. Receiving mail servers check it to verify that incoming messages come from a legitimate source.
  </FAQItem>

  <FAQItem question="Do AI agents need SPF records to send email?">
    Yes, if the agent sends from a custom domain. Without a valid SPF record, most receiving servers will reject the email or route it to spam. Managed services like LobsterMail handle SPF automatically.
  </FAQItem>

  <FAQItem question="What happens if my SPF record is missing?">
    Receiving servers have no way to verify that your agent's email is legitimate. Depending on the server's policies and your DMARC settings, the message will either be rejected, quarantined, or flagged as suspicious.
  </FAQItem>

  <FAQItem question="Can I have multiple SPF records on one domain?">
    No. Publishing more than one SPF TXT record on the same domain causes validation to fail entirely. Merge all your authorized senders into a single record.
  </FAQItem>

  <FAQItem question="What is the 10 DNS lookup limit for SPF?">
    SPF records that require more than 10 DNS lookups to fully resolve are considered invalid. Each `include:`, `a:`, `mx:`, and `redirect:` mechanism counts as one lookup. Nested includes add to the total.
  </FAQItem>

  <FAQItem question="What's the difference between ~all and -all in SPF?">
    `~all` is a softfail: unauthorized senders are marked suspicious but not necessarily rejected. `-all` is a hardfail: unauthorized senders should be rejected. Use `~all` during setup and switch to `-all` once everything is confirmed working.
  </FAQItem>

  <FAQItem question="How do SPF, DKIM, and DMARC work together?">
    SPF checks the sending server, DKIM verifies the message wasn't altered in transit using a cryptographic signature, and DMARC tells receiving servers what to do when either check fails. All three are needed for reliable deliverability.
  </FAQItem>

  <FAQItem question="Does LobsterMail handle SPF configuration?">
    Yes. Inboxes on the `lobstermail.ai` domain come with SPF, DKIM, and DMARC pre-configured. Your agent doesn't need to touch DNS records at all.
  </FAQItem>

  <FAQItem question="How do I check my current SPF record?">
    Run `dig +short TXT yourdomain.com | grep spf` in a terminal. You should see a single record starting with `v=spf1` that lists all your authorized sending sources.
  </FAQItem>

  <FAQItem question="Why is my agent getting 550 bounces even with SPF configured?">
    The sending server's IP might not be covered by your SPF record, you might have multiple SPF records (which invalidates both), or your lookup count might exceed 10. Check all three. Our [550 error troubleshooting guide](/blog/550-email-rejected-how-to-fix-outbound-failures-from-your-agent) covers this in detail.
  </FAQItem>

  <FAQItem question="Can I use SPF with a free email address like Gmail?">
    You can't set SPF on domains you don't control. If your agent sends from a `@gmail.com` address, Google's SPF record applies and you have no way to modify it. For agents, using a domain you control or a managed service is the better path.
  </FAQItem>

  <FAQItem question="How often should I update my SPF record?">
    Every time you add or remove an email sending service. If your agent starts using a new transactional email provider and you forget to add it to SPF, those emails will fail authentication.
  </FAQItem>
</FAQ>