SendGrid DNS authentication

RocketLead sends email via SendGrid. For automations to send from a customer’s domain (e.g. noreply@studio-example.com), the domain needs to be authenticated in SendGrid — which means adding CNAME records to the domain’s DNS zone.

This article walks through the SendGrid setup. The actual API-key handoff to RocketLead is covered in API key + scopes.

What “authentication” means here

SendGrid uses domain authentication (DKIM and link branding) to prove that mail sent from the domain genuinely originated from SendGrid. Practically: three CNAME records in the customer’s DNS, one per SendGrid signing key, plus an optional link-tracking CNAME.

Without authentication, mail from the domain ends up flagged as spam or rejected by Gmail / Outlook. With it, deliverability is dramatically better.

Step 1 — Add an authenticated domain in SendGrid

In SendGrid: Settings → Sender Authentication → Authenticate Your Domain.

Field	Value
DNS host	Whatever the customer uses (Strato, IONOS, Cloudflare, etc.). Picking it correctly is mostly cosmetic — the records are the same.
Branded links	No. Branded links are an additional feature that requires extra DNS work for marginal benefit; skip them for the operator-standard setup.
Domain	The customer’s email-sending domain (the part after the @).
Advanced → “Use a custom return path”	Leave default.
Advanced → “Use a custom DKIM selector”	Leave default.
Advanced → “Use automated security”	Leave on (the default).
Advanced → “Pinned to EU region”	Yes. This routes the customer’s sending traffic through SendGrid’s EU infrastructure, which keeps mail processing inside the EU for GDPR purposes. Important for German customers.

Click Next. SendGrid generates three CNAME records.

Step 2 — Add the CNAME records to the customer’s DNS

SendGrid shows three records like:

em1234.example.com.            CNAME u1234567.wl.sendgrid.net.
s1._domainkey.example.com.     CNAME s1.domainkey.u1234567.wl.sendgrid.net.
s2._domainkey.example.com.     CNAME s2.domainkey.u1234567.wl.sendgrid.net.

(The exact values are generated per domain.)

Add all three to the customer’s DNS zone, without modifying the host prefix or value. Most DNS providers want only the subdomain prefix (em1234, s1._domainkey, s2._domainkey) in the host field — not the full hostname — but check the provider’s docs.

Strato specifically uses just the prefix (no trailing dot, no domain suffix). Other providers vary; lean on the provider’s CNAME documentation if uncertain.

Step 3 — Verify

Back in SendGrid, click Verify. SendGrid checks for the CNAME records.

• Immediate success — done.
• Failure — DNS propagation can take minutes to hours, depending on the provider. Strato in particular is slower than most. If verification fails, wait 15-30 minutes and retry. If it’s still failing after an hour, inspect the records with dig or a public DNS lookup tool to verify they resolve to the SendGrid hostnames.

Verification is per-record. SendGrid shows you which of the three records is failing.

Step 4 — Add an SPF record (separate article)

DKIM (the CNAMEs above) is not enough for top-tier deliverability. The customer’s domain also needs an SPF record — see SPF record patterns.

Common pitfalls

Symptom	Cause
Verification fails immediately	Records pasted with extra spaces, wrong subdomain prefix, or pointing at the wrong target
Verification fails after 30 min	DNS provider is slow; wait longer
Verified, but mail still goes to spam	Missing SPF or DMARC record; see SPF record patterns
Verification succeeds, then fails later	Customer’s DNS records got overwritten — someone else edited the zone after you. Re-add and re-verify.
EU pinning option missing	SendGrid’s “Pinned to EU region” was only added recently; if you don’t see it, contact SendGrid support

What’s next

• SPF record patterns — required for good deliverability.
• No-reply sender rule — why every internal notification email is sent from noreply@.
• API key + scopes — how the SendGrid setup ties back to the RocketLead console.