SPF, DKIM & DMARC for SocketLabs.
SocketLabs authenticates your domain inside its On-Demand Portal, and its setup is genuinely different from a "paste this SPF line" provider. Every message you send is already SPF-authenticated and DKIM-signed the moment it leaves the platform — but by default that authentication belongs to SocketLabs' own domain, email-od.com, which is why unconfigured mail carries a "via email-od.com" note and can't align to your domain for DMARC. To make SocketLabs send as your domain, you add two records under Configuration → Domain Management: a Custom Bounce Domain CNAME (which moves the return-path onto your own subdomain so SPF aligns) and a DKIM record (a single CNAME, or a generated TXT selector, so DKIM signs as your domain). A separate DMARC policy completes the set. The important twist: SocketLabs' recommended SPF path is the bounce-domain CNAME, not adding include:email-od.com to your root SPF.
Why authenticate SocketLabs?
Authenticating SocketLabs isn't housekeeping — it decides whether your mail reaches the inbox at all. Since February 2024, Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume mail into Outlook.com/Hotmail in 2025. The catch specific to SocketLabs: out of the box it SPF-authenticates against its bounce domain email-od.com and DKIM-signs with d=email-od.com. Both checks PASS on email-od.com, but neither aligns to your From domain, so DMARC fails alignment, recipients see a "via email-od.com" tag, and the sending reputation you build pools with every other unauthenticated SocketLabs sender instead of accruing to your own domain. Setting up a custom bounce domain (SPF aligns) plus custom DKIM (DKIM aligns) closes that gap in two records — DMARC then passes on both mechanisms, the "via" tag disappears, and your domain owns its reputation.
The SPF reality for SocketLabs
SocketLabs is technically an "include" provider — include:email-od.com exists and DNS-verifies (it resolves to a single flat record, v=spf1 ip4:142.0.176.0/20 ip4:… ~all, with only ip4 ranges and no nested includes, so it would cost exactly ONE of your 10 SPF lookups) — but it is NOT SocketLabs' recommended SPF path and, on its own, it does not produce DMARC alignment. Here's why: SPF is evaluated against the return-path (bounce/envelope) domain, not your visible From address. By default SocketLabs' return-path is email-od.com, so the SPF check hits email-od.com's record and your root SPF is never consulted for SocketLabs mail. SocketLabs implements SPF instead through a Custom Bounce Domain: you publish a CNAME on a subdomain of your own domain — e.g. email.yourdomain.com CNAME tracking.socketlabs.com — and because tracking.socketlabs.com itself publishes v=spf1 include:email-od.com ~all, moving the return-path onto your subdomain both PASSES SPF (it inherits SocketLabs' whitelisted IPs through that CNAME) AND ALIGNS it to your organizational domain, all without editing your existing root SPF record. That's why the recommended setup adds zero lookups to your root SPF. The include:email-od.com mechanism is a belt-and-suspenders option: you can add it to your root SPF (it authorizes the sending IPs there too, at a cost of one lookup) but it does not give alignment by itself and isn't required once the custom bounce domain is in place. As always, keep exactly ONE SPF TXT record per domain — if you do add the include, merge it into your single v=spf1 line rather than publishing a second record.
Two ways to set it up
Custom Bounce Domain CNAME (recommended)
- Moves the return-path onto a subdomain of your domain, so SPF both passes and ALIGNS for DMARC
- Adds zero DNS lookups to your root SPF — there is nothing to merge or flatten
- The CNAME to tracking.socketlabs.com inherits SocketLabs' whitelisted IPs automatically; you never re-edit it when IPs change
- The same subdomain CNAME can be reused to white-label your open/click engagement-tracking links
include:email-od.com on your root SPF (optional)
- You add v=spf1 include:email-od.com ~all to your root SPF yourself
- Costs one of your 10 SPF DNS lookups (email-od.com is a flat ip4-only record, so exactly one)
- Authorizes the sending IPs under your domain but does NOT align SPF on its own — the return-path is still email-od.com unless you also set the bounce CNAME
- A supplement at best, never a substitute for the custom bounce domain
Step by step
- 1
Open Domain Management
Log in to the On-Demand Portal, click Configuration in the left-hand menu, choose Domain Management, then select the sending domain you want to authenticate (or click to add it). Everything below lives on this domain's card.
- 2
Start Custom Bounce Domain & SPF
On the domain, open "Custom Bounce Domain and SPF Authentication." SocketLabs generates a CNAME record on a subdomain of your domain (something like email.yourdomain.com or bounce.yourdomain.com) whose target is tracking.socketlabs.com. This is how SocketLabs implements SPF — it moves your return-path onto your own domain so SPF aligns.
- 3
Publish the bounce-domain CNAME
At your DNS host, create a CNAME: Host = the subdomain SocketLabs shows (e.g. email), Value = tracking.socketlabs.com. Do not change it to a TXT or A record, and do not touch your existing root SPF record — this CNAME is what carries SPF.
- 4
Choose your DKIM method
Back on the domain, open the DKIM section. You have two options: the CNAME DKIM Signing feature (easiest — SocketLabs owns and rotates the key for you) or the Advanced/TXT method via the DKIM Key Generator (you pick a selector and publish a public-key TXT record). Pick one; you do not need both.
- 5
Publish the DKIM record
For the CNAME method, add a CNAME: Host = dkim._domainkey, Value = dkim._domainkey.email-od.com. For the TXT method, add a TXT record at Host = <selector>._domainkey (the selector you chose in the generator, alphanumeric and under 10 characters) with the v=DKIM1; k=rsa; p=… value SocketLabs displays. Either way, DKIM will now sign as your domain.
- 6
Add the DMARC record
SocketLabs does not create DMARC for you. Add a TXT record at Host = _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so nothing about delivery changes while you confirm alignment — you'll tighten it later.
- 7
Verify in the portal
Return to Domain Management and click "Verify Bounce" for the custom bounce domain and "Verify" for DKIM. The bounce domain status should read authenticated and DKIM should read active. Propagation is usually minutes but SocketLabs can take up to 24–48 hours to confirm the records.
- 8
Send a test and read the headers
Send a message from an address on the configured domain to a Gmail account, open it, and choose ⋮ → Show original. You want SPF: PASS showing your bounce subdomain (not email-od.com), DKIM: PASS with d=yourdomain.com, and DMARC: PASS. The "via email-od.com" note should be gone.
Records to add
SocketLabs generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| CNAME | tracking.socketlabs.comCustom Bounce Domain — this is what carries and ALIGNS SPF. The subdomain label (email/bounce/…) is whatever SocketLabs assigns; reuse it for engagement-tracking white-labeling too. | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM (recommended, easiest) — SocketLabs owns and rotates the key. Selector is dkim; d= becomes your domain so DKIM aligns. |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)Alternative to the CNAME method — use the Advanced/TXT DKIM path only if you want to control the key. Selector (sl2026 here) is your choice: alphanumeric, under 10 chars. Illustrative value — the generator defaults to a 2048-bit key, generated per account. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself — SocketLabs never creates it. One per domain; start at p=none, then tighten to quarantine/reject. |
| TXT | @ | v=spf1 include:email-od.com ~allOPTIONAL belt-and-suspenders only. Not required if you set up the custom bounce domain, and it does not align SPF on its own. Costs 1 lookup; merge into your single root SPF line if you use it. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what SocketLabs's setup costs against that budget.
SocketLabs's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.
DKIM
SocketLabs signs every message by default, but with d=email-od.com, which doesn't align to your domain — so custom DKIM is what makes DKIM actually work for you, and there are two ways to set it up. The CNAME DKIM Signing feature is the easiest: you publish a single CNAME, Host = dkim._domainkey.yourdomain.com pointing to dkim._domainkey.email-od.com, and because it's a CNAME (not a key you paste) SocketLabs keeps control of both the private and public keys and rotates them for you — you never edit DNS again. The selector is simply dkim, and once verified SocketLabs signs your mail with d=yourdomain.com so DKIM aligns. The Advanced/TXT method gives you more control: in Domain Management you run the DKIM Key Generator, choose a selector (alphanumeric, fewer than 10 characters, e.g. sl2026), and SocketLabs generates the key pair — storing the private key in your account and handing you the public key to publish as a TXT record at <selector>._domainkey.yourdomain.com in the form v=DKIM1; k=rsa; p=…. The generator defaults to a 2048-bit key (a 1024-bit option exists, but leave it at 2048 — the stronger key is the modern standard and SocketLabs recommends not lowering it). There's also a "bring your own TXT record" variant where you supply an externally generated private key. A hard requirement of the TXT path: the portal will not let you save until it can resolve your published public key from DNS, and once saved the public key is no longer shown in the portal, so publish it first. One caveat that applies to BOTH methods: your custom DKIM signature is only applied to messages whose From address (the Purported Responsible Address) exactly matches the configured domain — mail sent from any other From domain falls back to the default email-od.com signature and won't align, so configure DKIM for every domain you send from.
DMARC
DMARC is a separate policy TXT record that SocketLabs does not create — you publish it yourself at your DNS host. Add a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm that SocketLabs mail is passing SPF and DKIM aligned to your domain. Because the custom bounce domain gives you SPF alignment and custom DKIM gives you DKIM alignment, a properly configured SocketLabs domain passes DMARC on BOTH mechanisms — the resilient setup that survives forwarding, since a forward that breaks SPF still leaves an aligned DKIM signature. Watch the reports for a week or two, make sure every legitimate sender (SocketLabs plus any other tools on the domain) is authenticating, then tighten the policy to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole organizational domain no matter how many senders you use; never add a second DMARC record just for SocketLabs.
Check it actually worked
Don't trust the portal's "authenticated" and "active" badges alone — confirm it on a real message. Send a test from an address on the configured domain to a Gmail mailbox, open it, and choose ⋮ → Show original: you want SPF: PASS showing your bounce subdomain (e.g. email.yourdomain.com, NOT email-od.com), DKIM: PASS with d=yourdomain.com, and DMARC: PASS. The tell-tale failure is SPF/DKIM still showing email-od.com, which means the bounce domain and/or custom DKIM aren't live yet, or you sent from a From domain that isn't configured. You can spot-check the raw records with dig CNAME email.yourdomain.com (should resolve to tracking.socketlabs.com), dig CNAME dkim._domainkey.yourdomain.com (or dig TXT <selector>._domainkey.yourdomain.com for the TXT method), and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm every record resolves cleanly, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — SocketLabs should appear as an aligned, fully-passing source.
Common gotchas
- Coverage
The default "via email-od.com" tag means you're not aligned yet: until you set up BOTH a custom bounce domain and custom DKIM, SocketLabs authenticates as email-od.com, so SPF and DKIM pass but DMARC fails alignment. The tag disappears only once both point to your domain.
- DNS setup
Adding include:email-od.com to your root SPF is NOT the fix on its own. It authorizes the sending IPs but the return-path is still email-od.com unless you publish the bounce-domain CNAME — and it's the bounce CNAME, not the include, that actually aligns SPF. Don't skip the CNAME thinking the include covers it.
- Coverage
Custom DKIM only signs mail whose From address exactly matches the configured domain (the Purported Responsible Address). Send from a different From domain and SocketLabs silently falls back to the default email-od.com signature, so DKIM won't align — configure every sending domain.
- DNS setup
Some DNS providers won't accept an underscore in a CNAME host, which blocks the dkim._domainkey CNAME method. If yours rejects it, use the Advanced/TXT DKIM path (DKIM Key Generator) instead — the public-key TXT record sidesteps the underscore-CNAME limitation.
- DNS setup
Cloudflare proxy breaks both CNAMEs: set the bounce-domain CNAME and the DKIM CNAME to "DNS only" (grey cloud). An orange-cloud proxied CNAME won't resolve to tracking.socketlabs.com / email-od.com and verification fails.
- Coverage
Subaccounts authenticate separately. SocketLabs' subaccount model means each subaccount needs its own custom bounce domain and DKIM authentication — authenticating the master account does not cover them.
- DNS setup
Verification can lag 24–48 hours. Propagation is usually minutes, but SocketLabs re-checks the CNAME/TXT on a delay, so "authenticated"/"active" may not flip immediately even when your DNS is already correct — verify with Show original rather than waiting on the badge.
- DNS setup
Host-field doubling: registrars that auto-append your domain turn dkim._domainkey.yourdomain.com into dkim._domainkey.yourdomain.com.yourdomain.com. Enter just the label (email, dkim._domainkey, <selector>._domainkey) if your panel adds the domain for you.
- Breaks auth
Keep exactly one SPF and one DMARC record per domain. If you add the optional include:email-od.com, merge it into your single v=spf1 line — two SPF records is a PermError, and so is a second _dmarc record.
Build your SPF record
SocketLabs doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSocketLabs SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.