SendLayer SPF and DKIM setup

What you are setting up

SendLayer is a transactional email service, most often wired up behind a WordPress site or an application that needs receipts, password resets, and form notifications to arrive. When you add a domain, SendLayer creates a dedicated sending subdomain for it, always starting with sl, as in sl.yourdomain.com, and sends every message through that subdomain so a deliverability problem cannot burn the reputation of your root domain. To authorize the domain you publish five DNS records: four CNAMEs and one TXT, each generated for your account, each with the sl subdomain in its hostname. SendLayer's glossary explains that its SPF, DKIM, and DMARC records all arrive as CNAMEs pointing at records SendLayer maintains, so it can rotate keys and update policies without you touching DNS again.

One honesty note before the records: SendLayer's documentation does not print the record values, the SPF include hostname, or the DKIM selector in text. They are generated per domain and shown only in your dashboard, so the values below are the shape, and your dashboard is the source.

Publish SPF and DKIM

Log in to SendLayer and click the orange Add Domain button at the top of the dashboard (or open the DOMAIN dropdown in the sidebar and choose Add new domain). Enter your domain and click Add Domain. SendLayer detects your DNS host and offers two paths. The one-click path is Connect With Cloudflare: log in to Cloudflare, review the records, click Authorize, and SendLayer adds them for you; back on the setup page, Verify DNS Connection checks propagation. The manual path is Setup DNS Manually, which lists the five records with a copy icon next to every hostname and value. If SendLayer did not recognize your host, use the choose your domain host link to pick it, or leave it on Other. The shape is:

Type:  CNAME
Host:  sl                    (SendLayer shows sl.yourdomain.com)
Value: (the target shown in your SendLayer dashboard)

Type:  CNAME
Host:  (a second name under sl.yourdomain.com, copy it from SendLayer)
Value: (the target shown in your SendLayer dashboard)

Type:  CNAME
Host:  (a third name under sl.yourdomain.com, copy it from SendLayer)
Value: (the target shown in your SendLayer dashboard)

Type:  CNAME   (DMARC for the subdomain, not for your root domain)
Host:  _dmarc.sl             (SendLayer shows _dmarc.sl.yourdomain.com)
Value: (SendLayer's own DMARC record)

Type:  TXT
Host:  (copy it from SendLayer)
Value: (copy it from SendLayer)

Add the TYPE, HOSTNAME, VALUE, and TTL exactly as SendLayer shows them. Two things trip people here. First, some DNS hosts append your domain to whatever you type in the hostname field, so the first record ends up at sl.yourdomain.com.yourdomain.com; SendLayer's own FAQ says to enter sl rather than sl.example.com when that happens, and the same trimming applies to every other hostname. Second, on Cloudflare the CNAMEs must be DNS only: turn the orange proxy cloud off for each one, because a proxied CNAME resolves to Cloudflare's edge and SendLayer cannot verify it. When the records are in, tick I have added these DNS records and am ready to proceed and click Verify DNS Records. SendLayer says to allow up to 24 to 48 hours for propagation, though it is usually far quicker.

Because the records are CNAMEs on a subdomain, your existing root-domain SPF record is untouched. There is no include: to merge and no lookup budget spent; SendLayer's SPF lives at the hostname it controls. The number of domains you can authorize depends on your SendLayer plan, with extra domains available as an add-on.

Add DMARC

Standard _dmarc TXT record on your root domain, and yes, you still need it even though SendLayer just gave you a DMARC record. Start in monitor-only mode and ramp up:

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

SendLayer's own DMARC article walks through exactly this record and says to publish it after the domain verifies, not before. Build it with our DMARC builder and progress past p=none once your reports show only genuine senders passing. Leave the adkim and aspf tags out entirely; the next section explains why.

The SendLayer gotcha

The DMARC record in your SendLayer dashboard is not your DMARC record. It lives at _dmarc.sl.yourdomain.com and is a CNAME to a policy SendLayer maintains: it quarantines mail that fails authentication on the sending subdomain, and its reporting addresses point back to SendLayer, not to you. That is fine for what it covers, but a receiving server checks DMARC on the domain in the visible From address. Your From address is you@yourdomain.com, so the server looks up _dmarc.yourdomain.com, and if nothing is there your mail has no DMARC policy at all. The subdomain record is never consulted. SendLayer's docs are unusually candid about this: the two records answer two different questions, you need both, and only the first is created for you. They coexist without conflict because they are different DNS names.

Strict alignment breaks SendLayer. SendLayer authenticates your mail on sl.yourdomain.com while your From address stays on yourdomain.com. Under DMARC's default relaxed alignment a subdomain counts as a match, so SPF and DKIM both align and the message passes. Add adkim=s or aspf=s to your root record and the subdomain stops counting; every SendLayer message then fails your own policy while SendLayer's dashboard still shows green checkmarks, because the records themselves are fine. If you inherited a DMARC record with strict tags, remove them before you move past p=none.

Confirm it worked

• Check the DNS Records & Settings tab. In SendLayer, go to Settings and open DNS Records & Settings. An authorized domain shows a green checkmark next to each of the five records in the STATUS column; Verify DNS Settings re-checks them on demand. A record stuck without a checkmark after two days almost always has the domain appended to its hostname or a Cloudflare proxy left on.
• Send a test and read the headers. Send through SendLayer, open the message at the other end, and confirm the DKIM signature and the Return-Path are on sl.yourdomain.com and the result is dmarc=pass for your root domain. Our header analyzer reads it back plainly and flags a strict-alignment mismatch if one is lurking.
• Watch the reports. SendLayer should appear in your DMARC aggregate reports as an aligned, passing source with sl.yourdomain.com as the authenticated domain, labeled as a known sender in trustyourinbox. If it shows as passing SPF and DKIM but failing DMARC, look for adkim=s or aspf=s in your record.