SPF, DKIM & DMARC for Sender.
Sender (sender.net) is an email-marketing and newsletter platform, and it authenticates your sending domain through a three-record flow you run under Account settings → Domains: a shared SPF include, a single DKIM CNAME, and a DMARC policy record. You add your domain, prove you own it by clicking a link Sender emails to an address on that domain, and Sender then shows the exact SPF, DKIM, and DMARC records to publish at your DNS host. Once all three verify — three green checkmarks in Sender's Authentication column — your campaigns go out as your own domain: SPF-authorized, DKIM-signed with d=yourdomain.com, and DMARC-aligned, instead of drawing a "via sender.net" note or sliding into spam.
Why authenticate Sender?
Authenticating your Sender domain isn't housekeeping — for a bulk marketing platform it's the difference between the inbox and the spam folder. Since February 2024, Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, publish a valid DMARC policy of at least p=none, and offer one-click unsubscribe; Microsoft began enforcing the same on high-volume mail to Outlook.com/Hotmail in 2025. Newsletters and promotional blasts are exactly the mail these rules target. Until you authenticate, Sender sends on shared infrastructure that isn't cryptographically tied to your domain: recipients may see a "via" note, your From address doesn't align, DMARC can't pass, and your reputation is pooled with every other unauthenticated sender on that platform. Completing SPF + DKIM + DMARC signs each campaign as d=yourdomain.com, lets DMARC pass, removes the "via" tag, and means the sending reputation you build accrues to your own domain — which is what protects your open rates over time.
The SPF reality for Sender
Sender is a genuine "include" provider — but the mechanism is include:sendersrv.com, NOT include:sender.net. This trips people up constantly: sender.net is the company's website, and it does not resolve as a valid SPF include, so anything built around it hard-fails. The real shared include every Sender customer adds is include:sendersrv.com, published inside the single SPF TXT record on your root domain. Sender's own docs show the full record as v=spf1 include:sendersrv.com ?all — note the neutral ?all qualifier, which is a tell about how Sender's SPF actually works. Two things matter here. First, the include is NOT flat: sendersrv.com's SPF record nests include:_spf.mx.cloudflare.net, so include:sendersrv.com costs TWO of your 10 allowed DNS lookups (RFC 7208), not one — worth watching if you already stack Google Workspace, Microsoft 365, or other senders. Second, and more important: like most marketing ESPs, Sender owns the envelope/Return-Path — your campaigns bounce to Sender's own domain, and it's that domain that gets SPF-checked. So the include:sendersrv.com you publish on YOUR root does not produce SPF alignment for DMARC; it authorizes Sender's servers and satisfies Sender's checker, but the mechanism that actually carries your DMARC pass is DKIM (the CNAME below signs as d=yourdomain.com). That's why Sender is comfortable recommending ?all. Publish the include — Sender's Authentication check looks for it and it's part of the required trio — but understand DKIM is the load-bearing record. And keep exactly one SPF TXT on your domain: if a v=spf1 record already exists, merge include:sendersrv.com into it rather than adding a second SPF record (two SPF records is a PermError).
Step by step
- 1
Open the Domains section
Log in at app.sender.net and go to Account settings → Domains. Click the Add domain button (top-right) to start authenticating a new sending domain.
- 2
Enter your sending domain
Type the domain you'll send campaigns from (e.g. yourdomain.com — the domain in your From address, not a subdomain unless you send from one) and click Next.
- 3
Verify domain ownership
Enter an email address on that domain and click Verify ownership — Sender emails a confirmation link to that inbox. Open it and click the link; a green check then appears in the Ownership confirmed column. The SPF, DKIM, and DMARC records do NOT appear until ownership is confirmed. This is a required first gate, separate from DNS.
- 4
Open the DNS records dialog
Back in Domains, click the domain row to open the dialog titled 'Authenticate your SPF, DKIM and DMARC records.' Sender shows three records — each with a Type, Name, and Value — that you copy to your DNS host.
- 5
Add or merge the SPF record
At your DNS host add a TXT record on the root (Name @): v=spf1 include:sendersrv.com ?all. If a v=spf1 record already exists (Google, Microsoft 365, another tool), do NOT add a second one — merge include:sendersrv.com into the existing line, keeping your own qualifier (usually ~all or -all) rather than downgrading to ?all.
- 6
Add the DKIM CNAME
Create a CNAME record: Name sender._domainkey, Value dkim.sendersrv.com. This is a CNAME, not a TXT — there is no key to paste. If your DNS is on Cloudflare, set the record to DNS only (grey cloud); an orange-cloud proxy breaks CNAME resolution and DKIM verification fails.
- 7
Add the DMARC record
Add a TXT record at Name _dmarc. Sender's default is a bare v=DMARC1; p=none; — publish it, but add a reporting address so you actually learn something: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it changes nothing about delivery while you confirm alignment.
- 8
Run the authentication check
Return to Domains and click the recheck button (labeled Recheck DNS records / Check SPF, DKIM and DMARC records). When all three resolve you'll see three green checkmarks in the Authentication column. Propagation is usually minutes but can take up to 24–48 hours; re-check if a record isn't green yet.
- 9
Send a test and read the headers
Send yourself a test campaign, open it in Gmail, and choose ⋮ → Show original. You want SPF: PASS, DKIM: PASS signed by yourdomain.com (selector sender), and DMARC: PASS — DKIM d=yourdomain.com is the tell that Sender is signing as you, not on the shared domain.
Records to add
Sender generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:sendersrv.com ?allRoot SPF — it's sendersrv.com, NOT sender.net. Keep exactly ONE SPF record; merge this include into any existing v=spf1 line and keep your stricter qualifier (~all/-all). Costs 2 DNS lookups (it nests a Cloudflare include). |
| CNAME | sender._domainkey | dkim.sendersrv.comDKIM — a CNAME, not a TXT key. Same fixed 'sender' selector for every account; Sender hosts and rotates the key. Set to DNS only (grey cloud) on Cloudflare. This is the record that carries your DMARC pass. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comSender's default is a bare p=none placeholder — add a rua reporting address and keep one DMARC record per domain. Start at p=none, then ramp to quarantine/reject. |
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 Sender's setup costs against that budget.
Sender adds 2 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM for Sender is a single CNAME, not a TXT key you paste. You add one record — Name sender._domainkey, Value dkim.sendersrv.com — and that's it. Because it's a CNAME delegated back to Sender's infrastructure, Sender holds the private key and serves the public key on its side (dkim.sendersrv.com currently publishes a 1024-bit RSA key), so it can rotate keys centrally without you ever touching DNS again. There's no key to copy and the selector is fixed at sender for every account. What makes this record the important one: Sender owns the envelope/Return-Path, so SPF doesn't align to your domain — but DKIM does. When Sender signs your campaign it uses d=yourdomain.com with selector sender, and because the CNAME lets receivers fetch the key under your domain, DKIM aligns and carries your DMARC pass. That means the DKIM CNAME is the record you cannot skip. Two practical notes: if your DNS is on Cloudflare, the record must be DNS only (grey cloud) — a proxied CNAME won't resolve to dkim.sendersrv.com and verification fails; and because the selector is a fixed shared sender, the key is common to all customers (functionally fine for alignment, but it's a 1024-bit key you can't upgrade yourself).
DMARC
DMARC is a separate policy record you publish yourself, and Sender's default value is deliberately minimal — v=DMARC1; p=none; with nothing else. Publish it at _dmarc.yourdomain.com, but don't leave it bare: add a reporting address so the record actually does something, e.g. v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only — it changes nothing about delivery while receivers email you aggregate (rua) reports showing whether your Sender campaigns (and every other sender on the domain) pass SPF and DKIM aligned to you. For Sender that alignment comes through DKIM (d=yourdomain.com, selector sender), so once the CNAME is live you should see clean DKIM-aligned passes. Watch the reports for a week or two, confirm every legitimate sender authenticates, then tighten the policy to p=quarantine and eventually p=reject — that's the step that actually stops spoofing. Keep exactly one _dmarc record for the whole organizational domain no matter how many tools you send from; never add a second DMARC record specifically for Sender.
Check it actually worked
Don't trust the three green checkmarks in Sender's Authentication column alone — confirm it on a real message. Send a test campaign to yourself, open it in Gmail, and choose ⋮ → Show original: you want SPF: PASS, DKIM: PASS, and DMARC: PASS, with the DKIM signature showing d=yourdomain.com and selector sender (if DKIM signs as sendersrv.com or the CNAME hasn't resolved, the record isn't live yet). You can also spot-check the raw records with dig TXT yourdomain.com (SPF), dig CNAME sender._domainkey.yourdomain.com (should return dkim.sendersrv.com), and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm all three records resolve and your SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Sender should appear as a DKIM-aligned, passing source.
Common gotchas
- DNS setup
It's include:sendersrv.com, NOT include:sender.net. sender.net is the company website and doesn't resolve as an SPF include — publishing it makes SPF fail. Every Sender customer uses the same include:sendersrv.com.
- DNS setup
The DKIM CNAME breaks behind a Cloudflare proxy. sender._domainkey → dkim.sendersrv.com must be DNS only (grey cloud); an orange-cloud proxied CNAME won't resolve and DKIM verification fails — the most common reason records verify everywhere except in a real inbox.
- DNS setup
The SPF include costs 2 DNS lookups, not 1. sendersrv.com's SPF record nests include:_spf.mx.cloudflare.net, so it isn't flat — factor both into the RFC 7208 10-lookup limit if you also stack Google Workspace, Microsoft 365, or other senders.
- Coverage
Sender documents a neutral ?all qualifier. When you merge include:sendersrv.com into an existing root SPF, keep your own stricter qualifier (~all or -all) — don't downgrade the whole record to ?all just because Sender's example does.
- DNS setup
Your DMARC pass rides on DKIM, not SPF. Sender owns the Return-Path, so the include:sendersrv.com on your root doesn't align — the DKIM CNAME (d=yourdomain.com) is what carries DMARC. If you only had time for one record, it's the CNAME.
- DNS setup
Verify domain ownership first. Sender emails a confirmation link to an address on the domain, and the SPF/DKIM/DMARC records don't appear until you click it — publishing DNS before that step gets you nowhere.
- Coverage
Don't leave DMARC at the bare p=none placeholder. Sender's default has no rua and no teeth — add a reporting address and ramp toward p=reject, or the record protects nothing.
- Coverage
The 'sender' DKIM selector and key are shared and fixed. You can't rename the selector or upgrade the (1024-bit) key yourself; it's fine for alignment, but if something else on your domain already uses sender._domainkey it would collide (rare).
Build your SPF record
Sender is pre-selected below. Add any other platforms you send through, then publish the single merged record.
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).
- 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 listSender 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.