Loading tutorials…
Loading tutorials…
Gmail and Yahoo's 2024 bulk sender rules made domain authentication non-negotiable above 5K sends/day — and strongly recommended below it. SendGrid hides the link-branding step that most accounts skip, leaving every click flagged 'via sendgrid.net' in Gmail's clip warning. Here's the full auth stack.
Who this is forSendGrid accounts still sending on Single Sender Verification, or accounts with partial auth (DKIM only, no DMARC, no link branding). If your emails show 'via sendgrid.net' under the From name in Gmail, this is exactly what you need.
What you'll need
Step 1
Send marketing from em.yourbrand.com or news.yourbrand.com — NOT yourbrand.com. Protects your root domain reputation when marketing has a bad week.
If you send marketing AND transactional from the same root domain (yourbrand.com), a bad marketing campaign tanks transactional deliverability too. Order confirmations go to spam alongside the promo.
Best practice: use a sending subdomain (em.yourbrand.com, mail.yourbrand.com, news.yourbrand.com) for marketing. Keep transactional on root (yourbrand.com) OR a separate subdomain (t.yourbrand.com).
The subdomain still inherits some reputation from the root in 2026's machine-learning filters, but isolates the worst damage.
Pick the subdomain now. You'll authenticate it in the next step. The From address can still display as hello@yourbrand.com — the authenticated domain is what matters for DKIM alignment.
Step 2
SendGrid → Settings → Sender Authentication → Domain Authentication → Authenticate Your Domain. Pick your DNS host so SendGrid generates the right format.
SendGrid → Settings → Sender Authentication → Domain Authentication → Authenticate Your Domain.
DNS Host: choose your actual host from the dropdown (Cloudflare, GoDaddy, Namecheap, Route 53, etc.). SendGrid pre-formats records for that host's quirks.
Would you like to also brand the links for this domain? → YES. This is the step that removes "via sendgrid.net" from Gmail clip flags. Skip and you're leaving 5-10 points of open rate on the table.
Click Next. Enter the domain: yourbrand.com (use the root — SendGrid will generate records for the subdomain you choose next).
Use a custom return path → YES. Subdomain for return path: em (or whatever you chose in Step 1). This makes the bounce return-path (envelope-from) match your brand instead of sendmail.net.
Click Next. SendGrid shows 3-5 CNAME records to add to your DNS (typically: 2 DKIM CNAMEs, 1 return-path CNAME, 2 link-branding CNAMEs).
Step 3
Copy each CNAME record from SendGrid into your DNS host exactly. Pay attention to Cloudflare proxy toggle — must be OFF for CNAMEs.
In your DNS host (Cloudflare/GoDaddy/Route 53/etc.), add each CNAME SendGrid provided. Typical records: `em####.yourbrand.com → u#######.wl###.sendgrid.net`, `s1._domainkey.yourbrand.com → s1.domainkey.u#######.wl###.sendgrid.net`, `s2._domainkey.yourbrand.com → s2.domainkey.u#######.wl###.sendgrid.net`, plus link-branding equivalents.
Cloudflare gotcha: set proxy status to DNS only (gray cloud), NOT proxied (orange cloud). Cloudflare proxy on CNAMEs breaks DKIM signature lookup.
GoDaddy gotcha: when entering a CNAME, GoDaddy may auto-append your domain. Enter `em1234` not `em1234.yourbrand.com` — it adds the domain automatically.
Save the records. DNS propagation: Cloudflare 5-15 min, GoDaddy/Namecheap 30 min - 2 hours, Route 53 5-30 min. Wait at least 1 hour before clicking Verify.
Verify in SendGrid: Settings → Sender Authentication → Domain Authentication → click Verify. All records should show green checks. If any are red, click the red row to see what SendGrid actually saw vs expected — usually a typo.
Step 4
Add ONE SPF TXT record at the root with include:sendgrid.net. If you already have an SPF record, merge — never create two.
Check existing SPF: in your DNS host, look for a TXT record at the root (@) starting with `v=spf1`. If none exists, add: `v=spf1 include:sendgrid.net ~all`.
If one DOES exist (e.g., for Google Workspace: `v=spf1 include:_spf.google.com ~all`), MERGE — never create two SPF records. The merged version: `v=spf1 include:_spf.google.com include:sendgrid.net ~all`.
Two SPF records at the same name = permanent SPF fail. Mailbox providers reject the whole record set. This is the #1 silent SPF mistake.
Always end with `~all` (soft fail) initially. `-all` (hard fail) is for accounts with confidence in their complete sender inventory. Start soft, harden later.
Verify SPF at mxtoolbox.com → SPF Record Lookup → enter yourbrand.com. Should return one record, all includes resolving, no PermError.
Step 5
Add a TXT record at `_dmarc.yourbrand.com` with `v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com`. Start with p=none for 30 days, then escalate.
In your DNS host, add a TXT record at `_dmarc.yourbrand.com`. Value: `v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com; ruf=mailto:dmarc@yourbrand.com; pct=100; aspf=r; adkim=r`.
p=none means: report failures but don't block. This is monitoring mode. Required as the starting policy — escalating to p=quarantine or p=reject too early blocks legitimate emails.
rua = aggregate reports (daily XML summaries). ruf = forensic reports (per-failure details, optional and most ISPs don't send them anyway).
Set up a DMARC reporting tool to parse the rua XML: dmarcian (free tier up to 5K msgs/mo), Postmark DMARC (free), or Valimail Monitor (free). Hand-parsing XML is misery.
Run p=none for 30 days. Watch the reports. Look for: legitimate sending sources you forgot (e.g., HubSpot, Mailchimp, your transactional service) failing DKIM or SPF alignment.
After 30 days clean: change to `p=quarantine; pct=10` for 14 days (quarantines 10% of failures). Then pct=25, 50, 100 over 60 days. Finally, escalate to `p=reject` only after 90+ days of clean reports.
Step 6
Send a test email to a Gmail address. Open the original headers. Verify DKIM=pass, SPF=pass, DMARC=pass, AND that DKIM signing domain matches the From domain (alignment).
Send a test email from SendGrid (Marketing Campaigns single-send or API) to a Gmail address you control.
In Gmail, open the email → three-dot menu → Show original.
Look at the Authentication-Results header. Should show: `spf=pass`, `dkim=pass`, `dmarc=pass`.
Critically: check DKIM signing domain. `dkim=pass header.i=@em.yourbrand.com` is GOOD — DKIM is signing with your authenticated subdomain. `dkim=pass header.i=@sendgrid.net` is BAD — DKIM is signing with SendGrid's shared domain, no alignment to your brand.
If DKIM is signing with sendgrid.net, your Domain Authentication didn't apply to the send. Causes: sent via Single Sender that wasn't replaced, sent from an unauthenticated address, or SendGrid hasn't picked up the new auth (wait 1 hour after Verify shows green).
DMARC alignment: From domain must match either SPF return-path domain OR DKIM signing domain. With your custom return path subdomain (em.) and DKIM CNAMEs, both will align.
Step 7
SendGrid → Settings → Sender Authentication → Domain Authentication → Set Default. Without this, sends still use whatever address you pass without auth alignment.
SendGrid → Settings → Sender Authentication → Domain Authentication.
Find your newly-authenticated domain in the list. Click the row → Set as Default.
This tells SendGrid: any send from any address on this domain should be signed with this DKIM key + use the custom return path. Critical for Marketing Campaigns + API sends.
For multi-domain setups: authenticate each domain separately. SendGrid will pick the matching domain for each send based on From address.
Re-test by sending another test email and checking headers (Step 6). DKIM signing domain should now be your subdomain on every send.
Common mistakes
Skipping link branding ("via sendgrid.net" stays visible)
What goes wrong: Gmail shows 'via sendgrid.net' under your From name when links route through sendgrid.net's tracking domain. Open rate drops 5-10 points on Gmail (60%+ of most B2C lists). On a 50K/mo sender, that's 2,500-5,000 missing opens monthly.
How to avoid: In Domain Authentication setup, choose YES on "Brand the links for this domain." Add the additional CNAMEs SendGrid provides. Verify links in test sends route through em.yourbrand.com, not sendgrid.net.
Two SPF records at the root domain
What goes wrong: SPF spec allows exactly one record per name. Two records → PermError → Gmail/Outlook treat as SPF fail. DMARC alignment breaks. Deliverability drops 15-25%.
How to avoid: Merge all SPF includes into ONE record at the root: `v=spf1 include:_spf.google.com include:sendgrid.net ~all`. Use mxtoolbox.com SPF lookup to confirm exactly one record returned.
Jumping straight to DMARC p=reject
What goes wrong: Without 30+ days of p=none monitoring, you don't know which legitimate sources are failing alignment. p=reject blocks them all — including your CRM, your invoice tool, your support inbox. Customers stop receiving order confirmations.
How to avoid: Start with p=none for 30 days. Use dmarcian/Postmark DMARC to parse reports. Escalate gradually: p=quarantine pct=10 → 25 → 50 → 100, then p=reject. Total timeline 90+ days to get to reject safely.
Cloudflare proxy enabled on SendGrid CNAMEs
What goes wrong: Proxied (orange cloud) CNAMEs resolve to Cloudflare IPs instead of SendGrid's targets. DKIM signature lookups fail intermittently. SendGrid's Verify shows green but real-world emails fail DKIM at random.
How to avoid: In Cloudflare DNS, edit each SendGrid CNAME → toggle proxy to DNS only (gray cloud). Save. Re-verify in SendGrid.
Not setting the authenticated domain as Default
What goes wrong: Domain Authentication shows green but Marketing Campaigns + API sends still use SendGrid's shared sendgrid.net DKIM. Headers show `header.i=@sendgrid.net` instead of your domain. Brand reputation builds on SendGrid's domain, not yours.
How to avoid: Settings → Sender Authentication → Domain Authentication → click your domain row → Set as Default. Re-test and verify `header.i=` in Gmail headers matches your subdomain.
Sending from root domain when subdomain was authenticated
What goes wrong: Authenticated em.yourbrand.com but sending From hello@yourbrand.com (root). DKIM alignment fails — From domain doesn't match DKIM signing domain. DMARC alignment fails. Reputation builds on the wrong scope.
How to avoid: Either: change From address to hello@em.yourbrand.com (most authentic), OR authenticate the root domain separately and set both as defaults. Don't mix scopes silently.
Recap
Done — what's next
How to set up a SendGrid account from scratch (sender, auth, API key, compliance)
Read the next tutorial
Hand it off
Domain authentication is one of those tasks where 80% of accounts have it 70% right — and that 30% gap costs 10-15 points of deliverability daily. A specialist who's authenticated 100+ SendGrid accounts will run the full DKIM + SPF + DMARC + link branding stack with alignment verification in 60-90 minutes. Typical engagement is $300-500 of one-time work at $14-16/hr.
See specialist rates
DNS propagation: Cloudflare 5-15 minutes, Route 53 5-30 minutes, GoDaddy and Namecheap 30 minutes to 2 hours, slower hosts up to 48 hours. SendGrid's Verify usually succeeds within an hour on most hosts. Always wait at least 1 hour before assuming a record is broken.
Yes — and Gmail/Yahoo's 2024 bulk sender rules made it explicitly required above 5K/day. DMARC is the policy layer that tells receiving servers what to do when DKIM or SPF fails. Without DMARC, your domain has no protection against spoofing and Gmail downranks accordingly.
Yes — Settings → Sender Authentication → Domain Authentication → Authenticate Your Domain. Repeat for each domain. SendGrid will route each send through the matching auth based on the From address domain. Useful for multi-brand setups.
Choose Other and SendGrid will show generic CNAME records. Most quirks are: GoDaddy auto-appends the domain (enter just the subdomain prefix), Cloudflare needs DNS only mode, Route 53 needs trailing periods on values. Test with a Gmail header check (Step 6).
Partially. Authentication fixes the SPAM tab (your real risk). Promotions tab is content-driven (image-heavy, lots of links, promotional language) — DKIM + DMARC don't change Gmail's tab classification. For Promotions, fix content; for Spam, fix auth.
Send a test email to a Gmail. Show original → look for `dmarc=pass`. Then check that DKIM `header.i=` aligns with your From domain. For ongoing monitoring, set up rua= reports going to dmarcian or Postmark DMARC — they parse the daily XML reports into a usable dashboard.
SendGrid
SendGrid's onboarding looks fast — sign up, paste an API key, send. The decisions hidden inside that flow (which Twilio org, which subuser, which sender identity, which API key scopes) lock in choices that are painful to reverse at month 6. Here's the setup that doesn't rot.
SendGrid
A dedicated IP is the most-recommended SendGrid feature that's wrong for 80% of accounts. Below 100K sends/month, you'll hurt deliverability — the IP can't build reputation on low volume. Above 250K/month sustained, it pays off. Here's the decision framework and full warmup playbook.
SendGrid
Open rate dropped from 28% to 14%. Bounces jumped. Customer support is forwarding 'we never got the email' tickets. The instinct is 'subject lines' or 'content' — usually it's deliverability infrastructure. Here's how specialists diagnose SendGrid deliverability without guessing.
Mailchimp
Deliverability is the silent killer of email revenue. Open rates dropping from 28% to 16% feels like 'the algorithm changed,' but it's almost always one of three things: authentication, warmup, or list hygiene. Here's the playbook.
SendGrid
DIY SendGrid is the right call until it isn't. The signal isn't 'sending more emails' — it's that the cost-of-mistakes finally outweighs the cost-of-hiring. Here's the honest framework for when that line is crossed.