Treat Email and SMTP as separate tests of shared settings
SendPulse documents a shared authenticated-domain list for Email and SMTP. The applicable domain allowance is the higher limit of the two plans, and each subdomain counts separately; a tracking domain does not consume that authentication allowance. Its current guide gives a free-plan example of one Email domain and two SMTP domains, permitting two shared entries. Confirm the live account's allowance before planning multiple brands or subdomains. SendPulse Email authentication, Generate your DKIM and SPF records.
Shared settings reduce duplicate DNS work, but they do not prove that every application selects the intended From domain. Inventory marketing campaigns, automations and applications submitting through SMTP or an API. Capture the account and intended domain for each route, the business owner, the application owner and the DNS administrator. Keep submission credentials outside this worksheet.
This guide covers the provider's public Email and SMTP authentication workflows. It does not assume an unlimited domain allowance, an independently selectable custom Return-Path or identical final identities across every integration. If a business requirement depends on strict alignment or a particular envelope domain, obtain a supported design from SendPulse before committing to it.
Check for an existing domain before generating records
In Email, the documented entry point is Settings > Domain settings, followed by activation in the authenticated-domain area. In SMTP, use SMTP Settings > Domain settings and the sending-domain area. Both workflows generate SPF and DKIM records for the entered domain. The SMTP documentation says existing Email authentication does not require another DKIM setup because the services share record settings. SendPulse SMTP DKIM, Shared record settings and Adding a new domain.
Open the existing domain first when one is already present. Record its current connection status and public values. Do not generate a second arrangement merely because a new application is using SMTP. If two accounts or teams claim the same domain, compare their current provider-issued instructions and clarify ownership before changing the shared selector.
Count the domains needed for the rollout, including separately authenticated subdomains. If the account is at its allowance, do not remove a working domain simply to expose the Add control. Identify what uses that domain and choose a plan or domain strategy with the account owner. A commercial entitlement decision is separate from a DNS failure.
Reconcile the SPF instruction with the existing policy
The SendPulse SPF guide instructs users with an existing SPF record to add the provider's authorization to that record rather than create a second one. The cited guide names include:mxsspf.sendpulse.com as the addition to an existing policy. Confirm applicability against the current account’s domain settings; the sample a and mx terms are not automatic additions. Do not copy a sample full policy over the existing one. SendPulse SMTP SPF, Copy an SPF record and Add an entry to the DNS provider website.
Export the current TXT answers for the exact owner before editing. List the other services that depend on its SPF policy, and identify the actual envelope identity in a baseline message when possible. The corporate From domain and the SPF-authenticated domain may differ. Publishing an include at an arbitrary apex cannot repair a failure evaluated elsewhere.
Review all DNS-querying SPF terms, including nested includes, against the ten-term evaluation limit. A DNS record that fits the editor's length constraint can still exceed the protocol's evaluation limit. Preserve legitimate authorizations and the approved ending qualifier. Do not broaden permissions with sample a or mx mechanisms unless the domain owner has evaluated what they authorize. RFC 7208, Selecting Records and DNS Lookup Limits.
If the provider request and the organization's existing policy cannot be reconciled safely, stop before publication. Ask the mail owner to evaluate a supported sending subdomain or another appropriate design. Keep the existing working route available while that decision is made.
Publish the account public key at the correct owner
SendPulse's instructions show DKIM as a TXT record and explicitly distinguish the demonstration public key from the account's own value. The guide illustrates sign._domainkey as the TXT owner; retrieve the current full name and public value from domain settings rather than treating an illustration as proof for every account. Do not reuse the long sample key in the article. SendPulse SMTP DKIM, Copying an existing domain record.
Inspect any existing record at the proposed selector owner. A pre-existing key may support a different account, provider or operational route. Ask for a supported resolution rather than silently replacing it or inventing a new selector that the service will not use. Keeping a copy of the previous public record helps the reviewer assess recovery, but it does not authorize restoring an obsolete key without coordinating signing state.
Use the authoritative DNS provider, not necessarily the domain registrar. Confirm whether the editor expects a relative host or a fully qualified name. After saving, query the full owner and compare the complete public value with the account output. TXT strings may be displayed in segments; compare their combined content rather than inserting spaces between fragments.
Only public verification material belongs in DNS or the implementation worksheet. Private signing keys, SMTP passwords and API secrets are not needed for a DNS review. Give support the affected domain and public record evidence without sending credentials.
Verify connection status and sender selection
The Email documentation uses Check DNS records and changes a successful entry to Connected. Its setup instructions also require the authenticated domain to match the sender-address domain. SendPulse Email authentication, Generate your DKIM and SPF records and Check the entry status.
Check the applicable status in both service views and record timestamps. If one team sees a different domain list, verify that both teams are in the intended account before altering DNS. Do not assume a status from one account proves another account is ready.
Then inspect the configured sender address in the marketing workflow and in every submitting application. Review automated templates and application defaults that may retain an old domain after a migration. A sender chosen in a preview screen can differ from the address used by a background job. Capture the actual settings of the production-like workflow being tested.
Keep tracking-domain configuration distinct. A branded tracking domain is useful for links, but it does not substitute for the authenticated domain selected by the sender. The acceptance record should never infer DKIM or SPF alignment from a tracking hostname or an apparently branded message.
Prove the Email and SMTP routes independently
Send harmless messages through one representative campaign and one representative application submission. Add further cases for different From domains, application overrides or routing arrangements. Use controlled external recipients and retain the original headers, Message-ID, submission time and workflow identifier.
For each case, record the visible From, the SPF-authenticated domain, Return-Path and every DKIM d= and s= value. The DKIM signing domain and selector identify the public-key lookup; a valid key in DNS alone does not prove the actual message used it. RFC 6376, The DKIM-Signature Header Field and Extract Signatures from the Message.
Use trusted receiver results to distinguish a cryptographic pass from an aligned pass. DMARC can pass through a qualifying aligned SPF or DKIM result, and the alignment mode affects the domain comparison. Record which mechanism supplies the result rather than writing only “authentication passed.” RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
If the campaign passes but the application does not, compare the actual sender, account and route first. Do not rotate the shared key as the first response. That change might affect a working marketing stream while leaving the application's incorrect From address untouched.
Diagnose shared record problems without disrupting both services
For a DNS verification failure, inspect the published owner, record type, complete value and authoritative provider. For a missing signature, confirm that the test used the authenticated domain and intended SendPulse account. For a signature failure, compare the observed selector and key and check whether another gateway altered signed content.
If SPF passes but DMARC fails, compare identities before adding authorization. If SMTP submission is rejected before delivery, keep the submission error separate from recipient authentication results. A credentials, quota or application-format problem cannot be diagnosed from a DNS check alone. Preserve exact errors without copying secrets into the support bundle.
If a custom envelope requirement remains unmet, obtain SendPulse's supported options for the exact account. The reviewed instructions do not establish that every customer can assign any desired Return-Path domain. Do not invent an MX or CNAME arrangement to approximate a feature that has not been confirmed.
Worksheet recovery and a fictional test failure
Complete the SendPulse shared-domain worksheet (create a separate review record with the fields described here) with one row group per authenticated domain and one evidence entry per Email or SMTP route. Record the plan allowance, existing selector dependency, DNS result, sender configuration and received-message result. Mark unknowns explicitly.
Fictional written case SP-01: assume campaign From courses@example.org has passing d=example.org, but the lesson application submits From lessons@old.example with DKIM/SPF results unknown. Connected status for example.org does not establish authentication of old.example. The application owner should confirm the approved sender, compare the shared-domain inventory and test the lesson route without rotating the working key. No account or message was accessed and no correction or test was performed.
Before a change, decide how to pause each affected stream and restore the last approved sender configuration. Coordinate any key replacement with all services sharing it. On retirement, stop every dependent application and campaign before removing authentication records. Retest after plan changes, account migration, DNS hosting changes or new application routes.
Close only the tested scope
Acceptance requires the correct domain entitlement, account-issued records, valid public DNS, connected provider status, intended sender selection and trusted receiver evidence for each material route. A verified campaign does not close an untested SMTP integration. Live account, DNS and message checks, independent technical review, visual review and human SME approval remain pending; this draft is unpublished and does not claim a completed deployment.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.