Understanding SendGrid Domain Authentication
The Three Pieces: SPF, DKIM, and DMARC
Email authentication rests on three standards. You don’t need to memorize the acronyms — just understand what each one does.
SPF (Sender Policy Framework) is a published list of servers that are allowed to send email for your domain. When a receiving server gets a message claiming to be from [email protected], it checks your SPF record to confirm the sending server is on the approved list.
DKIM (DomainKeys Identified Mail) is a cryptographic signature attached to every email. Your domain publishes a public key in DNS, and SendGrid signs outgoing messages with the matching private key. Receiving servers use the public key to verify that the message hasn’t been tampered with and really did come from an authorized sender.
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties the first two together. It tells receiving servers what to do if an email fails SPF or DKIM (accept it anyway, send it to spam, or reject it outright), and it gives you reports on who’s trying to send email as your domain.
Think of it this way: SPF says “this server is allowed to speak for me,” DKIM says “and here’s a signature proving the message wasn’t altered,” and DMARC says “here’s what to do if something doesn’t add up.”
How SendGrid Handles It
SendGrid simplifies the setup using an approach called Automated Security. Instead of you managing individual SPF and DKIM records directly, SendGrid creates a small set of CNAME records that point back to SendGrid’s infrastructure.
Here’s what happens under the hood:
You tell SendGrid the domain you want to send from (for example, yourdomain.com).
SendGrid generates a set of DNS records — typically three CNAMEs (one for the return path and two for DKIM selectors) — tied to a subdomain like em1234.yourdomain.com.
You publish those records at your DNS provider (GoDaddy, Cloudflare, Route 53, whoever hosts your domain).
SendGrid verifies the records are live, and from that point on it manages the underlying SPF and DKIM values on your behalf. If anything needs to rotate or update, it happens automatically — you don’t have to touch DNS again.
The beauty of this setup is that you’re delegating email authentication management to SendGrid through CNAME records, rather than copy-pasting raw SPF and DKIM values yourself. Fewer moving parts, fewer things to break.
What You’ll Need to Do
The actual work on your end is small but important. You’ll receive a set of DNS records from LASSO that look something like this:
Type | Host | Value |
CNAME | em1234.yourdomain.com | u1234567.wl123.sendgrid.net |
CNAME | s1._domainkey.yourdomain.com | s1.domainkey.u1234567.wl123.sendgrid.net |
CNAME | s2._domainkey.yourdomain.com | s2.domainkey.u1234567.wl123.sendgrid.net |
Your DNS administrator (or whoever manages your domain) needs to add these exactly as provided. Three things to watch for:
Copy values precisely. A single typo or extra character breaks verification.
Don’t add a trailing dot unless your DNS provider requires one. Some providers add it automatically.
Skip duplicate entries. If a record with the same host already exists, check with us before overwriting it.
Once the records are in place, click the “Request Domain Validation from Sendgrid” in LASSO. Most DNS providers propagate changes within a few minutes, though the standard guidance is to allow up to 48 hours in rare cases. (So you may have to wait to verify)
DMARC: The Recommended Next Step
DMARC isn’t strictly required to start sending, but major inbox providers now expect it for bulk senders, and it’s strongly recommended. It’s a single TXT record at _dmarc.yourdomain.com that tells receiving servers how to handle messages that fail authentication and where to send reports.
A safe starting DMARC policy looks like this:
v=DMARC1; p=none; rua=mailto:[email protected]
This sets a “monitor only” policy — nothing gets blocked, but you start collecting reports showing who’s sending email as your domain. Once you’ve confirmed everything legitimate is authenticating properly, you can tighten the policy over time to quarantine and eventually reject.
Work with your IT admin on DMARC setup once domain authentication is in place.
Additional FAQ for Domain Masking
Q: The domain masking is working for some users, but not others. What is happening?
If the users have different email domains, both email domains will need to be set up for masking.
Example: the company email domain is [email protected], but some users are using a personal email that uses a different domain, such as [email protected]. Both domains need to be set up for domain masking.
Any additional emails that will be sending emails from LASSO will also need their email configured for domain masking.