Do I need to add include:sendgrid.net to my SPF record?

Not with the recommended setup. When Automated Security is on, SendGrid authenticates SPF through the em CNAME on your sending subdomain, so you leave your root SPF alone. You only add v=spf1 include:sendgrid.net ~all if you deliberately turn Automated Security off and use the manual TXT-record path.

Why do my emails still say “via sendgrid.net” or “sent on behalf of”?

That means you’re only using a verified Single Sender, not domain authentication. Run Settings → Sender Authentication → Authenticate Your Domain and add the CNAMEs; once the domain is verified the via/on-behalf-of tag goes away.

The wizard wants to send from a subdomain like em1234 — can I use my bare root domain instead?

SendGrid always provisions a sending/Return-Path subdomain (that’s what the em CNAME is). Your visible From address can still be you@yourdomain.com; DMARC passes because relaxed SPF alignment matches the em subdomain to your organizational domain.

Will SendGrid’s records conflict with Google Workspace, Microsoft 365, or another sender I already use?

No. SendGrid uses CNAMEs on its own subdomain and its own s1/s2 DKIM selectors, so it won’t overwrite your existing DKIM or your root SPF. The only rule: keep a single SPF TXT record on your root — never publish two.

I bought a dedicated IP. Do I have to change DNS?

With Automated Security on, no — SendGrid updates the SPF/IP behind your CNAMEs for you. If you’re on the manual (Automated Security off) path, you may need to add the dedicated IP as an ip4: mechanism to your SPF TXT record yourself.

Do I add these as CNAME or TXT records?

CNAME — all of the domain-authentication records (em, s1._domainkey, s2._domainkey, and any link-branding hosts) are CNAMEs. Only the DMARC record is a TXT record, and it’s separate.

SPF setup guide

SPF, DKIM & DMARC for SendGrid.

SendGrid (now Twilio SendGrid) authenticates your domain through its Sender Authentication wizard, not by having you paste a shared SPF line. The recommended “Authenticate Your Domain” flow generates three CNAME records on a dedicated sending subdomain that delegate SPF and rotating DKIM keys back to SendGrid. Once those CNAMEs verify, SendGrid can send as your domain, the “via sendgrid.net” tag disappears, and you never have to touch the underlying SPF/IP values again.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

SendGridSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate SendGrid?

Authenticating your domain in SendGrid isn’t housekeeping — it decides whether your mail reaches the inbox at all. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began rejecting non-compliant mail in 2025. Until you authenticate, SendGrid sends on its own shared domain: recipients see a “via sendgrid.net” note, your From address doesn’t align, DMARC can’t pass, and your reputation is pooled with every other unauthenticated sender on that infrastructure. Domain authentication fixes all of it in one move — SPF and DKIM both align to your domain, the “via” tag disappears, DMARC passes, and the sending reputation you build accrues to your own domain instead of the shared pool.

The SPF reality for SendGrid

SendGrid is a CNAME-based domain-authentication provider, so for most people there is NO “include:sendgrid.net” to add. When you run Authenticate Your Domain with Automated Security left on (the default), SendGrid creates a branded sending subdomain (something like em1234.yourdomain.com) as a CNAME pointing into sendgrid.net. That subdomain becomes your Return-Path/bounce domain, and because the CNAME resolves into SendGrid’s own SPF-authorized space, SPF is satisfied there automatically — you do not publish include:sendgrid.net on your root domain, and DMARC still passes via relaxed SPF alignment (the em subdomain aligns with your organizational domain). The classic shared include only comes into play on the legacy path: if you switch Automated Security OFF, SendGrid instead hands you TXT records, and that is where you would add v=spf1 include:sendgrid.net ~all. Bottom line: the modern, recommended SendGrid setup is CNAME domain authentication with no shared SPF include; the include:sendgrid.net mechanism still exists but is the older, manual alternative.

Two ways to set it up

Recommended

Automated Security — CNAME (recommended)

SendGrid manages SPF and rotates your DKIM keys automatically via CNAMEs
Adds zero DNS lookups to your root SPF — there’s nothing to merge
Keys rotate on their own; you never re-edit DNS again
Dedicated-IP and infrastructure changes are handled for you

Legacy

Manual — include:sendgrid.net (legacy)

You add v=spf1 include:sendgrid.net ~all to your root SPF yourself
Costs one of your 10 SPF DNS lookups
DKIM becomes a static TXT record with no automatic key rotation
Only worth it if you specifically need self-managed, static records

Step by step

In SendGrid

1
Open Sender Authentication
Log in at app.sendgrid.com and go to Settings → Sender Authentication in the left-hand menu.
2
Start domain authentication
In the Domain Authentication section (“Authenticate Your Domain”), click Get Started.
3
Pick your DNS host
Choose your DNS host from the “Which DNS host do you use?” dropdown (Cloudflare, GoDaddy, Namecheap…). It only tailors the on-screen instructions — pick “Other Host / Not Listed” if yours isn’t there.
4
Brand your links
Answer “Would you also like to brand the links for this domain?” with Yes, so click-tracked links use your domain instead of sendgrid.net (this adds a couple more CNAMEs).
5
Keep Automated Security on
Open Advanced Settings and leave “Use automated security” checked — this lets SendGrid manage SPF and rotate DKIM via CNAMEs so you never re-edit DNS. Optionally set a custom sending subdomain; otherwise SendGrid assigns one like em1234.
6
Enter your sending domain
Under “Domain You Send From”, enter yourdomain.com (SendGrid derives the sending subdomain from it) and click Next.

In your DNS

7
Add the CNAME records
SendGrid shows the records to add. Create each as a CNAME: Host = the subdomain SendGrid lists (em1234, s1._domainkey, s2._domainkey, plus the url/link-branding hosts if enabled), Value = the matching *.sendgrid.net hostname. Don’t change the type to A or TXT.
8
Turn off the Cloudflare proxy
If your DNS is behind Cloudflare, set each record to “DNS only” (grey cloud) — an orange-cloud proxy breaks CNAME resolution and verification fails.

Verify

9
Click Verify
Back on SendGrid’s Sender Authentication page, click Verify. Propagation is usually minutes but can take up to 48 hours; the domain shows Verified once all CNAMEs resolve.
10
Send from the authenticated domain
In your app or SMTP settings, send from an address on the authenticated domain (e.g. no-reply@yourdomain.com) so mail actually uses the authenticated sending subdomain.

Records to add

SendGrid generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	em1234	u1234567.wl123.sendgrid.netSending subdomain (Return-Path) — this is what satisfies SPF
CNAME	s1._domainkey	s1.domainkey.u1234567.wl123.sendgrid.netDKIM key 1 (auto-rotated)
CNAME	s2._domainkey	s2.domainkey.u1234567.wl123.sendgrid.netDKIM key 2 (auto-rotated)
CNAME	url1234	sendgrid.netLink branding (optional)
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — one per domain

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what SendGrid's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

SendGrid's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is handled automatically by two of the CNAME records SendGrid creates: s1._domainkey.yourdomain.com and s2._domainkey.yourdomain.com, each pointing to s1.domainkey.uXXXXXX.wlYYY.sendgrid.net and s2.domainkey.uXXXXXX.wlYYY.sendgrid.net respectively (the uXXXXXX/wlYYY parts are unique to your account). Because these are CNAMEs delegated to SendGrid — not TXT records you paste — SendGrid holds the private keys and can rotate the published DKIM keys behind those two selectors without you ever editing DNS again. You do not create a DKIM TXT record yourself and there is no key to copy. Just add the two s1._domainkey / s2._domainkey CNAMEs exactly as shown (grey-cloud/DNS-only if on Cloudflare) and click Verify.

DMARC

DMARC is a separate policy record on your root domain, not one of the CNAMEs, though SendGrid’s flow prompts you to add it. Publish a TXT record at _dmarc.yourdomain.com beginning with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — p=none is monitor-only, so it won’t affect delivery while you confirm SendGrid mail passes SPF and DKIM aligned to your domain. Watch the aggregate (rua) reports for a week or two, then tighten to p=quarantine and eventually p=reject once alignment is consistent. Keep just one _dmarc record for the whole domain no matter how many senders you use — don’t add a second one for SendGrid.

Check it actually worked

Don’t trust the dashboard’s “Verified” badge alone — confirm it on a real message. Send yourself a test from an address on the authenticated domain, open it in Gmail, and choose ⋮ → Show original: you want SPF: PASS and DKIM: PASS both showing your domain (not sendgrid.net), plus DMARC: PASS. Prefer a report? Send a test to check-auth@verifier.port25.com and it emails back a full breakdown. You can also run your domain through Qualisend’s domain health check to confirm every record resolves, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — SendGrid should show up as an aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

DNS setup
Cloudflare proxy breaks it: set every SendGrid CNAME to “DNS only” (grey cloud). An orange-cloud proxied CNAME won’t resolve to sendgrid.net and verification fails.
DNS setup
Host-field doubling: many registrars auto-append your domain, so entering em1234.yourdomain.com produces em1234.yourdomain.com.yourdomain.com. Enter just the subdomain label (em1234, s1._domainkey, s2._domainkey) if the panel adds the domain for you.
Coverage
Single Sender Verification is not domain authentication — it lets you send from one address but still shows “via sendgrid.net” and doesn’t give you SPF/DKIM alignment. You must run Authenticate Your Domain.
DNS setup
Don’t add a redundant include:sendgrid.net to your root SPF when you used the CNAME (Automated Security) setup — it’s unnecessary and needlessly consumes one of your SPF lookups.
DNS setup
The 10-lookup SPF limit (RFC 7208): every include: in your root SPF counts toward a hard limit of 10 DNS lookups. SendGrid’s CNAME approach adds zero lookups to your root SPF, which is a real advantage if you already stack Google, Microsoft, Mailchimp, etc.
Breaks auth
Keep exactly one SPF TXT record on your root domain. If you also send from other providers, merge their mechanisms into a single v=spf1 record rather than publishing a second SPF TXT (two SPF records is itself a PermError).

Build your SPF record

SendGrid doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list