SendGrid asks for two domain keys, usually s1 and s2, so it can rotate DKIM keys without asking you to change DNS every time it changes the private signing key. One selector can actively sign mail while the other selector can be prepared, replaced, or allowed to age out across DNS caches and receiving mail systems.
That is the direct answer. The two records are not mainly about high availability, and they are not two different brands of authentication. They are two DKIM selectors. Each selector points to a public key location, and SendGrid controls the matching private key used to sign messages for your authenticated domain.
I treat the pair as a sign of sensible key lifecycle design. A single DKIM key can work technically, but it makes rotation clumsy. Two selectors let SendGrid move between keys while keeping old mail verifiable and new mail correctly signed.
The short answer
Why SendGrid asks for s1 and s2
SendGrid uses two DKIM selectors so it can rotate keys cleanly. It can sign with one selector while changing the other, then switch signing later. This reduces the operational risk of a compromised or old private key and avoids DNS changes for every rotation.A DKIM selector is the label before ._domainkey. If SendGrid signs a message with selector s1, the receiving server looks up the public key at the s1 DKIM DNS name for your domain. If it signs with s2, the receiver looks up the second selector instead.
- Main reason: Two selectors allow DKIM key rotation without a fragile same-day DNS change.
- Security benefit: Old private keys have a shorter useful lifetime if they are exposed later.
- Delivery benefit: Receivers can still verify messages signed with the previous selector during transition.
- Operational benefit: You publish stable CNAMEs once, and SendGrid manages the changing key material behind them.
SendGrid's own domain authentication setup commonly gives you CNAME records for two DKIM selectors. If you enable automated security, those CNAMEs point into SendGrid-controlled DNS, which is the part that makes provider-managed rotation practical.
How the two-key rotation works
The clean mental model is alternating selectors. SendGrid signs with one selector, updates the inactive selector's key behind the CNAME, waits for DNS and old messages to clear, then later signs with the refreshed selector. The inactive selector gives it somewhere to stage the next key without breaking verification for messages already in the wild.
Flowchart showing SendGrid alternating DKIM signing between s1 and s2 selectors.
|
|
|
|
|---|---|---|---|
January | s1 | s2 | Mail verifies against s1 while s2 can be prepared. |
Mid-cycle | s1 | s2 | Provider can replace the s2 public key target. |
February | s2 | s1 | Signing switches after the refreshed key has propagated. |
Next cycle | s2 | s1 | Provider can replace the s1 public key target. |
A simplified rotation example. Real timing depends on provider policy, DNS TTLs, and mail flow.
This is why deleting one of the two records often creates a future problem rather than an immediate one. Your current test can pass if SendGrid happens to be signing with the selector you kept. The failure appears later when signing changes to the selector you removed.
What the DNS records look like
With automated security, the records are normally CNAMEs rather than raw TXT records containing public keys. That is intentional. A CNAME lets SendGrid update the destination record it controls, while your DNS keeps pointing at the same stable name.
Example SendGrid DKIM CNAME recordsDNS
s1._domainkey.example.com. CNAME s1.domainkey.u123456.wl.sendgrid.net. s2._domainkey.example.com. CNAME s2.domainkey.u123456.wl.sendgrid.net.
Your actual target hostnames will differ. The important part is that each selector has exactly one DNS answer path. Do not try to put two different CNAME values at the same selector name. DNS does not allow a CNAME record to coexist with another record at the same owner name, and two competing CNAMEs for one selector is not a valid way to support two providers.
Do not merge the two selectors
Publish both records exactly as SendGrid provides them. If your DNS host complains, check whether you entered the full hostname twice, added the domain suffix twice, or tried to create duplicate CNAMEs at one selector name.
A quick check with a DKIM checker helps confirm that each selector resolves and returns usable DKIM key material through the CNAME chain.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Why one key is not enough operationally
One DKIM key can authenticate mail, but it is a brittle operating model for a provider sending at SendGrid scale. If there is only one selector, replacing the key means changing the only key receivers use to verify recently sent mail. DNS caches, retry queues, forwarding paths, and delayed delivery can all keep old messages around after the visible send event.
Single selector
- Rotation risk: Changing the only key can break verification for delayed or cached mail.
- DNS pressure: Every key change depends on timing, TTLs, and customer DNS correctness.
- Compromise window: A stale private key remains useful until the only published key changes.
Two selectors
- Rotation path: One selector signs while the other is refreshed and allowed to propagate.
- DNS stability: Customer DNS can stay stable while provider-controlled records change.
- Security posture: Regular rotation reduces the useful lifetime of exposed key material.
The security argument matters because DKIM private keys are powerful. If an old private key is copied from a backup, leaked from a storage bucket, or exposed through an internal process failure, an attacker can create mail that verifies against the matching public key. Rotation does not make key theft harmless, but it limits how long an exposed key remains useful.
This is also why I am more comfortable with per-domain keys than one shared key across many customers. A shared key can be simpler for an email service provider, especially in an older platform, but the blast radius is larger when that key leaks. Per-domain keys create more engineering work, yet they isolate customers better.
How SendGrid signs the message
A DKIM signature includes a selector tag. That tag tells the receiving server which DNS label to query. If the message contains s=s1, the receiver checks the s1 selector. If it contains s=s2, it checks the second selector. The domain tag should match the authenticated domain or a domain that has the same organizational domain as the visible From domain for DMARC.
Simplified DKIM-Signature headertext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:subject:date:to:mime-version; bh=base64-body-hash; b=base64-signature-data;
The signature does not say, "try both keys." It names one selector. That is why both DNS records must exist before SendGrid needs them. The second selector is a ready path, not a second guess by the receiver.
Twilio SendGrid domain authentication screen showing s1 and s2 DKIM CNAME records.
If you use a custom selector, SendGrid supports that in specific configurations, but custom selectors are a coordination choice. The default pair is simpler for most teams because the provider can keep its rotation process consistent. SendGrid documents custom DKIM selectors separately because the naming and ownership model matter.
How this affects DMARC domain matching
The presence of two SendGrid DKIM selectors does not weaken DMARC. DMARC does not care whether SendGrid used s1 or s2. It cares whether DKIM passes and whether the signing domain matches the domain in the visible From header.
- Selector: The selector tells the receiver where to find the DKIM public key.
- Signing domain: The domain in the DKIM signature is what DMARC checks against the visible From domain.
- Visible From: The domain users see in the From header must match SPF or DKIM domain identity.
- DMARC result: A passing DKIM signature with a matching domain can satisfy DMARC even if SPF fails.
The real failure pattern I watch for is not "two selectors caused DMARC to fail." It is usually a misconfigured authenticated domain, a missing CNAME, a subdomain mismatch, or a message stream still signing with a provider domain instead of your domain. A broader domain health check is useful when DKIM, SPF, and DMARC need to be checked together.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
This is where Suped's product fits the workflow well: it shows whether the SendGrid source is authenticated, whether DKIM has a matching domain, and which DNS records need attention. That saves time because you can separate normal SendGrid selector rotation from actual authentication failures.Common setup mistakes
Most SendGrid two-key problems come from DNS entry mistakes, not from the two-selector design itself. The same symptoms can look confusing because a provider dashboard can show one selector as verified while the other remains pending.
|
|
|
|---|---|---|
One key passes | Only one CNAME exists. | Add the missing selector. |
Both pending | DNS name entered wrong. | Remove duplicate domain suffix. |
DMARC fails | Signing domain mismatch. | Check From domain match. |
CNAME rejected | Record already exists. | Delete conflicting record first. |
Compact troubleshooting guide for SendGrid DKIM selectors.
If you are authenticating multiple sending tools on the same domain, avoid reusing the same selector names across providers. Give each provider its own selector names where the provider allows it, or use a sending subdomain to keep DNS ownership clean. The sibling issue is covered in more depth under multiple DKIM selectors.
The DNS rule that trips people up
One selector name can point to one CNAME target. If two platforms both ask for s1, do not stack both values. Change the selector where supported, or authenticate a separate subdomain.
What I would verify before sending volume
Before I let a SendGrid domain send meaningful volume, I want proof that both selectors resolve, that live mail signs with the expected domain, and that DMARC reports show a matching DKIM domain for the SendGrid source. The dashboard checkbox is helpful, but a real received message is better.
- Publish both records: Create both SendGrid DKIM CNAMEs exactly as shown in the setup screen.
- Check DNS resolution: Verify that each selector resolves through the expected CNAME chain.
- Send a real message: Inspect the DKIM-Signature header and confirm the signing domain matches your authenticated domain.
- Review DMARC data: Confirm SendGrid traffic shows DKIM pass and a matching domain before tightening policy.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
For ongoing monitoring, Suped's DMARC monitoring helps you catch the moment a source stops matching the From domain, a selector disappears, or a new sender starts using your domain. It is the practical layer above a one-time DNS check, especially when several teams or vendors send mail for the same domain.
Views from the trenches
Best practices
Publish both selectors and let the provider rotate inactive DKIM keys on a safe cadence.
Use CNAME-based DKIM when the sender manages rotation and key lifecycle for you.
Monitor DMARC reports after setup so selector issues show up before policy changes.
Common pitfalls
Keeping only one selector works briefly, then fails when the provider changes signing.
Stacking two CNAME targets on one selector creates invalid DNS and verification errors.
Assuming two selectors affect DMARC domain checks confuses key lookup with identity.
Expert tips
Treat per-domain keys as better isolation than one shared provider key for all tenants.
Check a real message header because dashboards can lag behind live signing behavior.
Rotate keys on a planned cadence so leaked old keys have a short useful lifetime.
Marketer from Email Geeks says SendGrid's two DKIM names looked redundant at first, but the reason became clear once they understood selector rotation.
2020-04-08 - Email Geeks
Expert from Email Geeks says two CNAME-backed selectors let a provider sign with one key while replacing the other key behind the scenes.
2020-04-08 - Email Geeks
The practical takeaway
SendGrid requires two domain keys because two selectors make DKIM key rotation safer and easier. The setup gives SendGrid room to move signing between selectors while it refreshes inactive keys, waits for DNS to settle, and keeps old mail verifiable during the transition.
Publish both records, do not combine them, and do not delete the one that looks unused today. If DMARC fails after setup, look at domain matching and live message headers rather than blaming the presence of two selectors.
Suped is the best overall DMARC platform for this kind of work because it connects the DNS view, the live authentication results, and the reporting history in one place. For SendGrid specifically, that means you can see whether the source is properly authenticated, whether DKIM uses a matching domain, and what to fix when it does not.
