SendGrid SPF record and domain authentication setup
Set up the SendGrid SPF record or current domain authentication records. Understand include:sendgrid.net, the return-path, and DMARC alignment.
The SendGrid SPF mechanism is:
v=spf1 include:sendgrid.net -all
Twilio SendGrid’s SPF documentation uses include:sendgrid.net to authorize SendGrid. Current domain authentication usually places that SPF identity on a branded return-path subdomain instead of your root domain.
Do not paste that value into your root domain by default. Current domain authentication uses a dedicated subdomain and account-specific DNS records. With Automated Security enabled, SendGrid manages SPF and DKIM through CNAME delegation.
We verified the SendGrid documentation in August 2026. In DMARC reports, the usual failure is a valid SendGrid SPF result for sendgrid.net that does not align with the visible From domain. Domain authentication fixes the identity, not only the SPF authorization.
SendGrid SPF record: include or domain authentication?
Use the record set shown in Settings > Sender Authentication. The current SendGrid documentation describes these paths:
| Configuration | Records SendGrid shows |
|---|---|
| Automated Security on | One mail CNAME, two DKIM CNAMEs, and one DMARC TXT record |
| Automated Security off | One MX record plus generated SPF, DKIM, and DMARC TXT records |
| Standalone SPF example | v=spf1 include:sendgrid.net -all |
The generated record set is authoritative for your account. The standalone SPF example is not a replacement for domain authentication.
Use this rule:
- If SendGrid shows records under Sender Authentication, publish those exact records.
- Keep Automated Security enabled unless your DNS or key-management design requires manual security.
- Add
include:sendgrid.netonly at the hostname SendGrid tells you to use. - Never create a second SPF record at the same hostname.
For DMARC, the authenticated subdomain gives SendGrid a custom return-path for SPF and a custom signing domain for DKIM.
Step 1: inspect the current mail identity
Send a real message through the SendGrid API key or subuser you use in production. Inspect the Return-Path, SPF domain, DKIM d= domain, and DMARC result.
If the identifiers still use sendgrid.net, configure domain authentication. Adding SendGrid to an unrelated Google Workspace or Microsoft 365 SPF record at the apex does not change the envelope sender that receivers evaluate.
If SendGrid explicitly tells you to maintain a combined SPF record at a hostname that already has one, merge the include. For example:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Use our SPF record generator to validate the merged record and its DNS-query count.
Step 2: prefer SendGrid domain authentication
In SendGrid, go to Settings > Sender Authentication and start domain authentication.
SendGrid says authenticated domains replace sendgrid.net with your sending domain and can remove “via” or “sent on behalf of” branding. With Automated Security on, the current record set includes one mail CNAME, two DKIM CNAMEs, and one DMARC TXT record.
Those records are account-specific. They often look conceptually like:
| Purpose | Example host | Example target |
|---|---|---|
| Mail / return-path | em.example.com |
u123456.wl.sendgrid.net |
| DKIM 1 | s1._domainkey.example.com |
s1.domainkey.u123456.wl.sendgrid.net |
| DKIM 2 | s2._domainkey.example.com |
s2.domainkey.u123456.wl.sendgrid.net |
| DMARC | _dmarc.example.com |
The DMARC TXT value shown by SendGrid |
Do not copy these examples. Use the exact hosts and targets in your SendGrid account.
Step 3: verify in SendGrid and DNS
After publishing records, return to SendGrid and validate the domain authentication.
Then check your domain with DMARCTrust. You want:
- One SPF record.
- Fewer than 10 SPF DNS lookups.
- SendGrid DKIM passing for SendGrid mail.
- DMARC passing through DKIM or aligned SPF.
Common mistakes
Adding include:sendgrid.net to the apex without checking the Return-Path. SPF is evaluated at the envelope sender domain. Publish the records generated for the authenticated domain.
Skipping domain authentication. Root SPF can authorize SendGrid, but DKIM and return-path alignment are usually handled through SendGrid’s sender authentication flow.
Copying example CNAMEs. SendGrid CNAME targets include account-specific values.
Forgetting subusers. SendGrid subusers can have their own authenticated domains. Verify the account or subuser that actually sends the mail.
What about DKIM?
For SendGrid, DKIM is part of domain authentication. Read the companion guide: SendGrid DKIM setup.
SPF helps receiving servers authorize SendGrid infrastructure, but DKIM is often what makes DMARC pass cleanly for marketing and transactional mail.
FAQ
What is the SendGrid SPF record?
The authorization term is include:sendgrid.net. In a current SendGrid domain-authentication setup, publish the account-specific DNS records SendGrid generates instead of assuming the include belongs at your root domain.
What DNS records does SendGrid domain authentication require?
With Automated Security on, SendGrid currently shows a mail CNAME, two DKIM CNAMEs, and a DMARC TXT record. With Automated Security off, it shows an MX record and separate SPF, DKIM, and DMARC TXT records. Publish the exact set in your account.
Should I use SendGrid Automated Security?
Usually yes. Automated Security lets SendGrid provide CNAME records and manage SPF/DKIM details for the authenticated domain.
Does SendGrid SPF make DMARC pass?
Not always. DMARC requires SPF or DKIM to pass with alignment. Configure SendGrid domain authentication and DKIM, then verify real messages.
