SendGrid SPF: do you need include:sendgrid.net?

Run the free SPF checker →This article is a how-to. The matching tool checks a live domain.

include:sendgrid.net turns up in apex SPF records all over MSP client bases, often added years ago "because SendGrid said so." Twilio's current documentation describes two setups, and in the default one you don't edit the apex SPF record at all. Knowing which one a client uses tells you whether the include belongs there, belongs on a subdomain, or is just costing a DNS lookup.

Two modes: automated security on or off

SendGrid's domain authentication has a setting called Use automated security. Twilio's documentation says it's on by default, and the DNS records you publish depend on it.

Automated security ON (default). You publish three CNAME records, and Twilio manages SPF and DKIM behind them:

TypeHostValue
CNAMEem1234.client.comu1234567.wl123.sendgrid.net
CNAMEs1._domainkey.client.coms1.domainkey.u1234567.wl123.sendgrid.net
CNAMEs2._domainkey.client.coms2.domainkey.u1234567.wl123.sendgrid.net

The numbers are placeholders, and SendGrid generates the real values per account. The first CNAME creates a return-path subdomain (em1234.client.com) that SendGrid uses as the envelope sender. SPF is evaluated against that subdomain, and Twilio maintains the record it resolves to. Twilio's docs say that in this mode, dedicated IPs you add are picked up automatically, so you don't have to edit the record.

Automated security OFF. You publish the records yourself:

TypeHostValue
MXem1234.client.commx.sendgrid.net
TXTem1234.client.comv=spf1 include:sendgrid.net ~all
TXTm1._domainkey.client.comthe DKIM public key SendGrid shows

Even here, the SPF record with include:sendgrid.net sits on the return-path subdomain, not on the apex. Twilio notes that with automated security off, you have to update these records yourself when the configuration changes, such as when you add a dedicated IP.

In both modes, SendGrid's example also shows a DMARC TXT record at _dmarc.client.com. If the client already has a DMARC record, don't publish a second one. Keep the existing record and review it.

Why the apex include is usually unnecessary

SPF checks the envelope sender (the RFC 5321 MAIL FROM, which shows up as Return-Path), not the From: header the recipient sees. With domain authentication set up, SendGrid's envelope sender is the em subdomain, so receivers evaluate the SPF record on em1234.client.com. The apex record isn't consulted for that mail, so an include:sendgrid.net there doesn't help those messages pass.

Before you remove an old apex include, confirm nothing else depends on it. An app that relays through SendGrid without domain authentication would be one example. The DMARC aggregate reports for the domain show which envelope domains SendGrid traffic actually uses.

How SendGrid mail aligns for DMARC

Under RFC 9989, a message passes DMARC if SPF or DKIM passes and the authenticated domain aligns with the From: domain. Relaxed alignment is the default, and it only requires the same Organizational Domain.

  • SPF route: em1234.client.com and client.com share an Organizational Domain, so an SPF pass on the return-path subdomain aligns under relaxed alignment. It won't align if the client's DMARC record sets aspf=s.
  • DKIM route: The s1/s2 (or m1) signatures use the client's domain, so they align with From: as well.

Domain authentication gives you both. That matters because RFC 9989 says a domain publishing p=reject must not rely on SPF alone for a DMARC pass and must sign with DKIM. Forwarding commonly breaks SPF and usually leaves DKIM intact.

How to tell which mode a client is in

You can usually work it out from public DNS without logging into the client's SendGrid account:

  • The em host is a CNAME to something under sendgrid.net: automated security is on. SPF and DKIM sit behind Twilio's records, and you don't maintain an include.
  • The em host has an MX of mx.sendgrid.net and a TXT starting v=spf1 include:sendgrid.net: automated security is off. That TXT record is yours to maintain.
  • There's no em-style host at all, only an apex include: the domain probably isn't authenticated in SendGrid. Mail may still show "via sendgrid.net" and rely on SendGrid's own domain. Twilio lists removing that tagline as one of the benefits of domain authentication.

Host names vary by account, so get the exact names from the client's SendGrid settings (or their developer) before you change anything.

Lookup cost of include:sendgrid.net

On Oct 13, 2026, a live DNS check of sendgrid.net showed ip4 ranges plus one nested include (ab.sendgrid.net), so the include costs two lookups toward the RFC 7208 limit of 10. In automated-security mode the CNAME target's record is Twilio's to manage, and the cost can change. These are observations, not documented values. Run the client's actual return-path host through the checker.

Common SendGrid mistakes

  • Adding a second SPF record at the apex for SendGrid. Two v=spf1 records are a permerror under RFC 7208 §4.5, which breaks SPF for every sender on that domain.
  • Editing the wrong host. The SendGrid records go on the exact host names SendGrid shows. Some DNS panels append the zone name automatically, so em1234.client.com turns into em1234.client.com.client.com. Check the record after you save it.
  • Mixing modes. Leftover manual TXT records on the em host alongside a new CNAME won't work, because a name with a CNAME can't carry other records.
  • Forgetting dedicated IPs with automated security off. The TXT record has to be updated by hand.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10, names common senders such as SendGrid, and flags duplicate records and +all or ?all endings.

Founding Partner: $1,999, one time. Catch the stale vendor includes and duplicate SPF records across every client domain without opening each DNS console. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →

FAQ

Is include:sendgrid.net still needed in my SPF record?
Not on the apex for authenticated SendGrid domains. With automated security on (the default), SPF is handled by the return-path CNAME. With it off, Twilio's documented v=spf1 include:sendgrid.net ~all goes on the return-path subdomain.
What is the em subdomain SendGrid asks for?
It's the return-path (envelope sender) subdomain, such as em1234.client.com. Bounces route there, and SPF is evaluated against it.
Does SendGrid mail pass DMARC with relaxed alignment?
Yes, if domain authentication is set up. The return-path subdomain aligns with the From: domain under relaxed SPF alignment, and the DKIM signatures use the client's domain.
What breaks if the client's DMARC uses aspf=s?
SPF alignment, because the envelope domain is a subdomain rather than an exact match. DKIM can still align, so DMARC can still pass through DKIM.
Do I need to update SPF when I add a SendGrid dedicated IP?
With automated security on, Twilio says it adds the IPs for you. With it off, you update the TXT record yourself.
Can I remove an old include:sendgrid.net from the apex?
Usually yes, once DMARC aggregate reports confirm that no SendGrid mail uses the apex as its envelope domain. Check before you remove it.
SendGrid SPF Include: Automated Security vs Manual Setup | Client Posture