Email authentication for SendGrid: SPF, DKIM and DMARC

26 April 2026 · 13 min read

SendGrid (now part of Twilio) is one of the most common ways to send transactional and marketing email at volume, and it is also one of the most common reasons a domain quietly fails DMARC. The catch is specific: SendGrid does not, by default, make your visible From domain pass SPF in a way DMARC cares about. It signs with DKIM under your domain, which is what saves you, but only if you complete the setup correctly and understand which checks actually align.

This guide is SendGrid-specific. It uses SendGrid's real selectors (s1 and s2), its real SPF include (sendgrid.net), the real CNAME structure that domain authentication creates, and the exact behaviour of the custom return-path option that controls SPF alignment. By the end you will know precisely which DNS records to publish, why DKIM alignment is the thing that carries you to p=reject, and how to verify each layer before you enforce.

If you want to skip ahead and just check what is already live on your domain, run your domain through the DMARC checker, SPF checker and DKIM checker first. Those three tools will tell you, in under a minute, whether SendGrid is already aligned or whether you are reading this just in time.

The one thing that matters: alignment, not just "pass"

DMARC does not care whether SPF or DKIM simply pass. It cares whether they pass and align with the domain in your visible From: address. This is the single concept that decides whether SendGrid works or breaks under enforcement.

There are two alignment checks and DMARC needs only one of them to succeed:

• SPF alignment: the domain in the SMTP envelope sender (the Return-Path, also called MAIL FROM or the bounce address) must match your From: domain, under relaxed alignment, by organisational domain.
• DKIM alignment: the domain in the d= tag of a valid DKIM signature must match your From: domain, under relaxed alignment, by organisational domain.

Here is the SendGrid-specific reality. Out of the box, SendGrid sends with a Return-Path on a SendGrid-owned domain or on a sendgrid.net envelope. SPF passes for that envelope domain, but that domain is not your From: domain, so SPF does not align. What carries you is DKIM: SendGrid signs every message with a key published under your domain (s1._domainkey.yourdomain.com / s2._domainkey.yourdomain.com), so the d= value is yourdomain.com and DKIM aligns.

That is why DKIM is non-negotiable with SendGrid and SPF is a bonus. If you only "add the SPF include" and skip domain authentication, you will pass SPF for a SendGrid envelope, fail alignment, fail DKIM, and DMARC will fail outright. For the deeper mechanics, see DMARC alignment explained.

Step 1: Set up Domain Authentication (this is the important step)

In SendGrid this feature is called Domain Authentication (older docs called it "Sender Authentication" or "whitelabel"). It lives under Settings, Sender Authentication, Authenticate Your Domain. This single workflow is what produces aligned DKIM, and optionally aligned SPF.

When you run it, SendGrid asks for your DNS host and your sending domain, then generates DNS records for you to publish. With Automated Security left on (the default, and the recommended choice), SendGrid creates CNAME records that point back into SendGrid so it can rotate keys for you without you touching DNS again.

A typical Automated Security set looks like this. The numeric IDs (em1234, u12345678, wl123) are unique to your account, so copy the exact values SendGrid shows you:

; SPF / Return-Path host
em1234.yourdomain.com.        CNAME   u12345678.wl123.sendgrid.net.

; DKIM selector 1
s1._domainkey.yourdomain.com. CNAME   s1.domainkey.u12345678.wl123.sendgrid.net.

; DKIM selector 2
s2._domainkey.yourdomain.com. CNAME   s2.domainkey.u12345678.wl123.sendgrid.net.

Three CNAMEs. The first wires up the Return-Path subdomain that SendGrid uses as the envelope sender; the second and third are the two DKIM selectors. Because they are CNAMEs into SendGrid, SendGrid can rotate the underlying DKIM keys behind s1 and s2 on a schedule without breaking you, which is the entire point of Automated Security.

A few SendGrid-specific gotchas when you publish these:

• Do not append your domain twice. Many DNS panels (Cloudflare, some registrars) auto-append the zone. If you paste em1234.yourdomain.com into a panel that already adds .yourdomain.com, you get em1234.yourdomain.com.yourdomain.com. Enter just the host label (em1234, s1._domainkey, s2._domainkey) where the panel expects a host.
• CNAMEs must not be proxied. On Cloudflare, set the orange cloud to grey (DNS only) for all three records. A proxied CNAME will not resolve to SendGrid and authentication validation will fail.
• TTL low while testing. Set a low TTL (300 seconds) so corrections propagate quickly, then raise it once verified.

After the records resolve, return to SendGrid and click Verify. SendGrid checks that all three CNAMEs resolve to the expected targets. Until that shows green, your mail is not aligned.

If you cannot use CNAMEs (Automated Security off)

Some environments cannot publish CNAMEs for these hosts, or you need to inspect the raw DKIM key. Turning Automated Security off changes the record set: instead of CNAMEs, SendGrid hands you a literal SPF TXT record on the em host and a single DKIM TXT record under a selector like m1._domainkey, plus an MX for the bounce host:

em1234.yourdomain.com.        MX    10 mx.sendgrid.net.
em1234.yourdomain.com.        TXT   "v=spf1 include:sendgrid.net ~all"
m1._domainkey.yourdomain.com. TXT   "k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

The trade-off is real: with Automated Security off, you own key rotation. SendGrid cannot rotate a TXT key it does not control, so you must manually re-publish a new DKIM key when you rotate. Unless you have a hard constraint, leave Automated Security on and use the CNAME flow. For why rotation matters and how often, see DKIM key rotation.

Step 2: The SPF include, and why it is not enough on its own

SendGrid's SPF include is:

include:sendgrid.net

If you also send from your own mail server or other providers, your apex (or sending subdomain) SPF record might look like:

yourdomain.com.  TXT  "v=spf1 include:sendgrid.net include:_spf.google.com ~all"

Two important, SendGrid-specific points:

First, include:sendgrid.net is heavy. It expands to several nested includes and consumes a meaningful chunk of the 10 DNS-lookup limit that SPF imposes. Stack SendGrid alongside Google Workspace, Microsoft 365 and a CRM and you can blow straight past 10 lookups, which produces a permerror and breaks SPF for every sender. If your record is getting crowded, run it through the SPF checker to see the live lookup count, and read SPF PermError: the 10-lookup limit. Flattening is the usual fix; see how SPF flattening works.

Second, and this is the part people miss: adding include:sendgrid.net to your apex SPF does almost nothing for DMARC by itself. SPF is checked against the envelope Return-Path domain, not your From: domain. With default SendGrid, the Return-Path is a SendGrid-controlled domain, so your apex SPF record is not even consulted for SPF alignment. The apex include matters for any mail you send where SendGrid uses your domain in the envelope, and it is good hygiene, but it is not what makes DMARC pass. DKIM alignment from Step 1 is.

This is the most common misunderstanding with SendGrid: teams add the SPF include, see SPF "pass" in a report, and assume they are DMARC-compliant. Then they move to p=reject and watch SendGrid mail get rejected, because SPF passed for a non-aligned domain and DKIM was never set up.

Step 3: Custom Return-Path, for SPF alignment as well

If you want SPF to align too (belt and braces, useful for resilience because forwarding can break DKIM while leaving SPF intact), use SendGrid's custom return-path. By default the Return-Path subdomain SendGrid creates (the em1234 host) is treated as a SendGrid-side bounce domain, and many setups end up with an envelope that does not share your organisational domain.

The custom return-path option lets you set the Return-Path so it lives under your sending domain rather than a SendGrid-shaped one. When the envelope sender is, for example, bounces@em1234.yourdomain.com and your From: is you@yourdomain.com, the two share the organisational domain yourdomain.com, so under relaxed SPF alignment they match and SPF aligns.

To set this, during Domain Authentication open Advanced Settings and either let SendGrid generate the return-path host under your domain or specify your own subdomain label. The practical outcome you are aiming for:

• From: domain: yourdomain.com
• Return-Path (envelope) domain: em1234.yourdomain.com (or a label you choose, under yourdomain.com)
• SPF for that envelope host: passes via the include:sendgrid.net chain
• Result: SPF aligns by organisational domain, in addition to DKIM aligning

You do not strictly need SPF alignment to reach p=reject with SendGrid, because DKIM alignment alone satisfies DMARC. But having both means a single broken link does not fail the whole message. If a forwarder rewrites the path and breaks DKIM, aligned SPF can still carry the message; if SPF breaks, aligned DKIM carries it. For the forwarding edge cases, see DKIM, alignment and forwarding.

Step 4: Subdomain strategy (recommended for SendGrid)

A strong pattern, especially if SendGrid is your bulk or marketing stream, is to send from a dedicated subdomain rather than your apex, for example mail.yourdomain.com or news.yourdomain.com. Authenticate that subdomain in SendGrid, publish the three CNAMEs under it, and use a From: like you@mail.yourdomain.com.

Why this helps with SendGrid specifically:

• Reputation isolation. Bulk and transactional reputation stays off your apex, which protects your person-to-person Google Workspace or Microsoft 365 mail.
• Cleaner SPF. The SendGrid include lives on the subdomain's SPF record, not your apex, so it does not eat into the apex 10-lookup budget shared with your corporate mail providers.
• Independent policy. You can enforce on the subdomain at your own pace using a subdomain policy. See the subdomain DMARC record and the sp tag.

Remember that DMARC alignment is by organisational domain under relaxed mode, so a From: of you@mail.yourdomain.com aligns with a DKIM d=mail.yourdomain.com and with a Return-Path under mail.yourdomain.com. Keep the From:, the DKIM d= and the Return-Path all consistent under the same subdomain.

Step 5: Publish DMARC and start at p=none

Now publish DMARC, but start in monitoring mode so you can see SendGrid's real alignment in reports before enforcing. A starting record at your apex:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; adkim=r; aspf=r"

• p=none means observe only, do not act on failures yet.
• rua= is where aggregate XML reports are sent. Point this somewhere you actually read. If you want this parsed into plain English with per-source pass rates, send rua to a monitoring inbox instead of an unread mailbox.
• fo=1 asks receivers to send failure samples when either SPF or DKIM fails, which is useful while you are confirming SendGrid alignment.
• adkim=r and aspf=r keep relaxed alignment, which is what you want with SendGrid subdomain return-paths. Do not set adkim=s (strict) unless your DKIM d= exactly equals your From: domain with no subdomain difference, or you will fail messages that would otherwise align.

If you have never published one, the DMARC generator builds a valid record from a short form, and understanding your DMARC record explains every tag.

Step 6: Read the reports and confirm SendGrid aligns

Leave p=none running for one to two weeks and read the aggregate reports. You are looking for one specific thing: every message that came from SendGrid should show DKIM: pass and aligned, ideally with SPF: pass and aligned too if you configured the custom return-path.

In the raw XML, a healthy SendGrid row shows your From: domain in <header_from>, a <dkim> result of pass with the domain matching your From: (or its organisational parent), and the disposition as delivered. Raw XML is painful to eyeball, so paste a report into the DMARC report analyzer, or have DMARC monitoring ingest your rua stream continuously. For a walkthrough of what the fields mean, see reading your first DMARC report.

Watch specifically for these SendGrid failure signatures:

• DKIM fails or is absent for SendGrid mail. Domain Authentication was not completed or the CNAMEs are not resolving. Re-check s1._domainkey and s2._domainkey with the DKIM checker.
• SPF passes but is not aligned. Normal for default SendGrid without a custom return-path. Fine if DKIM aligns; if you want SPF to align too, do Step 3.
• A SendGrid source you do not recognise. Multiple SendGrid subusers or a separate Marketing Campaigns sender can appear as distinct sources. Authenticate each so they all align.
• A non-SendGrid source spoofing your domain. This is exactly what DMARC reporting exists to surface. Note it, then proceed; enforcement will stop it.

Step 7: Move to quarantine, then reject

Once reports confirm SendGrid (and every other legitimate sender) is aligned, tighten the policy in stages. Never jump straight from none to reject.

First, quarantine a slice of traffic:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

The pct=25 applies quarantine to a quarter of failing messages while the rest stay at the previous handling, so you can watch for collateral damage on a small sample. Raise to pct=100, watch a few more days, then enforce fully:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

At p=reject, any message claiming to be from your domain that does not pass an aligned check is rejected by receivers. Because your SendGrid mail is DKIM-aligned, it sails through; spoofed mail does not. The full staged method, including how long to sit at each step, is in reaching p=reject without breaking email and the enforcement journey.

The Gmail, Yahoo and Microsoft bulk-sender rules also lean on this: if you send volume through SendGrid to those mailboxes, an aligned, enforced DMARC record is effectively required. See Gmail, Yahoo and Microsoft now require DMARC.

SendGrid-specific troubleshooting

"DKIM passes in SendGrid's own check but DMARC reports show DKIM fail." SendGrid's verify button confirms the CNAMEs resolve; it does not confirm alignment with your From:. If you send from you@yourdomain.com but authenticated mail.yourdomain.com, the d= will be mail.yourdomain.com and, under relaxed alignment, that still aligns with the apex. Under strict (adkim=s) it will not. Keep alignment relaxed, or match the authenticated domain to your From:.

"I added the SPF include but DMARC still fails." Expected. The apex include does not control SendGrid's envelope. Complete Domain Authentication so DKIM aligns; that is what passes DMARC. Re-read Step 2.

"SPF permerror appeared after adding SendGrid." The include:sendgrid.net chain pushed you over 10 DNS lookups. Move SendGrid to a sending subdomain (Step 4) or flatten. Confirm the count with the SPF checker.

"Some SendGrid mail aligns, some does not." You likely have more than one sending identity: a separate subuser, Marketing Campaigns, or an inherited account that signs under a different d=. Authenticate every sending domain and subuser. Each must produce an aligned DKIM signature.

"CNAMEs will not verify." Most often a proxied Cloudflare record (set to DNS only / grey cloud), a doubled domain suffix, or a registrar that strips the trailing dot. Re-enter host labels only, unproxied, and wait for propagation.

"BIMI and the logo." Once you are at p=quarantine or p=reject with SendGrid aligned, you become eligible for BIMI, which can show your brand logo next to authenticated mail. Check readiness with the BIMI checker and read do you need BIMI.

A complete SendGrid example, end to end

For a domain sending transactional mail from app.yourdomain.com via SendGrid, a finished, aligned configuration looks like this:

; --- SendGrid Domain Authentication (Automated Security on) ---
em5678.app.yourdomain.com.          CNAME u9876543.wl210.sendgrid.net.
s1._domainkey.app.yourdomain.com.   CNAME s1.domainkey.u9876543.wl210.sendgrid.net.
s2._domainkey.app.yourdomain.com.   CNAME s2.domainkey.u9876543.wl210.sendgrid.net.

; --- SPF for the sending subdomain ---
app.yourdomain.com.                 TXT   "v=spf1 include:sendgrid.net ~all"

; --- DMARC, after monitoring, enforced ---
_dmarc.yourdomain.com.              TXT   "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

Mail sent as noreply@app.yourdomain.com is DKIM-signed with d=app.yourdomain.com, the signature aligns with the From: domain, SPF aligns through the custom return-path under app.yourdomain.com, and DMARC passes on both factors. Spoofed mail using your domain from anywhere else fails alignment and is rejected.

The practical takeaway

For SendGrid, three things carry you to enforcement, in order of importance:

1. Complete Domain Authentication so DKIM signs under your domain with selectors s1 and s2. This is the alignment that actually passes DMARC.
2. Add include:sendgrid.net to the relevant SPF record, mind the 10-lookup limit, and use the custom return-path if you want SPF to align too.
3. Publish DMARC at p=none, verify SendGrid aligns in reports, then move through quarantine to reject in stages, never in one jump.

Do those in order and SendGrid mail keeps flowing while spoofing of your domain stops. Start by checking what your domain reports today with the DMARC checker, SPF checker and DKIM checker. If you would rather not babysit the CNAMEs, the alignment, the lookup budget and the staged rollout yourself, our done-for-you DMARC service takes your domain from p=none to p=reject with SendGrid (and every other sender) aligned and continuously monitored, with no email outage along the way.