What DNS records does SendGrid domain authentication need?

With automatic security on (the default), three CNAMEs: the return-path subdomain SendGrid creates for you (like em1234.yourdomain) pointing to your SendGrid subdomain target (u….wl.sendgrid.net), and two DKIM selectors, s1._domainkey and s2._domainkey, pointing to SendGrid's key hosts. Behind those CNAMEs SendGrid generates the subdomain's SPF and MX and rotates the DKIM keys itself. With automatic security off, you instead publish SendGrid's MX at the subdomain, an SPF record (v=spf1 include:sendgrid.net ~all) on the subdomain, and a static DKIM TXT record at the m1 selector. In both modes your root domain's SPF and MX are never touched. SendGrid's own pages count the records inconsistently (a setup page bundles link-branding records and a DMARC record into a count of four), so copy exactly what your Install DNS Records screen shows rather than trusting any count — including ours.

Does SendGrid authentication make my DMARC pass?

Through DKIM, yes — dependably. DKIM signatures carry d= equal to your domain, which aligns under both relaxed and strict DMARC alignment. SPF is different by construction: the Return-Path is always the em-subdomain SendGrid creates, so SPF alignment is relaxed-only. Twilio's own DMARC documentation warns that a DMARC record with aspf=s (strict SPF alignment) combined with a root-domain From will fail — occasionally surfacing as a 550 5.7.26 rejection — and advises against setting aspf=s. Also check your From domain matches an authenticated domain exactly; mail from a domain with no matching authentication is documented to go out as sendgrid.net, which is the usual reason 'authenticated but DMARC still fails'.

Do I need a dedicated IP for SendGrid authentication?

No — domain authentication works on shared pools. A dedicated IP (which comes with Pro Email API / Advanced Marketing Campaigns plans; trial and essentials tiers use shared IPs) matters for reputation isolation and is the prerequisite for reverse DNS, which SendGrid supports only with a dedicated IP. SendGrid's official volume guidance suggests a minimum of two dedicated IPs around 250,000 messages per month. Authenticate the domain first; treat the IP as a separate, later decision.

SendGrid · Domain authentication

SendGrid domain authentication: you delegate, SendGrid signs

First published 20 October 2026 · Flow, records and alignment facts from Twilio SendGrid's current documentation and support knowledge base, read for this guide. Record values are never printed here as examples to copy — yours come from your own SendGrid screen, because some of them are unique to your account.

THE MECHANISM Your DNS holds pointers; SendGrid holds the keys

You don't publish SendGrid's keys — you publish CNAMEs that delegate a slice of your domain to SendGrid, and SendGrid runs SPF, MX and rotating DKIM behind them. That's why this setup never touches your root SPF record, and why deleting a “useless-looking” CNAME later un-authenticates you silently.

Root SPF & MX: untouchedDKIM is your DMARC leg; SPF is relaxed-only

The setup ladder

SendGrid → Settings → Sender Authentication → Domain Authentication → Get Started. Enter your root domain only — SendGrid creates the sending subdomain itself (a return path like em1234; a custom label is optional at creation and cannot be edited into an existing authentication later).
Leave Automatic Security ON unless you have a specific reason (below).
Publish the records from your Install DNS Records screen into your DNS host — exactly as shown, values and all.
Verify in SendGrid. Failing rows name the record; check propagation with a DNS lookup of that exact name before re-editing.
Link Branding (separate feature, separate record pair → sendgrid.net): makes click/open links your domain. Do it now while you're in DNS anyway.
Send a test and read the headers: dkim=pass with your domain, SPF pass at the em-subdomain — the alignment story in the next section.

The records — both security modes

Mode	What you publish	Notes
Automatic Security ON (default)	3 CNAMEs: `em…` → your `u….wl.sendgrid.net`; `s1._domainkey` and `s2._domainkey` → SendGrid key hosts	SendGrid generates the subdomain's SPF + MX behind the delegation and rotates DKIM keys behind s1/s2 — rotation is the point of the design. No MX appears in your zone because it lives behind the CNAME.
Automatic Security OFF	`em…` MX → `mx.sendgrid.net`; SPF TXT on the subdomain (`v=spf1 include:sendgrid.net ~all`); static DKIM TXT at `m1._domainkey`	You own key management; the selector is `m1`, not s1/s2. Choose this only if your process demands static records.
Either	Root domain: nothing	No root SPF edit, no root MX change. Any guide that has you adding `include:sendgrid.net` to your root SPF is teaching an older/different flow and spending your 10-lookup budget (our SPF guide) for nothing.

On counts: SendGrid's own setup page elsewhere counts “four records” by bundling the link-branding pair and a DMARC TXT into the wizard's haul. Counts are marketing; your screen is the specification. Copy it exactly.

Alignment truth — the section that saves your DMARC rollout

DKIM: aligned, both modes of alignment. Signatures sign with d= = your domain. This is the leg your DMARC stands on.
SPF: relaxed-only, forever. The Return-Path is the em-subdomain by construction and — per Twilio — can never be rewritten to the root. Relaxed alignment passes (same organisational domain); strict (aspf=s) cannot, and Twilio's DMARC documentation explicitly warns that aspf=s + root From breaks, sometimes as a 550 5.7.26 (the error our 5.7.26 guide dissects). Leave aspf at its relaxed default.
The sendgrid.net fallback: if a message's From domain matches no authenticated domain, SendGrid's documented behaviour is to send it as sendgrid.net — alignment impossible, and the number-one cause of “but I authenticated!” Use From addresses on the authenticated domain exactly.
Subdomains don't inherit: authenticating example.com covers sending as designed above; a different subdomain's authentication is its own setup. And your own DMARC record remains yours — SendGrid checks DMARC during setup, but the enforceable policy is the _dmarc record you publish (our DMARC records guide).

Traps

Trap	Reality
Single Sender Verification “is basically the same”	It's a per-address shortcut for testing/low volume — no delegation, no alignment story like this. Fine for a trial; not your production identity.
Deleting the em/s1/s2 CNAMEs in a DNS cleanup	They look unused because nothing browsable lives there. They ARE the authentication. (Inventory rule from our SPF work: never delete a record you can't explain.)
Cloudflare proxy (orange cloud) on the CNAMEs	Labelled practice, not a SendGrid citation: the unanimous operational advice is DNS-only for these records, and DNS lookups are the arbiter — our research found no current SendGrid doc prescribing it, while SendGrid's Link Branding doc does carry a different official Cloudflare instruction (CNAME flattening set to “Flatten CNAME at root”). Verify by lookup, not by lore.
Waiting for rDNS before sending	rDNS exists only with a dedicated IP (Pro-class plans) and takes its own verification window (up to ~48 h). It's a reputation refinement, not an authentication prerequisite.

FAQ

Can I choose the subdomain name?

A custom return-path label is offered at creation; SendGrid's default is em + 4 random characters. It can't be edited into an existing authentication afterwards — a rename means a new authentication.

My records verify but DMARC fails on SendGrid mail.

Run the alignment checklist above in order: From exactly on the authenticated domain? (else the sendgrid.net fallback) · aspf=s anywhere in your DMARC record? (remove it) · DKIM actually signing (header check) — SPF was never going to carry this alone.

Two SendGrid accounts / subusers?

Each authentication is its own delegation; subdomains don't inherit, and neither do accounts. Authenticate per sending identity, and keep the CNAME inventory documented per account.

Sources

Twilio SendGrid — Domain Authentication & Configure Domain Authentication docs, Automatic Security support article, DMARC documentation (alignment table, aspf=s warning), Link Branding docs (incl. the Cloudflare flattening instruction), Sender Authentication (single sender vs domain), Dedicated IPs & reverse DNS docs · This site's RFC-grounded alignment rules (Articles #3/#11/#18).

Verification note: record sets for both security modes and the alignment limits were confirmed from Twilio's documentation on 20 October 2026. Claims SendGrid's docs don't make — a Cloudflare proxy prohibition, a default DKIM key size — are labelled practice/unverified in this guide rather than laundered into facts.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.