How to set up SPF, DKIM and DMARC for SendGrid

SendGrid's domain authentication (what it calls "Domain Authentication" in settings) issues you a small set of CNAME records. You do not write these by hand - they are account-specific and generated per domain.

What SendGrid gives you

In SendGrid's dashboard under Settings > Sender Authentication > Domain Authentication, you add your sending domain and it returns something shaped like this:

em1234.yourdomain.com      CNAME   u1234567.wl123.sendgrid.net.
s1._domainkey.yourdomain.com   CNAME   s1.domainkey.u1234567.wl123.sendgrid.net.
s2._domainkey.yourdomain.com   CNAME   s2.domainkey.u1234567.wl123.sendgrid.net.

The exact subdomain and selector values are specific to your account - copy them from that screen, do not reuse an example from elsewhere. SendGrid uses two CNAMEs (commonly s1 and s2 selectors) so it can rotate the DKIM key without you touching DNS again.

SPF: the em1234 CNAME covers it

The first CNAME (often labelled a "mail CNAME" or shown as your "Return-Path" domain) is what SendGrid uses as the envelope sender when you authenticate on your own subdomain, and it points at a SendGrid hostname that already has SPF set up server-side. You do not need a separate SPF include for this path once the CNAME is correctly published and verified in SendGrid's dashboard.

If you are instead sending via SendGrid's shared or dedicated IPs without domain authentication, you would add:

yourdomain.com.    TXT    "v=spf1 include:sendgrid.net ~all"

But domain authentication (the CNAME approach) is what actually aligns DKIM and gets you DMARC alignment - treat it as the default, not SPF alone.

DKIM: verify the signature is live

Once the CNAMEs resolve, SendGrid signs outgoing mail with the matching private key automatically. Confirm the record is published:

$ dig s1._domainkey.yourdomain.com CNAME +short
s1.domainkey.u1234567.wl123.sendgrid.net.

Then check a real sent message's headers for DKIM-Signature: ... d=yourdomain.com; s=s1 - the d= domain should match your sending domain, not SendGrid's.

DMARC: your own TXT record

SendGrid does not create this for you. Publish it yourself at the root of your sending domain:

_dmarc.yourdomain.com.    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Start at p=none to collect aggregate reports without affecting delivery, then move to p=quarantine once reports show your legitimate SendGrid traffic passing consistently.

The reality check on what SendGrid does and doesn't cover

SendGrid's domain authentication gets SPF and DKIM passing and aligned to your domain - that is real and sufficient for DMARC alignment. What it does not do is manage your DMARC policy, monitor your sender reputation over time, or tell you whether your mail is actually landing in the inbox versus spam. Those are separate problems even after authentication is perfect.

What not to do

• Don't skip domain authentication and send only from SendGrid's default shared subdomain if you care about deliverability - unauthenticated or default-domain mail is treated with more suspicion by Gmail and Yahoo's bulk-sender rules.
• Don't publish a second SPF record alongside an include:sendgrid.net one - only one SPF TXT record per domain is allowed; merge mechanisms into it instead.
• Don't set p=reject on day one. Watch aggregate reports first.

SendGrid authentication quick reference

FAQ

Do I need domain authentication if I'm only sending a handful of transactional emails? Technically no - SendGrid will deliver mail from its default shared domain. But Gmail and Yahoo's bulk-sender thresholds are based on volume per rolling period, not intent, and low-volume senders can cross them without noticing. Setting up domain authentication once avoids having to scramble later.

What happens if I change SendGrid accounts or re-add the domain? The CNAME values are tied to the specific SendGrid account and subuser configuration - re-adding a domain, or moving it to a new account, typically generates new selector values, meaning you need to republish the DNS records, not just re-verify the old ones.

Can I use SendGrid alongside another ESP on the same domain? Yes - merge SendGrid's SPF include with any other sender's include in a single SPF TXT record, and let each ESP sign DKIM with its own selector; they don't conflict as long as each uses a distinct selector name.

Authentication gets your mail accepted for delivery; it does not get it into the inbox.

Does a verified "Domain Authentication" badge in SendGrid guarantee DMARC alignment? It guarantees SPF and DKIM are both passing and signed with your own domain, which is what alignment actually requires - but always confirm by checking a delivered message's headers directly rather than trusting the dashboard badge alone, since dashboard status and live signing can occasionally drift out of sync after account changes. MailPilot warms the mailboxes sending through SendGrid and runs real per-provider seed-inbox placement tests, so you can see whether Gmail, Outlook, and Yahoo are actually putting authenticated mail in front of the recipient.