Setup Guides · SendGrid
SendGrid Authentication Setup: SPF, DKIM & DMARC
SendGrid does authentication differently from a mailbox provider: instead of you writing SPF and DKIM records, its Domain Authentication hands you a few CNAME records that delegate SPF and DKIM to a sending subdomain SendGrid manages. Get those records right and SendGrid can sign your mail with your authenticated domain and use an aligned Return-Path, so your messages pass DMARC when the visible From domain is aligned. Get them wrong, or stop at Single Sender Verification, and bulk mail can fail Gmail and Yahoo's sender requirements and be rejected or filtered to spam. This is the record set, why it keeps SPF off your root domain, and the failures we keep finding in audits.
Last updated 10 September 2026 · applies to Twilio SendGrid, Domain Authentication
What SendGrid authentication actually does
SendGrid gives you two ways to prove your mail is yours, and only one of them is real authentication:
- Single Sender Verification confirms you own one email address by clicking a link in a confirmation email. It needs no DNS access, but it does not publish aligned SPF or DKIM, so it should not replace Domain Authentication for production or bulk sending - and it will not pass the Gmail and Yahoo bulk-sender rules.
- Domain Authentication (formerly "domain whitelabel") is the real thing: you publish DNS records and SendGrid then signs your mail with DKIM
d=yourdomain.comand routes bounces through a subdomain of your domain. This is what aligns for DMARC and is the recommended configuration for production sending.
The clever part: with Domain Authentication's Automated Security (on by default), you publish CNAME records that point at SendGrid, and SendGrid maintains the actual SPF and DKIM values behind them. That means your root domain SPF is never touched, and SendGrid can rotate DKIM keys without you republishing anything.
What you need
- A SendGrid account with access to Settings → Sender Authentication.
- Access to your domain's public DNS (registrar or DNS host) to add CNAME and TXT records.
- The domain you send from. Have your DNS host name ready - SendGrid tailors the instructions to it.
The setup, step by step
1 Start Domain Authentication (not Single Sender)
Go to Settings → Sender Authentication → Authenticate Your Domain. Pick your DNS host, enter only your root domain (for example yourdomain.com - omit www and any protocol), and leave "Use automated security" on. SendGrid automatically sends under a generated subdomain, so you do not type one here.
The advanced settings let you customise the sending subdomain and the DKIM selector. A custom Return-Path gives you a clearer, aligned bounce domain, and authenticating a genuinely separate From subdomain can help isolate a mail stream's reputation. Just as important, choosing an unused custom selector is how you force a fresh 2048-bit DKIM key when re-authenticating an old 1024-bit configuration (see the failures below).
2 Publish the CNAME records SendGrid generates
A typical Automated Security configuration shows three authentication CNAMEs - one return-path record and two DKIM selectors - like this (the bracketed parts are your account/domain-specific values). Link Branding, custom return paths and other account options can change the displayed set, so always publish the exact records shown in your SendGrid account:
Type Host Value CNAME em[####].yourdomain.com u[#######].wl[###].sendgrid.net CNAME s1._domainkey.yourdomain.com s1.domainkey.u[#######].wl[###].sendgrid.net CNAME s2._domainkey.yourdomain.com s2.domainkey.u[#######].wl[###].sendgrid.net
The em[####] record is your return-path (bounce) subdomain - it carries SPF for the sending subdomain, so receivers can route bounces and your root SPF stays clean. The two s1/s2 records are DKIM. Publish all three as CNAME, exactly as given.
Publish them DNS-only, never proxied
On Cloudflare (or any proxying DNS), set every one of these CNAMEs to DNS only (grey cloud), not proxied (orange cloud). Cloudflare proxying can hide the CNAME target behind Cloudflare addresses, so SendGrid's verification and receiving systems cannot resolve the delegated authentication configuration. It is a common cause of verification failure in the configurations we audit, and it is not covered in SendGrid's official troubleshooting.
3 Add Link Branding (recommended)
In the same Sender Authentication screen, set up Link Branding. It adds two more CNAMEs so SendGrid rewrites your click and open-tracking links through your domain instead of a shared sendgrid.net URL (enabling auto-SSL adds two more records). Spam filters weigh the reputation of the link domain, so branding your links keeps that reputation on your domain, not SendGrid's shared one.
4 Wait for propagation, then click Verify
DNS changes are not instant. SendGrid says to allow up to 48 hours before the records resolve everywhere. Clicking Verify before the records resolve is a common cause of a failed check. Once it validates, SendGrid marks the domain authenticated and your mail is signed with d=yourdomain.com.
5 Keep and then tighten the DMARC record
Domain Authentication also adds a DMARC record at _dmarc.yourdomain.com:
Type Host Value TXT _dmarc.yourdomain.com v=DMARC1; p=none;
p=none is monitoring only, not protection. Add an rua=mailto: address to collect aggregate reports, confirm from them that your SendGrid mail (and every other sender) passes DMARC-aligned, then move the policy through p=quarantine to p=reject. Our DMARC enforcement guide walks that path - including the current DMARCbis tags (np= for subdomains, and why pct= is being retired) - and the Postbox DMARC Monitor reads the reports for you.
How SPF, DKIM and DMARC line up here
- SPF - with Automated Security, SPF is published on the
em[####]sending subdomain (the Return-Path), managed by SendGrid via the CNAME. Your root domain SPF is unchanged. You do not addinclude:sendgrid.netto your root record; that include exists only in manual mode, and adding it unnecessarily consumes part of your ten SPF DNS lookups and can contribute to an SPF permerror - especially once the domain already authorizes several other senders. (Behind theem[####]CNAME, SendGrid maintains both an SPF and an MX record in its own zone - if youdigthat subdomain and see an MX pointing atmx.sendgrid.net, that is expected and routes your bounces.) - DKIM - SendGrid signs with
d=yourdomain.comusing thes1/s2selectors. Key length depends on when the domain was first authenticated, not on Automated Security: domains authenticated since May 2021 get 2048-bit keys; older configurations are still 1024-bit and are not upgraded automatically (see the failures below). Becaused=is your domain, DKIM is aligned either way. - DMARC - passes because that aligned DKIM matches your visible
From:domain. With relaxed SPF alignment (the DMARC default), a Return-Path such asem123.example.comalso aligns with a visible From ofexample.combecause both share the same organizational domain - the CNAME is how SendGrid manages the underlying SPF authorization, not what creates alignment. So a correctly authenticated SendGrid domain passes DMARC on DKIM alignment even when forwarding breaks SPF. For the full picture of how the three fit together, see our SPF, DKIM and DMARC guide.
Dedicated vs shared IP, and reverse DNS
Authentication is only part of the sending identity - the IP matters too, and on a dedicated IP its reverse DNS becomes your job. Gmail can reject mail from an IP with missing or mismatched forward-confirmed reverse DNS using 550 5.7.25 - the RFC-standard enhanced code for reverse-DNS validation failure (see our SMTP error codes reference) - so a dedicated IP with no rDNS fails before content ever matters.
- Shared IP (the default on most plans) - SendGrid owns the IPs and their reverse DNS; you inherit the pool's reputation. Fine for low and moderate volume, and nothing to configure.
- Dedicated IP (higher tiers / high volume) - the reputation is yours to build, and SendGrid provides a reverse-DNS (PTR) setup for it. Configure forward-confirmed reverse DNS: the sending IP's PTR must resolve to a hostname, and that hostname's A/AAAA record must resolve back to the same IP - otherwise you can hit
550 5.7.25at Gmail. Warm a new dedicated IP gradually.
The failures we keep finding
Stopping at Single Sender Verification
It leaves the visible From domain without aligned authentication and is unsuitable for bulk sending. It publishes no aligned SPF or DKIM, so it fails DMARC and the 2024 Gmail/Yahoo bulk-sender requirements. Use Domain Authentication for anything real.
Proxied (orange-cloud) CNAMEs on Cloudflare
If the em, s1 and s2 records are proxied, verification fails and mail routing breaks. Set each to DNS only. Because CNAMEs used for ordinary web traffic may be proxied, confirm every SendGrid authentication record is explicitly DNS-only.
Your DNS host auto-appends the domain
Some hosts add the zone name for you, so entering em123.yourdomain.com becomes em123.yourdomain.com.yourdomain.com. If your host appends the domain, enter just the host label (for example em123). A quick lookup after saving catches this immediately.
Clicking Verify before DNS has propagated
Give it up to 48 hours. Re-checking every minute and assuming the records are wrong leads people to delete and re-create correct records, which resets the clock.
Your DKIM key is still 1024-bit
SendGrid moved to 2048-bit keys in May 2021, but existing domain authentications are not upgraded automatically and may still use a 1024-bit key - Automated Security does not save you here. A domain authenticated in, say, 2019 is still signing with a 1024-bit key today. Check the key length of your s1._domainkey record; if it is 1024-bit, re-authenticate the domain with an unused custom selector (so SendGrid generates a fresh 2048-bit key rather than reusing the old s1 key), verify it, then delete the old configuration. This is a live audit finding sitting in a lot of long-standing SendGrid accounts.
Turning Automated Security off (and forgetting the MX record)
Manual mode makes you publish the records yourself: an MX record (em#### → mx.sendgrid.net) that routes your bounces, a v=spf1 include:sendgrid.net ~all TXT, and a DKIM key under the m1 selector that does not rotate. The MX is the one people miss - publish SPF and DKIM, skip the MX, and your return path breaks. Unless you have a specific reason, leave Automated Security on: it manages SPF, DKIM rotation and the MX for you.
Adding include:sendgrid.net to your root SPF anyway
On top of the CNAME setup it does nothing useful and burns several of your ten SPF lookups, risking a permerror that fails SPF for all your mail. With Domain Authentication, leave your root SPF alone.
Verify it end to end
DNS checkers only tell you the records exist. To prove SendGrid mail actually authenticates, send a real message and read the result:
- Send a test through SendGrid to Postbox Mailtester and confirm SPF pass, DKIM pass with
d=yourdomain.com, and DMARC pass (aligned). - Or open the received message's headers and check the
Authentication-Resultsline showsdkim=pass header.d=yourdomain.comanddmarc=pass.
If DKIM shows d=sendgrid.net instead of your domain, the domain was not authenticated (you are on the shared SendGrid signature) - go back to step 1.
Frequently asked questions
What DNS records does SendGrid need for authentication?
With Domain Authentication and Automated Security (the default), SendGrid generates three CNAME records - a mail/return-path record (em####.yourdomain.com) and two DKIM records (s1._domainkey and s2._domainkey) - plus a DMARC TXT at _dmarc.yourdomain.com set to p=none. Publish all of them and click Verify. The CNAMEs let SendGrid manage your SPF and DKIM under a sending subdomain without touching your root SPF.
Do I need to add include:sendgrid.net to my SPF record?
No, not with Domain Authentication and Automated Security. SendGrid publishes SPF on the em#### sending subdomain via the CNAME, so your root SPF is untouched. You only get v=spf1 include:sendgrid.net ~all in manual mode. Adding that include to your root SPF on top of the CNAME setup is unnecessary and wastes DNS lookups.
Why does SendGrid publish two DKIM selectors, s1 and s2?
So SendGrid can rotate DKIM keys between them without you republishing anything. Key length depends on when the domain was authenticated, not on Automated Security: domains authenticated since May 2021 get 2048-bit keys, while older ones stay 1024-bit and are not upgraded automatically (re-authenticate with a custom selector to fix that). SendGrid signs with d=yourdomain.com, so DKIM aligns and passes DMARC. Manual mode publishes a single key under the m1 selector - no rotation.
Is Single Sender Verification enough, or do I need Domain Authentication?
Single Sender Verification only confirms one address and produces no aligned SPF/DKIM, so it is for testing. Real and bulk sending needs Domain Authentication, which lets you send from any address on the domain and satisfies the Gmail and Yahoo bulk-sender rules. Single-sender does not.
Why did my SendGrid verification fail?
A common cause is attempting verification before the records have propagated - allow up to 48 hours. Other causes: the CNAMEs are proxied (set them to DNS-only on Cloudflare), your DNS host auto-appended the domain (em123.yourdomain.com.yourdomain.com), or a duplicate/conflicting record already exists at that host.
Does SendGrid set up DMARC for me?
Domain Authentication adds _dmarc.yourdomain.com at p=none - monitoring only. Keep it, add an rua address, confirm your senders pass aligned, then move to p=quarantine and p=reject. A DMARC monitor makes that safe.
Sources (Twilio SendGrid documentation): Configure domain authentication · DKIM records & selectors · 2048-bit DKIM migration · DMARC · Single Sender Verification · Link branding · Troubleshooting sender authentication. The Cloudflare "DNS-only" note reflects widely-reported practice, not SendGrid's official troubleshooting text.
Not sure your SendGrid mail is actually aligned?