Skip to content
RocketLead Developers

SPF record patterns

SPF (Sender Policy Framework) lets the receiving mail server check that the sending IP is on the list of IPs authorized for the domain. It complements the DKIM CNAMEs (covered in SendGrid DNS) — without an SPF record, even properly DKIM-signed mail can land in spam.

There’s only ever one SPF record on a domain. If the customer already has an SPF record (because they send mail via Google Workspace, Microsoft 365, or another provider), you don’t add an SPF record — you merge SendGrid into the existing one.

Step 1 — Check for an existing SPF record

Section titled “Step 1 — Check for an existing SPF record”

Look up the domain’s TXT records. Either via the DNS provider’s UI or via dig TXT example.com. You’re looking for a record that starts with v=spf1. Examples:

Existing recordSource
(none)Domain isn’t yet sending mail from any authenticated service
v=spf1 include:_spf.google.com ~allGoogle Workspace
v=spf1 include:spf.protection.outlook.com ~allMicrosoft 365 / Exchange Online
v=spf1 include:_spf-strato.de ~allStrato mail hosting
v=spf1 include:mailgun.org ~allMailgun

The customer’s MX records also tell you what they use — if MX points at Strato, they’re using Strato mail, and that needs to stay in the SPF.

Step 2a — No existing record: create one

Section titled “Step 2a — No existing record: create one”

If no SPF record exists, create a new TXT record on the root of the domain:

TXT @  "v=spf1 include:sendgrid.net include:_spf-strato.de ~all"

Adjust the include: entries based on what the customer also sends from:

  • SendGrid (for RocketLead) → include:sendgrid.net
  • Strato → include:_spf-strato.de
  • Google Workspace → include:_spf.google.com
  • Microsoft 365 → include:spf.protection.outlook.com

The ~all at the end is a “soft fail” — mail from non-listed IPs is marked suspicious but not rejected. This is the recommended baseline. -all (hard fail) is stricter but riskier if you forget to include a sending service.

Step 2b — Existing record: merge SendGrid in

Section titled “Step 2b — Existing record: merge SendGrid in”

Edit the existing SPF record. Add include:sendgrid.net before the trailing ~all:

Before:

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

After:

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

Order doesn’t matter functionally. Keep all the existing include: and ip4: mechanisms intact — removing one will break whatever service that mechanism authorized.

include: vs. redirect:

Section titled “include: vs. redirect:”

You may see SPF examples using redirect=:

v=spf1 redirect=_spf.example.com

redirect= replaces the entire SPF policy with the one at the target. It’s used by hosting providers that maintain the policy on your behalf. Don’t combine redirect= with include: — you can have one or the other, not both.

If a domain uses redirect=, you can’t simply add include:sendgrid.net. You have two options:

  1. Look up what the redirect target resolves to, copy its mechanisms into a new root SPF record, and add SendGrid alongside. This breaks the redirect — the customer’s hosting provider can no longer manage the SPF on their behalf.
  2. Use the redirect target’s own SPF, if the provider supports custom additions. Strato supports adding to their SPF via the panel; check the provider.

include: is what you want in nearly every case.

Step 3 — Wait and verify

Section titled “Step 3 — Wait and verify”

After adding/editing the TXT record:

  • Wait for DNS propagation (5-30 min typically; can be longer).
  • Verify with dig TXT example.com or a public SPF-check tool.
  • Send a test email through RocketLead; check the email headers for spf=pass.

If you see spf=softfail or spf=neutral after a real send, the record isn’t picked up yet — wait longer.

Section titled “Recommended tooling”

For combining records or sanity-checking a complex SPF string, use ChatGPT or any SPF-record generator. Paste the existing record and ask “Add SendGrid to this SPF record”. The output is mechanical — easy to verify by eye.

Section titled “DMARC (optional but recommended)”

Once SPF and DKIM are in place, a DMARC record signals to receivers what to do with mail that fails authentication. The minimal DMARC record:

TXT _dmarc  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

This is monitoring-only (p=none). For stricter policies (p=quarantine, p=reject), make sure all the customer’s sending services are properly authenticated first — a strict DMARC policy will start rejecting legitimate mail otherwise.

What’s next

Section titled “What’s next”