On this page: Identify the shared domain and plan allowance · Generate or reuse the account records · Configure SendPulse SPF safely · Configure the generated DKIM public key · Check Connected status and each sending route · Troubleshooting SendPulse-specific failures · Frequently asked questions · Publish DMARC without weakening existing protection · Verify DNS and trusted receiver evidence separately · Review scope and implementation boundary
Authenticate your SendPulse sending domain using the account-generated SPF and DKIM records, check that it becomes Connected, and test both Email and SMTP routes you actually use. SendPulse shares domain authentication settings between those services, but one service's successful message does not prove another application's sender settings are correct. SendPulse shared authentication
This guide covers SendPulse email campaigns and SMTP application sending, not SMS, messaging bots or web-push delivery. Those products do not become authenticated email senders merely because they are in the same workspace. Keep authentication domains separate from custom tracking domains and receiving mailbox domains.
Identify the shared domain and plan allowance
Begin with the exact domain after the at-sign in the intended From address. Record whether campaigns, automations and SMTP applications use that same domain. Obtain access to the authoritative DNS host and your SendPulse domain settings. Save existing records before making changes, including other services' selectors and any inherited DMARC policy.
Email and SMTP use a shared authenticated-domain list. When their plan limits differ, SendPulse applies the higher allowance; each subdomain counts separately, while a custom tracking domain does not consume that authentication allowance. Check the current account allowance before adding another domain rather than assuming root-domain authentication covers every subdomain. Domain limits
For an implementation worksheet, give Email and SMTP separate rows containing the sending application, From address, selected authenticated domain, public record owner, provider status and message-test result. Shared records can be recorded once, but route evidence belongs in both rows. This prevents the common handover mistake of marking SMTP complete because a marketing colleague saw a green status badge.
Generate or reuse the account records
For campaigns, use Email → Settings → Domain settings and activate the authenticated-domain entry. For SMTP, use SMTP Settings → Domain settings and activate the sending domain. Enter the domain without a protocol or web-address prefix, then request the SPF/DKIM records. If it already exists, open its settings rather than generating a competing configuration. Email workflow, SMTP workflow
Copy names and values into the worksheet, not directly into production without checking collisions. Make sure the domain shown is the one your message will use, not an agency's domain or a previously selected client. With several authenticated domains, review the sender-address setting explicitly.
The current documentation describes TXT-based authentication. Do not substitute a CNAME recipe from another sending platform. Domain validation tokens, public DKIM material and application credentials have different purposes: only records expressly issued for DNS publication belong in the public zone.
Configure SendPulse SPF safely
SendPulse documents this SPF example:
Owner: example.com
Type: TXT
Value: v=spf1 include:mxsspf.sendpulse.com +a +mx ~all
The SendPulse authorization is include:mxsspf.sendpulse.com. If SPF already exists at that owner, merge this mechanism into the existing policy rather than adding another policy. Review a and mx against your real senders: they authorize the domain's address and MX hosts, not just SendPulse. Do not add them mechanically when those hosts do not send. SendPulse SMTP SPF instructions
For a confirmed SendPulse-only authorization with no need for those hosts, a minimal illustrative policy is v=spf1 include:mxsspf.sendpulse.com ~all. This is a scoped example, not a replacement for your organization's complete policy. Preserve the existing terminal qualifier unless the domain owner separately approves changing it.
An SPF mechanism and its domain are contiguous: include:mxsspf.sendpulse.com, not include: mxsspf.sendpulse.com. Also keep exactly one v=spf1 beginning and one intended terminal all. An include added after all cannot provide the authorization you expect.
If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.
SPF is evaluated against the envelope MAIL FROM identity. A passing result for a provider-owned bounce domain does not align with your branded From domain. The reviewed SendPulse setup pages do not establish a universal custom Return-Path procedure for every account; inspect a real message instead of promising aligned SPF based on an apex TXT record.
Configure the generated DKIM public key
SendPulse documents selector sign, with a TXT owner such as sign._domainkey.example.com. Copy the complete public value from your account. It commonly has the form v=DKIM1; k=rsa; p=PUBLIC_KEY, but PUBLIC_KEY is an explanation placeholder and must never be published literally. The long keys in vendor screenshots are examples, not your configuration. SendPulse SMTP DKIM instructions
In a suffix-appending editor for zone example.com, full sign._domainkey.example.com uses relative sign._domainkey. For full sign._domainkey.news.example.com, use sign._domainkey.news in that parent zone or sign._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, use relative sign in that zone. A full-name field takes the complete account-issued owner. Preserve the existing NS delegation and publish with its actual operator rather than adding an inactive parent-zone copy. DNS zone boundaries.
If another service already owns sign._domainkey, stop and identify that service. Replacing its key can break existing mail; adding two unrelated public keys at one owner is not a safe resolution. Ask the providers about supported selector or domain separation and plan the migration. A conflict is an ownership problem, not a propagation problem.
After saving, query the fully qualified selector and compare the entire public key. One long TXT record may appear as multiple quoted chunks that concatenate; separate competing TXT key records are different. Do not regenerate keys as a first response to a typo in the hostname. DKIM DNS behavior
Check Connected status and each sending route
Reopen the domain's settings and run Check DNS records. SendPulse documents green checks and a transition from Awaiting confirmation to Connected when validation succeeds. Existing shared settings can be checked without publishing duplicates. DNS caches may delay discovery; confirm what authoritative DNS serves before merely waiting. SMTP verification
Next, confirm the selected authenticated domain matches the sender address. SendPulse's Email documentation calls out that association when multiple domains exist. A correctly published key for one domain cannot authenticate an unrelated From identity. Sender-domain selection
Run controlled new-message checks separately for a campaign and an SMTP application. Use normal sending settings and a receiving mailbox where raw headers are accessible. An editor preview or settings badge does not exercise the production transport. Include automations if they choose a different sender, account or integration.
The SMTP Test plan is not a custom-domain acceptance test: it replaces From with devtest@sendpulseemail.com and adds a development-purpose subject prefix. Complete domain authentication and sender-address setup, then test your real From identity outside that mode. Availability varies during the rollout. SendPulse SMTP Test behavior
Troubleshooting SendPulse-specific failures
Cannot add another domain: inspect the shared allowance and existing subdomain entries. Do not delete an active entry just to free capacity. First determine which production routes depend on it.
Connected but wrong signing domain: review the sender-address association and the application's actual account. Correct the route or selection, then generate a fresh sample. Preserve the working DNS for other streams.
SPF passes but DMARC fails: record smtp.mailfrom and DKIM header.d. A provider-owned envelope domain may explain the first result; an absent, broken or misaligned DKIM signature explains why that pass did not save DMARC.
Only SMTP fails: compare the campaign and application From addresses, raw signatures and recipient paths. Do not assume the shared domain record must be broken when one route already verifies it successfully.
Publish DMARC without weakening existing protection
Inspect the From domain's policy and any applicable inherited parent policy first. Preserve established enforcement, reporting destinations and subdomain settings. Do not create a child p=none record merely to bypass a parent's protection.
Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan, use this starter template. Preserve all existing policies and use only approved report recipients:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
For From example.com, the relative owner is _dmarc in that zone. For From news.example.com, a deliberate domain-specific policy belongs at _dmarc.news.example.com, entered as _dmarc.news in the parent zone or _dmarc in a separately hosted news.example.com zone. Check inherited protection before adding it.
Replace the domain and reporting mailbox with a working destination you control or one explicitly supplied by your reporting service. Keep semicolons between tags and mailto: before the address. Publish one DMARC policy at the intended owner. p=none requests monitoring, not quarantine or rejection of failures.
Before a separate domain-wide move to p=reject, follow RFC 9989 section 7.4: ensure legitimate outbound messages carry a valid DKIM signature and consider interoperability with indirect mail, such as forwarding and mailing lists. Completing SendPulse alone does not authorize enforcement for other senders.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.
DMARC passes when SPF or DKIM passes and aligns with From. Relaxed alignment permits an organizational-domain match; strict alignment requires an exact domain match. Review reports across all legitimate senders before stronger enforcement. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around that obsolete percentage tag. Current DMARC standard
Verify DNS and trusted receiver evidence separately
Replace the example names before running read-only checks:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT sign._domainkey.example.com
dig +short TXT _dmarc.example.com
Check the authoritative answer and a recursive resolver if results differ. For this TXT-based DKIM route, expect the complete account-issued public key at the selector owner. Expect only one SPF policy at each evaluated owner. Recursive SPF evaluation must stay within the ten DNS-lookup-causing-term limit; counting the includes visible in the top-level record is insufficient. SPF evaluation rules
Send a newly generated message through each production route to a mailbox where you can inspect raw headers. Use the receiving system's trusted Authentication-Results, not an arbitrary earlier field a sender could have inserted. Record spf, smtp.mailfrom, dkim, header.d, and dmarc with header.from; obtain the selector from DKIM-Signature when needed. Authentication-Results trust boundary
Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.
For this branded DKIM setup, require the intended SendPulse signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.
Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.
Preserve a redacted sample, route and timestamp; do not upload confidential message bodies to public tools. Authentication does not guarantee inbox placement or eliminate reputation, consent and content problems.
If Google Workspace also sends as your domain, review the Google Workspace authentication guide separately. Keep both providers authorized; completing SendPulse setup does not validate your mailbox route.
Agree a recovery plan before rollout: identify which affected Email or SMTP streams can be paused, who can restore the approved sender configuration, and which applications depend on the shared domain keys. Coordinate key replacement across every dependent service; stop dependent campaigns or applications before retiring required records rather than breaking a still-active stream. Retest the actual routes after account, plan, DNS or sender changes. Preserve shared records until their dependencies are accounted for.
Review scope and implementation boundary
No customer account was configured, DNS changed or delivery test performed for this guide. Before deployment, complete the account, DNS and message checks above for your sending route. Authentication does not guarantee delivery.