# How do I set up SPF and DKIM for SendGrid? > Set up SendGrid SPF and DKIM with Domain Authentication, automated or manual security, account-specific DNS records, and DMARC validation. To set up SPF and DKIM for Twilio SendGrid, open `Settings > Sender Authentication`, start `Domain Authentication`, choose your DNS host, and enter the root domain used in your From address. Keep automated security enabled unless you have a documented reason to manage the records manually. Publish every account-generated DNS record, select `Verify`, and inspect a new delivered message. Never copy SendGrid values from another account or an online example. ## Quick takeaways - Domain Authentication is the SendGrid workflow for branded SPF and DKIM, not the Single Sender Verification shortcut. - Automated security normally gives you three CNAME records and lets SendGrid manage SPF, DKIM, and key rotation behind those records. - Manual security uses a different record set, so publish only the values generated for the selected account and domain. - The production From domain must match an authenticated domain or the account's valid default-domain logic. - SendGrid verification, public DNS, delivered headers, and DMARC reports are separate evidence layers. ## What should I check before configuring SendGrid? This guide covers outbound mail sent through Twilio SendGrid with Domain Authentication. It does not cover Single Sender Verification, dedicated-IP reverse DNS, Inbound Parse, or link branding beyond the choice shown during domain setup. You need access to the SendGrid account or subuser that will send the mail and permission to change the authoritative DNS zone. Twilio's [current Domain Authentication guide](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication) asks you to identify the DNS host before starting. Confirm the exact root domain that appears in production From addresses and decide whether a parent account or subuser owns the configuration. Inventory any existing records on the owners SendGrid will use. A CNAME cannot coexist with another record at the same owner. If another service already uses the intended sending subdomain or DKIM selector, choose a different SendGrid subdomain or resolve the conflict before publishing. > Copy every host and value from the SendGrid account, region, and domain you are configuring. Never publish another account's CNAME targets, DKIM key, SPF policy, verification data, account ID, or example values. ## Which setup method should I use? Keep automated security enabled for the standard setup. SendGrid then provides three `CNAME` records and can manage its SPF and DKIM records, including key rotation, behind those delegations. This reduces future DNS work when SendGrid changes the managed configuration. Use manual security only when your DNS design or change-control policy requires direct TXT and MX records. SendGrid documents two `TXT` records and one `MX` record when automated security is disabled. Manual mode makes your team responsible for later record changes. SendGrid also offers an automated Domain Connect path for specific eligible GoDaddy setups. Use it only when the current UI offers the method and you are authorized to approve the DNS changes. Other configurations follow the manual DNS-host workflow even when automated security remains enabled. ## How do I set up SPF and DKIM for SendGrid? ### 1. Open Sender Authentication Sign in to the SendGrid console and open `Settings > Sender Authentication`. In the `Domain Authentication` section, select `Get Started`. Do not use the Single Sender Verification section for a production domain-authentication rollout. ### 2. Select the DNS host and setup options Choose the DNS provider that hosts the authoritative zone. Select `Other Host (Not Listed)` or the uncertainty option if necessary. Decide whether to enable link branding, then continue. Open `Advanced Settings` before finalizing the domain when you need to review automated security, a custom DKIM selector, a custom return-path subdomain, or regional settings. Keep the defaults unless the production architecture requires a specific change. ### 3. Enter the domain used in From addresses Enter only the root domain SendGrid asks for, without `www` or a URL scheme. SendGrid uses that choice to generate the account-specific authentication configuration. Subdomains do not automatically inherit a parent's SendGrid authentication, so confirm the From-address scope shown by the current setup screen. ### 4. Publish every generated DNS record With automated security enabled, publish the complete set of CNAME records shown by SendGrid. **Return-path and SPF delegation** - Record type: `CNAME` - Host: the account-generated return-path owner - Target: the matching SendGrid target **First DKIM selector** - Record type: `CNAME` - Host: the first account-generated `_domainkey` owner - Target: its matching SendGrid target **Second DKIM selector** - Record type: `CNAME` - Host: the second account-generated `_domainkey` owner - Target: its matching SendGrid target Manual security displays TXT and MX records instead. Do not translate a manual record set into CNAMEs or copy a value from an automated example. Publish the record type, owner, value, and priority exactly as the selected setup produces. ### 5. Verify the authenticated domain Return to SendGrid after the records resolve and select `Verify`. Resolve every failed record individually. A successful status means SendGrid found the expected public records for that authenticated domain. ### 6. Send a message from the matching domain Send a new message through the actual API, SMTP relay, Marketing Campaigns workflow, parent account, or subuser that production will use. Use a From address covered by the authenticated domain. SendGrid's matching logic can fall back to another default domain when the From address does not match, so the delivered header is the final check. ## How does this setup affect DMARC? Domain Authentication replaces SendGrid's shared authentication identifiers with branded identifiers associated with your sending domain. The message still needs an aligned SPF or DKIM pass for DMARC. Under the [current DMARC standard](https://www.rfc-editor.org/info/rfc9989), the receiver compares authenticated domains with the visible From domain using the published alignment modes. Do not assume a green SendGrid status means DMARC passed. An application can still send from a different domain, use a default authenticated domain, or route through a configuration outside the account you verified. Inspect a delivered message and review aggregate reports before moving to stronger policy. Use Palisade's [DMARC checker](/tools/dmarc) to confirm the domain's policy before changing enforcement. ## How do I validate the setup? ### Check public DNS Resolve each generated owner using the record type shown in SendGrid. With automated security, query all three CNAME owners. With manual security, query the displayed MX and TXT owners. Compare the complete answers with the same SendGrid setup screen. Use Palisade to [check the SPF record](/tools/spf) and [check the DKIM selector](/tools/dkim). A public DNS pass does not prove that the production SendGrid message used the authenticated domain. ### Check the SendGrid status Open `Settings > Sender Authentication` and confirm that the intended domain is valid. Check the account or subuser context as well as the domain name. This status proves record discovery for that configuration, not the behavior of every application or From address. ### Inspect a delivered message Send a new message to a receiver where you can inspect raw headers. Use the receiver-added `Authentication-Results` field according to [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601). Confirm the SPF MAIL FROM domain, DKIM `d=` and `s=` values, visible From domain, and DMARC result. The expected result is `spf=pass`, `dkim=pass`, and `dmarc=pass`, with at least one passing identifier aligned to the visible From domain. If the header still uses `sendgrid.net` or an unexpected authenticated domain, review From-domain matching and the account's default-domain behavior. ### Review DMARC reports Find SendGrid traffic in aggregate reports after routine sends occur. Compare sources, authenticated identifiers, alignment, and disposition across APIs, campaigns, subusers, and dedicated or shared infrastructure. Reports can reveal a path that one manual test missed. ## Troubleshooting ### SendGrid cannot validate a record that appears in the DNS panel Twilio's [sender-authentication troubleshooting guide](https://www.twilio.com/docs/sendgrid/ui/account-and-settings/troubleshooting-sender-authentication) documents automatic domain suffixing as a common cause. Resolve the public owner and check whether the DNS host repeated the root domain. Use a relative label when that is what the provider expects. ### A CNAME conflicts with another DNS record Inspect the exact owner for an existing TXT, MX, CNAME, or other record. A CNAME owner cannot hold unrelated record data. Remove only a stale record you have verified is safe to retire, or restart Domain Authentication with a different subdomain or selector. ### The DNS provider rejects an underscore SendGrid DKIM owners contain `_domainkey`. The underscore is required. Manual security still uses an underscored DKIM owner, so disabling automated security does not remove this requirement. Use a DNS host that can publish standard DKIM owner names. ### The domain verifies but messages still use sendgrid.net Check the actual From address and the SendGrid account or subuser that sent the message. SendGrid applies a matching valid authenticated domain first, then a valid default according to account context. Authenticate the correct domain or fix the application From address. ### Verification remains pending Twilio says DNS validation can take up to 48 hours. Confirm the authoritative record and a public resolver before waiting the full window. If both match SendGrid and verification still fails, capture the exact failing owner and contact SendGrid support. ## Check the domain beyond SendGrid Run Palisade's [Email Security Score](/tools/email-security-score) after SendGrid verifies the domain. The score checks public authentication signals, but it does not prove the exact SendGrid application path, private vendor status, continuous alignment, or future inbox placement. One verified SendGrid domain does not identify other services using the From domain. Palisade's DMARC Agent turns aggregate-report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. It detects when authentication and alignment conditions indicate that a domain is ready for the next policy stage, then proposes the move for your team to review and apply. This human-in-the-loop workflow helps you progress toward `p=reject` while keeping policy changes under your control. Stronger authentication helps protect your domains and supports better email deliverability. Palisade does not change SendGrid settings, select a From address, control receiver handling, guarantee delivery, or apply policy changes without human approval. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=how-do-i-set-up-spf-and-dkim-for-sendgrid) ## Frequently asked questions ### Is Domain Authentication different from Single Sender Verification? Yes. Domain Authentication publishes SPF and DKIM-related DNS records for a domain. Single Sender Verification confirms one From address and is useful for limited testing, but it is not the same production domain-authentication setup. ### Should I keep SendGrid automated security enabled? Yes, for the standard setup. Automated security delegates the generated SPF and DKIM configuration through CNAME records so SendGrid can manage related updates and key rotation. Use manual security only for a documented operational reason. ### Can I copy SendGrid CNAME values from another account? No. SendGrid generates values for the selected account, domain, options, and region. Reusing another tenant's records can validate the wrong configuration or fail completely. Copy every value from the account you are configuring. ### Do I still need DMARC after SendGrid verifies the domain? Yes. SendGrid verification checks its expected authentication records. DMARC belongs to the From domain and covers every sender. Publish and monitor one domain policy, then review aggregate reports before stronger enforcement. ### Can one SendGrid authenticated domain cover every subdomain? No. SendGrid's current setup guidance says subdomains do not automatically inherit the parent's authentication permissions. Confirm each production From-domain pattern and authenticate additional domains or subdomains when required. ### Will SendGrid verification guarantee inbox placement? No. Authentication supports domain trust and DMARC alignment, but receivers still consider reputation, content, traffic patterns, and other signals. Validate the technical result without treating it as a delivery guarantee.