SendGrid: setting up the authenticated domain (SPF/DKIM)
By Thomas · virtual CISO · 2026-08-01
Among product teams and marketing teams alike, SendGrid (Twilio) ranks among the most widely deployed sending platforms: transactional email, application notifications, campaigns. Yet as long as nothing is configured on the DNS side, a SendGrid account sends under the platform's own identity — the DKIM signature carries a sendgrid.net domain, and so does the envelope address. From DMARC's point of view, that perfectly legitimate traffic has no tie whatsoever to the domain shown in the From field: neither mechanism aligns, and a p=reject policy would simply throw it away.
The platform's answer is called "domain authentication" — the feature formerly known as "domain whitelabel," since renamed. The principle: three CNAME records placed in the sending domain's DNS zone, delegating to SendGrid the publication of the DKIM keys and the SPF record the setup requires. Once validation passes, every message leaves signed in the organization's name, with an envelope that belongs to it as well.
Done properly, this setup makes SendGrid one of the most favorable cases among the major ESPs: DKIM aligns, and SPF aligns too — a double alignment other platforms don't offer. This guide walks through the role of each CNAME, the mechanics of "automated security," what delegation changes for DMARC, link branding, the mistakes that make validation fail, and the final counter-check: the RUA reports.
Three CNAMEs, one DNS delegation
SendGrid's setup wizard generates three records to place in the domain's zone — here example.com:
em1234.example.com. CNAME u1234567.wl123.sendgrid.net.
s1._domainkey.example.com. CNAME s1.domainkey.u1234567.wl123.sendgrid.net.
s2._domainkey.example.com. CNAME s2.domainkey.u1234567.wl123.sendgrid.net.
The first, em1234 (the exact prefix varies from account to account and can be customized), becomes the envelope subdomain: it is what shows up in the Return-Path of outgoing messages. Because it's a CNAME, any DNS query on that name is redirected to SendGrid's zone — which publishes the appropriate SPF record there, authorizing its own sending addresses. The platform can add or retire IPs from its fleet without the domain's zone moving by a single line.
The next two, s1._domainkey and s2._domainkey, are the DKIM selectors. Same logic: the public key is not copied into the domain's zone; it is published on SendGrid's side, and the CNAME bridges the gap. When a receiving server verifies a signature reading d=example.com; s=s1, DNS resolution follows the CNAME and fetches the key from SendGrid, entirely transparently.
This is delegation in the proper sense: the domain keeps the upper hand — deleting the three CNAMEs cuts everything off instantly — but the upkeep of the content, keys and address lists, falls to the platform. Annotated DMARC record examples show how this building block then slots into the domain's overall policy: domain authentication prepares the alignment, and the _dmarc record sets the instruction.
"Automated security": key rotation without touching DNS
The "automated security" option, enabled by default, is the whole reason the CNAMEs exist. Two selectors, s1 and s2, are provisioned from the start: the platform can generate a fresh key pair, publish it on its side, then switch signatures from one selector to the other — no DNS ticket, no internal intervention, no window of exposure. DKIM key rotation, an operation notoriously neglected whenever it demands a manual zone change, becomes a non-event handled platform-side.
Turning automated security off remains possible, and falls back to the classic model: the DKIM key is then supplied as a TXT record to copy verbatim into the zone, and the SPF authorization lands back with the internal team, as an include to maintain in its own record. Every future rotation becomes a manual, coordinated operation again. That mode has its justification when internal policy forbids DNS delegation to a third party — some regulated sectors require it — but the price is paid in operational load. For the vast majority of organizations, the default CNAME mode is the right call: fewer copy-paste errors, longer keys possible, and cryptographic hygiene delegated to a party that industrializes it.
DMARC alignment: the favorable scenario
DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. This is exactly where SendGrid's domain authentication stands out.
On the DKIM side, the signature carries d=example.com — the domain itself, not a platform domain. Alignment is a given, strict mode included. On the SPF side, the message envelope becomes bounce@em1234.example.com: a subdomain of the organizational domain. In relaxed mode — DMARC's default — that subdomain aligns with example.com; under DMARCbis the organizational domain is determined by the DNS Tree Walk, and the outcome is the same. Both mechanisms therefore pass aligned, and that redundancy has operational value: if a forward breaks SPF by changing the sending IP, DKIM survives; if a gateway alters the message body and voids the signature, SPF remains.
A comparison with other ESPs shows what makes this arrangement favorable. At Mailchimp, alignment rests on DKIM alone: the envelope stays on the platform's domains, so SPF passes but never aligns — compliant and sufficient, but with no safety net. The SPF and DKIM setup at Mailjet follows an intermediate model, with records to copy into the zone rather than a full delegation. SendGrid, by delegating both the DKIM selectors and the envelope subdomain, obtains the double alignment without a single value being transcribed by hand — the most robust arrangement an ESP can offer today.
Link branding: domain consistency down to the links
The same CNAME mechanics apply to a second, distinct but complementary feature: "link branding." By default, SendGrid's click tracking rewrites every link in a message toward a platform domain. With link branding, the rewrite targets a subdomain of the sending domain instead — url1234.example.com, or a chosen prefix — itself delegated by CNAME.
DMARC does not evaluate links: this building block changes nothing about alignment. What it changes is the perceived consistency of the message. An email signed example.com whose every link points to a third-party tracking domain sends a discordant signal — to spam filters, and to attentive recipients who hover over a link before clicking. Domain consistency — From, envelope, links, all under the same banner — feeds the overall reputation; off-domain tracking links are among the factors examined in why emails end up in spam. Since CNAMEs are being placed in the zone anyway, completing the set costs little.
The common mistakes that make validation fail
The setup fits in three records, yet a handful of traps come up constantly.
- CNAMEs proxied behind a CDN. This is mistake number one on zones managed at Cloudflare: the proxy (the orange-cloud icon) intercepts resolution and substitutes its own addresses for the CNAME target. SendGrid's validation fails — or worse, succeeds and then breaks silently. All three records must be set to "DNS only," proxy off: these are mail records, not web traffic to accelerate.
- The
emsubdomain already taken. A leftover from a past integration, a second SendGrid account, an existing wildcard in the zone: if the proposed name collides, validation won't pass cleanly. The right answer is picking another prefix through the custom Return-Path option (em2,m1…), never overwriting an existing record some other flow may depend on. - Domain duplication. Many DNS interfaces automatically append the domain to whatever name is typed: pasting
em1234.example.cominto the "name" field producesem1234.example.com.example.com. Adigquery against the exact expected name settles the doubt in ten seconds. - Validation tested too early — or never retried. DNS propagation takes anywhere from minutes to hours depending on TTLs. An immediate failure proves nothing; the check has to be rerun once propagation completes, because the platform only signs in the domain's name after validation.
- CNAMEs deleted afterwards. Validation is not an exam taken once: the records serve every single message, for every recipient-side DKIM and SPF check. A zone "cleanup" that removes them breaks authentication overnight.
Verifying the result in the RUA reports
The "verified" banner in SendGrid's interface confirms that the CNAMEs answer — not that real mail leaves aligned. The proof reads in the DMARC aggregate reports, a few days after activation.
In the RUA reports, the rows attributed to SendGrid's sending addresses should show two results: DKIM pass with d=example.com (selector s1 or s2) and alignment achieved; SPF pass with em1234.example.com as the envelope domain, aligned in relaxed mode. Deviations are quick to diagnose: a DKIM that passes with d=sendgrid.net flags a flow not using the authenticated domain — an unattached subuser, a forgotten second account, an integration pointing elsewhere; an SPF that passes without aligning, with a platform envelope domain, betrays the same symptom. Those rows would turn back into rejections under p=reject.
Once both mechanisms stay green across several weeks of reports, and across all SendGrid flows (transactional and marketing, every subuser included), the policy hardening can run its course — DMARCbis test mode t=y, then p=quarantine, then p=reject — with no risk to this channel.
In summary
SendGrid's domain authentication rests on three CNAMEs: an envelope subdomain (em1234) and two DKIM selectors (s1._domainkey, s2._domainkey), delegating key and SPF publication to the platform. "Automated security" makes key rotation invisible; the double alignment — DKIM on the domain, SPF on a delegated subdomain — makes this one of the most solid arrangements on the ESP market. The classic traps are DNS-shaped: CDN proxying to switch off on these records, a collision on the em subdomain, domain duplication, a validation to rerun after propagation. And the final verdict reads neither in the interface nor in a one-off test, but in the aggregate reports.
To establish the starting point, a free DMARC analysis of the domain reveals within seconds whether the SendGrid flow already signs under the right name and whether the envelope aligns. And to track the effect of the three CNAMEs over time, creating an account opens access to the decoded RUA reports, source by source — the counter-check that turns a green checkbox into certainty.
Enforcing DMARC, in practice
Thomas, the virtual CISO of DMARC.com, identifies every legitimate sending source, writes the exact DNS records, and takes a domain from p=none to p=reject — without breaking its mail.
Get to p=reject — freeRelated guides
- Mailchimp and DMARC: reaching full alignment
By default Mailchimp signs with its own domain: nothing aligns for DMARC. The CNAME records to publish, what RUA reports show before and after, and the dedicated subdomain.
- Authenticating Mailjet: SPF, DKIM and DMARC alignment
Domain validation at Mailjet, the SPF include, the mailjet._domainkey DKIM record and DMARC alignment: the full path, with the mistakes seen in real DNS zones.
- Authenticating Brevo: SPF, DKIM and DMARC alignment
Without domain-aligned DKIM, Brevo campaigns hit a deliverability ceiling. The mail._domainkey setup, the SPF envelope question and the proof in RUA reports.
About the author
Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.