SocketLabs SPF and DKIM setup

What you are setting up

SocketLabs sends your transactional and marketing email from its own infrastructure. Out of the box, every message is DKIM-signed as email-od.com and carries a Return-Path on email-od.com, so it passes SPF and DKIM but neither result aligns with your domain, and recipients see “via email-od.com” next to your name. You fix that with three DNS records: an SPF include, a DKIM record for your domain, and a custom bounce domain CNAME that moves the Return-Path onto your domain.

Publish SPF and DKIM

SocketLabs’ only SPF requirement is that include:email-od.com appears in your record. The include adds no lookups beyond itself. Then create a subdomain for bounces and point it at SocketLabs:

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:email-od.com ~all

Type:  CNAME   (custom bounce domain)
Host:  bounces
Value: tracking.socketlabs.com

Register bounces.yourdomain.com as a custom bounce domain in the SocketLabs Control Panel once the CNAME resolves. You can add several, and SocketLabs matches each From address to the bounce domain on the same domain. If none matches, it falls back to your default entry or to email-od.com.

For DKIM, SocketLabs offers two routes. The simplest is a single CNAME, which lets SocketLabs hold and rotate the key:

Type:  CNAME   (DKIM)
Host:  dkim._domainkey
Value: dkim._domainkey.email-od.com

If your DNS host refuses an underscore in a CNAME name, or you want to own the key, use the TXT route instead: the SocketLabs DKIM key generator asks for a selector (alphanumeric, ideally under ten characters), gives you the public key to publish as a TXT record at yourselector._domainkey, and stores the private key on your account. You can also bring a key pair you generated yourself. Either way the Control Panel will not save the setting until it can read the public key at your domain and selector.

Add DMARC

Standard _dmarc TXT record, nothing SocketLabs-specific. Start in monitor-only mode and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean.

The SocketLabs gotcha

The SPF include alone does not align. Receivers check SPF against the Return-Path domain, not your From address. Until you register a custom bounce domain, that Return-Path is email-od.com, so SPF passes for SocketLabs and fails alignment for you. The bounce CNAME is what puts a subdomain of your domain in the Return-Path, and because it is a CNAME to tracking.socketlabs.com (which publishes its own SPF record) you neither need nor can add a TXT record at that name. Keep the include on your apex anyway; it is SocketLabs’ stated requirement and costs nothing. The second trap is exact-match signing: SocketLabs applies your DKIM signature only when the From domain exactly matches the domain you configured, so a subdomain that also sends (news.yourdomain.com) needs its own DKIM entry and its own bounce domain, or it falls back to email-od.com for both. And if the DKIM CNAME sits unverified, check that your DNS host did not append your domain a second time; the name must be exactly dkim._domainkey.yourdomain.com.

Confirm it worked

• Verify in SocketLabs. The Control Panel checks the bounce CNAME and the DKIM record before it lets you enable either; allow up to 48 hours for DNS propagation, though it usually takes minutes.
• Send a test and read the headers. Send through SocketLabs and confirm the Return-Path is on bounces.yourdomain.com, the DKIM signature shows d=yourdomain.com, and the “via” label is gone. Our header analyzer reads it back plainly.
• Watch the reports. SocketLabs should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.