Sender SPF, DKIM and DMARC setup, step by step

To authenticate a native Sender.net campaign domain, open Account settings → Domains, add the domain and confirm ownership through an associated working email address. Publish the account's DNS records, preserving existing SPF and DMARC policies, then run Sender's authentication check. Its current setup guide publishes the DKIM CNAME sender._domainkey → dkim.sendersrv.com and SPF authorization include:sendersrv.com. Successful DNS verification is a checkpoint, not proof that a delivered campaign carries your intended aligned signature.

This guide covers Sender.net's native campaign domain-authentication workflow. It does not configure transactional SMTP credentials, API requests, custom tracking links or mailbox hosting. The current native setup instructions and account-generated records govern the steps below.

Before you change Sender or DNS

You need an active Sender account, access to its domain settings, a domain you own or manage, a working address on that domain and permission to change the actual authoritative DNS zone. The current native guide does not establish a named plan tier or a universal administrator-role label. If you cannot access the controls, have your account administrator resolve access rather than switching products or inventing a permission setting.

Agree the campaign's intended visible From address with the domain owner. Inventory current SPF authorizations, DKIM selectors, delegated namespaces, direct and inherited DMARC policy, authorized report recipients and existing campaign sender settings. Save a recoverable record of the current configuration and arrange a controlled change window. A new marketing sender must not silently displace employee mail, another campaign service or established enforcement.

Use an address on a domain you control. You cannot authenticate a public provider's domain merely by entering a Gmail or Yahoo address. This process also does not create a mailbox for the address that receives Sender's ownership email.

Keep the ownership paths separate. Sender's transactional identity article describes DNS-based ownership verification, whereas its native setup page and Add domain illustration require an associated email address. Do not combine those instructions into a fictional universal procedure. Follow the native campaign path below; if your account instead presents a different workflow, confirm its applicability with Sender Support before proceeding. This guide does not prescribe transactional activation or API/SMTP credentials.

1. Add the campaign domain and verify ownership

1. Open Account settings → Domains.
2. Click Add domain. Enter the domain, not a complete email address, in Domain, then click Next.
3. Enter an existing associated address in Email and click Verify ownership.
4. Open Sender's verification email in that mailbox and follow its verification link.
5. Return to Domains and confirm the checkmark under Ownership confirmed for the intended domain.

The ownership email proves control through that account workflow; it does not publish DNS or prove DKIM signing. If the email does not arrive, check the address and mailbox handling before modifying unrelated DNS. Do not change MX or forwarding just to make an ownership check pass without a separately approved mailbox-routing plan.

Sender's verification companion uses shorter labels such as Settings, Add, and Check SPF/DKIM Records. The fuller native guide uses the labels above. These are documented interface variations, not extra required buttons. Use the equivalent current control in your account and escalate a materially different sequence.

2. Open and preserve the account's DNS instructions

After ownership confirmation, click the domain row to open Authenticate your SPF, DKIM and DMARC records. Some documented views expose Set up DNS records beside the domain. Copy each full Type, Name and Value, not a truncated screenshot field. The parameters guide also directs you to the domain-specific values in Settings.

The current public native example is:

DKIM: CNAME sender._domainkey dkim.sendersrv.com TTL 3600
SPF: TXT @ v=spf1 include:sendersrv.com ?all
DMARC: TXT _dmarc v=DMARC1; p=none;

The setup article specifies SPF TTL 3600 and DMARC TTL 300. Compare these published parameters with the actual domain dialog before using them. If they differ, obtain a current account-specific explanation rather than replacing working records to match this example.

This is not a three-record overwrite instruction. SPF usually requires an edit to an existing policy, and an applicable DMARC policy may already protect the domain. The Custom links column is a separate feature; its Set up control is not the SPF/DKIM authentication check. Do not introduce tracking changes into this task.

3. Merge Sender's SPF authorization without losing other mail

The Sender authorization component is:

include:sendersrv.com

SPF evaluates the SMTP MAIL FROM domain, or HELO in the applicable empty-envelope case, not automatically the visible From. Sender's example places its policy at the authenticated domain's apex, but the cited pages do not guarantee a universal runtime Return-Path. Follow the account's supported domain instructions, confirm which customer-controlled owner is being evaluated and inspect the actual message later. Do not invent a bounce domain or edit a provider-owned SPF policy.

Read the existing TXT records at the correct owner. Maintain one v=spf1 policy there. Add the Sender include before a terminating all, preserving all legitimate authorizations, intentional ordering and the approved qualifier. Do not add a second SPF record or copy the demonstration policy over another sender's authorizations. The EmailAuth guide to multiple SPF records explains why duplicate policies need reconciliation rather than another TXT entry.

The published ?all means neutral, not softfail or hardfail. It does not declare unmatched senders unauthorized in the same way as -all. Do not silently change an existing ~all, -all or redirect-based policy to match this example. If there is no policy, have the domain owner approve a complete initial policy covering all legitimate senders and its qualifier; Sender's single-service sample is not an inventory of your other mail.

Evaluate the entire dependency chain against SPF's maximum ten evaluated DNS-dependent terms, including nested mechanisms. This is not a ten-visible-includes allowance. An all mechanism makes redirect ignored, so inserting all into an existing redirect policy can change its meaning. Neither a qualifier nor SPF pass guarantees delivery. These distinctions follow RFC 7208.

For evaluated domain example.com, the full SPF TXT owner is example.com, commonly entered as @ in that zone. For news.example.com, it is relative news in the parent zone or @ in a separately delegated news.example.com zone. Use those examples only for the actual approved domain, not as an assumption that every account supports every subdomain arrangement.

4. Publish the exact DKIM CNAME at its authoritative owner

For the current published setup, the alias target is dkim.sendersrv.com. For signing domain example.com, the full owner is sender._domainkey.example.com, relative sender._domainkey within example.com.

If the approved authenticated signing domain is news.example.com, the corresponding full owner is sender._domainkey.news.example.com:

• In the parent example.com zone, use relative sender._domainkey.news.
• In a separately delegated news.example.com zone, use relative sender._domainkey.
• If _domainkey.news.example.com itself is delegated, the owner within that authoritative zone is relative sender.

An editor accepting full names may instead require the complete owner. Inspect the resulting fully qualified name so the zone suffix is not appended twice. Keep the target as the complete provider hostname; do not append your domain to it. Preserve existing NS delegation and other active selectors. Publishing below a delegated zone in its parent does not override the child authority.

At the alias owner, check for conflicting TXT, A, AAAA, MX or another CNAME before saving. If sender._domainkey is already used by another service, stop and reconcile ownership with the affected service and Sender. Do not delete a working key or delegation merely to clear a warning. A CNAME is not interchangeable with a TXT public key, and the target does not belong inside SPF.

Keep the record DNS-only rather than HTTP-proxied. If flattening would hide the required literal alias, switch off the applicable per-record flattening control when available and ensure relevant zone-wide, apex and same-zone behavior does not suppress it. Do not disable unrelated global features. If mandatory DNS-host behavior cannot preserve the CNAME answer, stop and coordinate a supported configuration rather than inventing a switch or deleting shared dependencies.

Sender performs the private-key signing. You do not need to generate a private key, paste a screenshot key or upload a secret to DNS for this CNAME workflow. At the target, verification must reach the complete applicable public DKIM key. Multiple quoted strings can form one logical TXT value; a partial p= or any nonempty response is not sufficient. DKIM is a signature mechanism, not encryption of the campaign's content; see RFC 6376.

5. Preserve DMARC before using the monitoring example

Read the direct policy and any applicable inherited policy first. Preserve existing enforcement and authorized reporting destinations. Do not replace p=quarantine or p=reject with Sender's p=none sample, publish a duplicate policy or weaken protection to obtain a green icon.

Only when no applicable policy exists, the domain owner approves and an appropriate monitoring plan exists, consider a first TXT policy such as:

v=DMARC1; p=none

For visible From domain example.com, the TXT owner is _dmarc.example.com, relative _dmarc in its zone. For news.example.com, use _dmarc.news.example.com, relative _dmarc.news in the parent or _dmarc in the delegated child zone. Confirm how the DNS editor handles the suffix.

Monitoring is not an instruction guaranteeing delivery, and this minimal value alone has no aggregate-report destination. If reports are wanted, provision an actual approved and monitored destination instead of copying a sample address. The domain owner must approve the data-sharing and privacy consequences.

When the destination's Organizational Domain differs from the Organizational Domain of the domain where the policy was discovered, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone is not enough. RFC 9990 section 4 defines that check. Protocol authorization does not replace owner approval. Current DMARC alignment and policy rules are in RFC 9989.

6. Verify DNS and recheck the domain in Sender

Compare the public answers at both authoritative and recursive resolvers. Replace every placeholder below with the actual approved owner or resolver:

dig @AUTHORITATIVE_NS ACTUAL_SPF_OWNER TXT
dig @RECURSIVE_RESOLVER ACTUAL_SPF_OWNER TXT
dig @AUTHORITATIVE_NS ACTUAL_DKIM_OWNER CNAME
dig @RECURSIVE_RESOLVER ACTUAL_DKIM_OWNER CNAME
dig @RECURSIVE_RESOLVER dkim.sendersrv.com TXT
dig @AUTHORITATIVE_NS ACTUAL_DMARC_OWNER TXT
dig @RECURSIVE_RESOLVER ACTUAL_DMARC_OWNER TXT

Check exact full owners, complete values and the expected alias target, then confirm the alias chain reaches the applicable public key. Use a different target only if Sender has actually issued it. Resolve any direct or inherited DMARC policy according to the domain's real hierarchy. DNS caches and TTLs can explain temporarily different answers, but waiting will not fix a misspelled owner, conflicting record or wrong authoritative zone.

Return to the domain dialog and click Check SPF, DKIM and DMARC records. The current guide says successful verification closes the dialog and produces three green checks in Authentication. Ownership confirmed is a separate check. If a record fails or shows a warning, compare the account values and DNS, correct only the approved discrepancy and use Recheck DNS records.

Sender says updates often appear within minutes but may take 24–48 hours. Treat that as a documented expectation, not a guaranteed delay or a reason to ignore an immediately visible error. If correct authoritative and recursive answers still fail the account check, contact Sender Support with sanitized evidence. Do not replace a valid existing DMARC policy just because its value differs from the sample. The cited native workflow does not establish another universal Enable DKIM toggle after these checks.

7. Confirm the actual campaign signer and sender

With the owner's approval, select the intended verified-domain From address in the actual campaign and send nonsensitive content through the native campaign route to a valid controlled recipient. Do not substitute a transactional API test for a campaign test. Record the expected From, domain configuration and sending path without exposing customer content.

Use Authentication-Results produced inside the actual receiving service's known processing boundary, supported by that service's documented handling of externally supplied fields. Ignore attacker-supplied results; a familiar authserv-id, header position or copied pass is not proof. If provenance is unclear, obtain the receiver's authenticated message trace or administrator diagnostics. RFC 8601 explains why this boundary matters.

Accept the new branded DKIM setup only if the intended Sender signature passes. Reconcile observed d= and s= with the approved domain and current provider setup, require alignment with the unchanged intended visible From under the published policy, and require trusted receiver dmarc=pass. An unrelated passing signature, provider-rewritten From or DMARC passing only through SPF does not establish that your Sender DKIM route works.

Record the actual envelope/SPF identity separately. Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. A child envelope domain does not automatically strictly align with an apex From. Do not infer runtime d= from dkim.sendersrv.com, assume the shared target is your From domain or promise a universal Return-Path. Test each meaningful approved sender/domain combination, not just one account default.

Troubleshooting and safe recovery

Ownership is green, but authentication is not. Ownership and DNS checks are separate. Confirm the correct domain row, complete issued values and authoritative zone; run the authentication check after publication.

DKIM CNAME exists but DKIM fails. Check literal alias visibility, the complete target/public key, account verification and the message's actual selector/domain. Existing selector conflicts need coordination, not destructive replacement.

SPF fails while DKIM passes DMARC. Diagnose the observed envelope policy independently. fail or softfail points to an unauthorized sender under that policy; inspect the route and preserved authorizations. temperror indicates transient evaluation/DNS availability trouble. permerror indicates a permanent problem such as syntax, multiple policies or an exceeded evaluation budget. neutral is consistent with ?all for an unmatched sender and is not SPF pass. none means no applicable policy was found.

Sender displays three checks but the recipient rejects mail. Account DNS status does not prove an aligned campaign signature, receiver acceptance or inbox placement. Preserve the trusted result, actual From and route; check the failure layer instead of loosening DMARC or adding unrelated SPF includes.

A change breaks existing mail. Pause affected campaigns, retain evidence and coordinate recovery with the domain and routing owners. Restore only the approved prior records/settings from the saved baseline, without overwriting unrelated concurrent changes. Recheck DNS, Sender status and a new message after recovery. Do not change MX, parent nameservers, DNSSEC or credentials as an authentication shortcut.

Official references and documentary limits

• Native SPF, DKIM and DMARC setup: ownership, published values, status and check controls.
• Find authentication parameters: account values and DNS-dialog workflow.
• Verify SPF and DKIM records: companion labels and rechecks.
• Transactional sender identity: separate scope and conflicting ownership instruction, not this guide's activation authority.

These are JSON-LD publication/update dates, not visible page labels or screenshot dates. Screenshot filenames are not publication dates. These instructions are a documentary workflow, not evidence of a completed customer deployment or a promise of rankings, authentication outcomes or inbox placement.