SendGrid Domain Authentication makes your emails pass SPF and DKIM by having you publish three CNAME records on a delegated subdomain like em1234.yourdomain.com. SendGrid signs each message with a DKIM key that aligns to your root domain, and it routes the Return-Path through that subdomain so SPF passes there instead of on your root record. What SendGrid does not do is create a DMARC record, so authentication is only half finished until you add one yourself.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
This guide decodes the em1234 delegated-subdomain model, contrasts Automated Security (SendGrid manages the records behind CNAMEs) with Manual mode (you paste raw TXT records), and explains why the delegated subdomain keeps your root SPF untouched. Then it walks through adding a real DMARC policy and confirming the CNAMEs resolve.
What SendGrid actually asks you to publish
When you run Domain Authentication in the SendGrid dashboard (Settings, then Sender Authentication), it generates a small set of CNAME records. With the default Automated Security turned on, you get something close to this:
em1234.yourdomain.com CNAME u1234.wl.sendgrid.net
s1._domainkey.yourdomain.com CNAME s1.domainkey.u1234.wl.sendgrid.net
s2._domainkey.yourdomain.com CNAME s2.domainkey.u1234.wl.sendgrid.net
The numbers are unique to your account, so treat 1234 as a placeholder and copy the exact values from your own console. Three records do three jobs. The em1234 record is the branded sending subdomain that becomes your Return-Path, which is where SPF gets evaluated. The two s1 and s2 selector records are DKIM. SendGrid uses two selectors so it can rotate signing keys between them without an outage.
If you also turn on Link Branding, you get one or two more CNAMEs (often url1234 and 1234) that rewrite click-tracking links to your domain instead of sendgrid.net. That is a deliverability and trust improvement, not an authentication requirement, but it is worth doing at the same time.
Why the delegated subdomain leaves your root SPF alone
This is the part that confuses people coming from other senders. You do not add include:sendgrid.net to your root domain's SPF record. You never touch your root SPF at all.
Here is the mechanism. Every message SendGrid sends uses an envelope sender (the Return-Path, also called MAIL FROM) on the em1234.yourdomain.com subdomain, not on your root domain. SPF is always checked against the envelope sender's domain, so receivers look up SPF for em1234.yourdomain.com. Because that name is a CNAME to SendGrid, the lookup follows through to SendGrid's own SPF record, which lists their sending IPs and ends in a hard or soft fail. SPF passes on the subdomain, and your root v=spf1 record is completely uninvolved.
That design has a real benefit: it keeps SendGrid's IP ranges out of your root SPF, so it cannot push you toward the ten-lookup ceiling that breaks so many records. If you have ever had to fix an SPF record with too many DNS lookups, you will appreciate that SendGrid's model sidesteps the problem entirely. Your root SPF still governs mail sent from your own servers and other providers, and SendGrid mail authenticates on its own subdomain.
How alignment still passes for DMARC
DMARC does not just want SPF or DKIM to pass. It wants at least one of them to pass and to be aligned with the domain in the visible From header. SendGrid gives you two aligned paths.
DKIM signs with d=yourdomain.com (your root), so DKIM aligns directly. SPF authenticates on em1234.yourdomain.com, which is a subdomain of your root, so under relaxed alignment (the DMARC default) the organizational domains match and SPF aligns too. You get both a passing, aligned DKIM signature and a passing, aligned SPF result. If you want the full mental model of how these interact, see SPF, DKIM and DMARC explained and the deeper dive on fixing DKIM alignment.
Automated Security versus Manual: what really differs
SendGrid presents a toggle called Automated Security during setup, and it changes what you publish.
Automated Security ON (CNAME, the default)
You publish CNAMEs that point at SendGrid. The actual DKIM public keys and SPF values live on SendGrid's side, behind those CNAMEs. The advantage is key rotation: SendGrid can retire an old DKIM key and bring up a new one on the s1 or s2 selector without asking you to edit DNS. Your records keep pointing at the same CNAME target, and the value it resolves to changes underneath you. For almost everyone, this is the right choice. It is the same reasoning behind preferring DKIM as a CNAME rather than a TXT record with hosted senders.
Automated Security OFF (Manual TXT)
You publish raw TXT records instead: an SPF TXT record on the mail subdomain and a single DKIM public-key TXT record that you own outright. Nothing resolves through SendGrid, so you see the exact values. The cost is that any future DKIM key rotation becomes a manual DNS change you have to perform, and if SendGrid rotates on their schedule and you have not updated the TXT record, signatures start failing. Choose Manual only if your DNS provider cannot create CNAMEs at those hostnames, or if a security policy forbids delegating record content to a third party.
Either way, the resulting authentication is equivalent when correctly published. The difference is purely who maintains the key material over time.
Add the DMARC record SendGrid will not create
SendGrid authenticates your mail, but it does not publish a DMARC policy, and DMARC is what actually tells receivers what to do with mail that fails. Without it you have no policy, no reporting, and no protection against spoofing. Google and Yahoo now require a DMARC record for bulk senders, so this is not optional if you send volume. See the Google and Yahoo sender requirements for the current thresholds.
Start in monitoring mode so you can watch reports before enforcing anything:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"
p=none collects data without affecting delivery. The rua address receives daily aggregate reports so you can confirm SendGrid mail is aligning before you tighten the policy. The relaxed alignment tags (adkim=r, aspf=r) match how SendGrid's subdomain model aligns, so leave them relaxed. Once reports show SendGrid and your other legitimate sources passing, move to p=quarantine and then p=reject. The full progression is covered in how to set up DMARC and moving DMARC from none to reject.
Confirm the CNAMEs resolve before you send
DNS changes and SendGrid's own verification can lag by anything from minutes to a full day, depending on your provider's TTL. Do not trust the green checkmark alone. Run your domain through the scanner above to confirm the DKIM selectors are live and DMARC is present, and check the CNAMEs from the command line:
dig +short s1._domainkey.yourdomain.com CNAME
A correct result returns the s1.domainkey.u1234.wl.sendgrid.net target. Repeat for s2._domainkey and for em1234. Common failure modes: a DNS host that silently appends your domain to an already-fully-qualified target (producing ...sendgrid.net.yourdomain.com), or a proxy or CDN that flattens or hides the CNAME. If the checker shows DKIM passing and DMARC present, send one test message and read the Authentication-Results header to confirm both dkim=pass and spf=pass with your root domain in alignment.
Frequently asked questions
Do I need to add include:sendgrid.net to my SPF record?
No. With standard Domain Authentication, SendGrid uses a Return-Path on your em1234 subdomain, and SPF is evaluated there through the CNAME. Your root SPF stays untouched, which also keeps you clear of the ten-lookup limit. Only add a SendGrid include if you have deliberately configured a custom setup that sends from your root envelope domain.
What is the difference between the s1 and s2 DKIM selectors?
They are two DKIM signing keys. SendGrid uses a pair so it can rotate one key while the other stays active, avoiding a window where mail is unsigned. With Automated Security on, this rotation happens behind the CNAMEs without any DNS change on your side. Both selectors must resolve for authentication to stay healthy.
Does SendGrid set up DMARC for me?
No. SendGrid handles SPF and DKIM through the CNAMEs, but it never publishes a DMARC record. You must add _dmarc.yourdomain.com yourself. Start at p=none to gather reports, confirm SendGrid mail aligns, then advance to quarantine and reject.
Should I use Automated Security or Manual mode?
Use Automated Security (the CNAME option) unless your DNS provider cannot create those CNAME hostnames or policy forbids delegating record values. Automated Security lets SendGrid rotate DKIM keys without you editing DNS. Manual TXT mode gives you full ownership of the key material but makes every future rotation a manual task you cannot forget.