SendGrid (now part of Twilio) is a long-running transactional and marketing email platform. Its "Authenticate Your Domain" flow sets up SPF and DKIM using several CNAME records. This guide gives you the three DNS records you need to publish for SendGrid to authenticate cleanly: SPF, DKIM, and a safe DMARC starter.
1. SPF — authorize SendGrid to send
Publish (or update) a single TXT record at the root of your domain (host @) that includes SendGrid's SPF token:
v=spf1 include:sendgrid.net ~all
If you already have an SPF record, do not replace it — merge. Add include:sendgrid.net alongside your existing mechanisms, keeping every other sender that's already authorized. A domain may only have one SPF record; publishing two breaks SPF entirely. Use the SPF checker to verify the merged record once published.
2. DKIM — sign messages from SendGrid
SendGrid generates the DKIM key pair for you in its admin console. You publish the public key in your DNS as a CNAME (or set of CNAMEs).
- Sign in to SendGrid.
- Go to Settings → Sender Authentication.
- Under Authenticate Your Domain, click Get Started.
- Choose your DNS host and enter your domain.
- SendGrid generates several CNAME records (
em####,s1._domainkey,s2._domainkey). - Add all of them as CNAMEs in your DNS.
- Return to SendGrid and click Verify.
The record host(s) you'll end up adding: s1._domainkey, s2._domainkey, em####. Once published, confirm with the DKIM lookup.
3. DMARC — tell receivers what to do on failure
DMARC is sender-agnostic — the starter record is the same regardless of who hosts your mail. Publish it as a single TXT record at _dmarc:
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; fo=1
This is monitor-only: it doesn't change how mail is delivered. Instead, it tells receivers to send you aggregate reports about every server sending as your domain. Watch those reports for a few weeks, confirm only your legitimate senders pass, then tighten the policy to p=quarantine and eventually p=reject. Jumping straight to p=reject without checking reports is the most common way to block your own legitimate email. The DMARC checker can generate a tailored record for you.
Where do these records actually go?
All three records live at your DNS provider, not at SendGrid. Your mail provider tells you what to publish; your DNS host is where you publish it. If you're not sure where to add them, see the step-by-step guides for every common DNS provider — Cloudflare, GoDaddy, Namecheap, AWS Route 53, Google Cloud DNS, Hover, Porkbun, IONOS and OVH are all covered.
Verify what you published
Once everything is live, run the full diagnostic on your domain. It checks all three records, detects SendGrid as your mail host, and flags any mismatches between what you should have published and what's actually in DNS.
Frequently asked questions
Do I need SPF, DKIM and DMARC?
For sending email from a custom domain, yes. SPF lists which servers may send as you, DKIM cryptographically signs each message so receivers can verify it wasn't altered, and DMARC tells receivers what to do when SPF or DKIM fails. Together they're the modern standard — most major mailbox providers (Gmail, Yahoo) now require all three for reliable delivery to consumer inboxes.
Should DMARC start at p=none, p=quarantine or p=reject?
Start at p=none with a rua= address. That's monitor-only — it doesn't change how your mail is delivered, but it tells you who's sending as your domain via aggregate reports. Once you've watched reports for a few weeks and confirmed only your legitimate senders pass, move to p=quarantine, then to p=reject. Jumping straight to reject without checking reports is the most common way to block your own legitimate email.
Where do I actually publish these records?
All three records live at your DNS provider — not at your mail provider. Your mail provider tells you what value to publish; your DNS provider is where you publish it. See our guide for adding TXT records at each common DNS provider if you're unsure where to add them.