Table of Contents
- Whether SendGrid Belongs in Your Root SPF Record
- Root SPF requirements by SendGrid setup
- How to verify it
- Publishing the SendGrid CNAME Records
- SendGrid authentication CNAME records
- How should the DNS entries be entered?
- How to verify it
- How to Write One SPF Record With the SendGrid Include
- How should the manual policy be assembled?
- How to verify it
- SPF and DNS Mistakes That Break SendGrid Mail
- SendGrid SPF and DKIM failures by symptom
- Which fix should happen first?
- Questions About SendGrid SPF Records, Answered
- What happens if a SendGrid DKIM selector is already in use?
- Can a sending subdomain carry its own SPF policy?
- Should the policy use softfail or hard fail?
- How long until DNS changes appear in verification?
- How to Verify Your SendGrid SPF and DKIM Records
- What should the results show?
- How to verify it
Do not index
Do not index
With SendGrid domain authentication and automated security on, the root SPF usually doesn't need
include:sendgrid.net: SPF runs through the return-path CNAME, while the s1 and s2 CNAMEs handle DKIM. The include is needed when automated security is off or SPF is managed manually, not just because SendGrid sends mail for the domain.The important distinction is which domain the receiving server checks. Adding authorization to the root domain won't repair a broken return-path CNAME, and unnecessary includes make an existing policy harder to maintain.
Table of Contents
Whether SendGrid Belongs in Your Root SPF RecordRoot SPF requirements by SendGrid setupHow to verify itPublishing the SendGrid CNAME RecordsSendGrid authentication CNAME recordsHow should the DNS entries be entered?How to verify itHow to Write One SPF Record With the SendGrid IncludeHow should the manual policy be assembled?How to verify itSPF and DNS Mistakes That Break SendGrid MailSendGrid SPF and DKIM failures by symptomWhich fix should happen first?Questions About SendGrid SPF Records, AnsweredWhat happens if a SendGrid DKIM selector is already in use?Can a sending subdomain carry its own SPF policy?Should the policy use softfail or hard fail?How long until DNS changes appear in verification?How to Verify Your SendGrid SPF and DKIM RecordsWhat should the results show?How to verify it
Whether SendGrid Belongs in Your Root SPF Record
A SendGrid SPF record isn't automatically a root-domain TXT record. With automated security enabled, SendGrid provides a return-path subdomain that delegates SPF management through a CNAME, alongside CNAMEs for DomainKeys Identified Mail, or DKIM.
Start in Settings > Sender Authentication in the SendGrid dashboard. Open the authenticated domain, inspect its status, and confirm whether automated security is enabled. The generated DNS instructions determine which configuration applies.
Root SPF requirements by SendGrid setup
The presence of another provider doesn't itself make a SendGrid root include necessary. A company can keep its mailbox provider authorized at the root while SendGrid authenticates through its delegated return-path subdomain.
For manual SPF, SendGrid's SPF documentation describes the SendGrid include as delegated authorization. Receivers evaluate SendGrid's maintained policy rather than an IP list copied into the customer's DNS.
How to verify it
Run the mailX SPF checker against the root domain and compare the live policy with the dashboard configuration. If automated security is active, an existing SendGrid root include is a candidate for removal, not evidence that setup is complete. Confirm that no remaining sending workflow depends on that authorization before deleting it.
Publishing the SendGrid CNAME Records
SendGrid's automated-security workflow generates the DNS records for the selected domain. Publish those records as CNAMEs, using the exact targets from that account's dashboard.
The following hostnames are examples for example.com, not values to paste unchanged. SendGrid's return-path numbering, custom selectors, and target formats can differ by configuration; confirm the current naming in the dashboard and official setup documentation.
SendGrid authentication CNAME records
How should the DNS entries be entered?
- Select the domain in SendGrid's Sender Authentication settings so the records belong to the intended sending identity.
- Copy the return-path host and target exactly, preserving the account-specific target.
- Publish the return-path CNAME at the DNS provider, using a relative host if the provider automatically appends the zone name.
- Publish the DKIM CNAMEs with the selector names and targets generated by SendGrid.
- Resolve conflicting records at those exact hostnames, after confirming their ownership and purpose.
- Run SendGrid verification after the new records resolve publicly.
A DNS provider that appends the zone automatically generally expects the short host, not the full domain. Entering the full hostname into such a field can create an unintended repeated domain suffix.
Don't delete unrelated root TXT records while resolving conflicts. The relevant conflict is at the same DNS owner name as the required CNAME, not elsewhere in the zone.
How to verify it
Run the mailX DKIM checker for the authenticated domain with each generated selector, normally entered as s1 and s2, rather than the entire DNS hostname. A good result finds both keys through the CNAME targets and agrees with SendGrid's verified status.
A missing selector or an empty CNAME answer points to a wrong host, wrong target, conflicting record, or cached result. Allow existing DNS caches to expire before treating an unchanged response as proof that the edit failed.
How to Write One SPF Record With the SendGrid Include
Manual SPF requires a sender inventory before a DNS edit. Google Workspace, Microsoft 365, a customer relationship management platform, or another application may already rely on the policy being changed.
Publish one SPF policy at each owner name. Don't paste SendGrid's complete policy alongside an existing SPF TXT record.
The combined value is an example, not a universal replacement. Confirm the Google Workspace mechanism in Google's current administration documentation and retain every other legitimate authorization.
How should the manual policy be assembled?
- Inventory senders, including applications, forms, mailbox services, and transactional systems.
- Identify the policy owner each sender uses; a visible From domain alone doesn't establish that.
- Retrieve the existing SPF TXT policy, preserving its required mechanisms.
- Insert the SendGrid include before the terminal qualifier only if that policy needs it.
- Choose the qualifier according to the completeness of the sender inventory.
- Evaluate nested dependencies, not just the includes visible in the top-level record.
- Save the consolidated TXT policy, removing obsolete duplicate SPF policies at that owner name.
The mailX SPF Generator endpoint, spf-generate, returns a publishable TXT value or explains the alternative configuration when a root include isn't needed. It supports strict and soft qualifiers, but mailX doesn't publish DNS changes; the generated result still needs review against the sender inventory.
A soft qualifier produces softfail for unauthorized sources. A strict qualifier produces fail; neither setting alone guarantees a particular receiving server's delivery decision.
RFC 7208 limits an SPF evaluation to 10 DNS-dependent terms, including nested evaluations involving
include, a, mx, ptr, exists, and redirect; ip4, ip6, and all don't consume that budget.How to verify it
Run the mailX SPF checker on the policy owner. A good result shows a single valid policy, required authorization, and no lookup-budget error. Duplicate policies or permerror mean the configuration needs correction before sending.
SPF and DNS Mistakes That Break SendGrid Mail
Publishing a separate SendGrid SPF TXT record beside the existing policy doesn't add permission. It creates an ambiguous policy selection and can produce permerror, affecting mail from other authorized systems as well.
Another failure is adding SendGrid to the root despite using automated security. Google's SPF troubleshooting guidance warns that complex policies with multiple third-party services can exceed the 10-lookup limit. Changing the terminal qualifier won't repair that error.
SendGrid SPF and DKIM failures by symptom
Which fix should happen first?
Correct the policy or CNAME failure identified by the corresponding mailX check. Don't rotate credentials to repair missing DNS, and don't change DNS to repair rejected SMTP credentials.
For SendGrid SMTP, use the port and encryption pairing currently documented for the account's integration. An app password belongs to some mailbox-provider authentication workflows; it isn't a substitute for a SendGrid API key.
If removing obsolete authorization isn't enough, evaluate separate sending subdomains before choosing to flatten SPF records to reduce lookups. Flattening introduces maintenance responsibility when a provider changes its addresses.
How to verify it: Rerun the mailX SPF or DKIM checker after cached DNS expires. For a connection-only failure, use the mailX SMTP test with credentials belonging to an authorized account.
Questions About SendGrid SPF Records, Answered
What happens if a SendGrid DKIM selector is already in use?
Check the complete selector hostname before changing it. If the existing record belongs to an obsolete integration, replace it with the CNAME SendGrid generated for that selector. If another sender still uses it, use a different SendGrid selector where available or authenticate SendGrid on a dedicated subdomain. One selector hostname should resolve to the intended target.
Can a sending subdomain carry its own SPF policy?
Yes. SPF is evaluated at the envelope-sender domain, so
mail.example.com can carry a policy independently of example.com. With automated security, that subdomain can be the delegated return-path hostname while the root policy remains unchanged. It only helps when SendGrid mail uses that hostname in the return path.Should the policy use softfail or hard fail?
A practical rollout is roughly two weeks on
~all while reviewing authentication failures and, where enabled, DMARC aggregate reports. Repair any missing authorization or incorrect return-path delegation, then switch to -all after the results stay clean. Keep ~all while legitimate sources remain unresolved. Neither qualifier repairs a malformed policy or excessive lookups.How long until DNS changes appear in verification?
There is no universal delay. The wait depends on the previous record's TTL, resolver caching, and whether authoritative DNS has published the edit. Retest after the cached TTL expires; if the old answer persists, compare the resolver response with the authoritative record.
How to Verify Your SendGrid SPF and DKIM Records
Most of the verification work reuses checks already described. Re-run the SPF policy inspection from How to Write One SPF Record With the SendGrid Include, confirm the return-path CNAME resolves to the target from Publishing the SendGrid CNAME Records, and query the selectors SendGrid assigned through the mailX DKIM checker. Two checks sit outside that scope, and they are the ones that prove end-to-end authentication:
- Send an actual message to a controlled recipient inbox and inspect its authentication headers.
- Confirm DMARC alignment between the authenticated domains and the visible From domain.
What should the results show?
SPF evaluates the envelope-sender domain, which may differ from the visible From address. In received headers, inspect the identity associated with the SPF result rather than the pass verdict alone.
When SPF supplies alignment for Domain-based Message Authentication, Reporting, and Conformance, or DMARC, its authenticated domain must align with the From domain under the applicable alignment mode. Relaxed alignment permits the same organizational domain, so a SendGrid return path on a subdomain of the From domain still aligns. Strict alignment requires an exact match.
For the relationship between these identities and signatures, MailAdept's SPF, DKIM and DMARC explained provides additional context. A DNS check validates published configuration. The received-message test establishes which identities the sending workflow used.
How to verify it
Compare public DNS results, SendGrid's verification status, and the received message together. The dashboard confirms SendGrid accepted what it queried, the DNS lookups confirm what the rest of the internet sees, and the received headers confirm the identities attached to live traffic. A green dashboard alongside failing headers points to a mismatch in the sending configuration rather than a DNS problem.
Before the next SendGrid send, visit mailX to run free SPF and DKIM checks without signup and get plain-English explanations of broken records. mailX, a deliverability diagnostics toolkit by Mailwarm Inc. (YC S20), also supports REST API access, an app inside ChatGPT, and agent workflows from ChatGPT, Claude, or Cursor through its documented MCP server.