Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Separate Nutshell Email Marketing from connected mailbox sending
Start with the Nutshell feature that produces the message. **Email Marketing**, a connected Google or Microsoft mailbox, another SMTP connection and a CRM Sales inbox are different routes. Nutshell documents custom authentication for Email Marketing and separately documents sending through connected email accounts. A domain authenticated for a marketing campaign does not prove that a salesperson's connected mailbox or a shared-inbox reply follows the same path. Email Marketing authentication, connected email accounts.
This guide's implementation branch covers **Nutshell Email Marketing**. It also tells administrators how to avoid applying that branch to the wrong route. The exact tenant-generated records, current interface and received-message behavior have not been inspected. Obtain those before making a change. Do not copy legacy selectors or a generic record set from a screenshot into a production zone.
List the marketing sender addresses and the domains they use. Identify who controls the authoritative DNS zone and who administers Nutshell. Preserve the existing DNS values and sending configuration before beginning. Decide whether marketing needs its own subdomain, but do not create one merely to avoid understanding current records. A new subdomain also needs an approved sender identity, reply handling and operational ownership.
Verify the sender and obtain the current domain records
The Email Marketing authentication article says an administrator can add an address under sender addresses and process its verification email. It directs administrators to the Domains page for the DNS records associated with the verified address. The article also describes support-assisted personalization of the Return-Path. These details should be reconciled with the current account rather than treated as a promise that every account has the same activation controls. Nutshell authentication workflow.
Open the relevant marketing domain in the tenant and record the exact public DNS instructions. Label each record's purpose: bounce handling, SPF, DKIM, tracking or hosted content. A list of five records is not useful evidence unless each owner, type and value is preserved and tied to this domain. Where the account requires support to complete customization, obtain confirmation of that step before scheduling the production switch.
For the domain-management branch, Nutshell's custom-domain guide describes Marketing → Domains → Add a domain → Start authentication, using Entri to configure DNS. Review what that connection will change and any permissions it requests. A written guide is not permission for an operator to grant new account access without approval. If an automated connection is unsuitable, obtain the supported manual instructions from the current account or support rather than improvising an equivalent record set. Nutshell custom domains.
Keep the marketing sender verification distinct from DNS verification. The former establishes access to an address in the provider workflow; the latter demonstrates that requested domain records are present. Neither alone proves that a received campaign has aligned authentication.
Preserve mailbox routing and distinguish tracking from signing
The Email Marketing documentation explains that Nutshell handles campaign bounces and can personalize the Return-Path. It describes an MX record on a designated subdomain for that purpose, separate from the organization's main MX records. Use the exact subdomain supplied to this tenant. Do not replace root-domain MX records or copy a hostname from the article's illustration. Confirm that replies still reach the intended monitored mailbox after the change.
Custom tracking and hosted-content domains have another job. A branded click URL may make campaign links recognizable, but the URL's hostname is not the DKIM d domain. Record it separately. A green check beside a landing-page or tracking record cannot demonstrate that the campaign signature aligns with the From domain.
When entering records manually, resolve the DNS editor's name convention. Nutshell's custom-domain guide specifically warns that some editors append the zone automatically. Preserve the fully qualified owner in the worksheet and compare it with the authoritative answer. A record entered under a doubled domain name can look plausible in the editor while being invisible to the verifier. Do not “fix” the supplied public value by changing punctuation or record types without checking the current instructions.
If the supplied configuration includes SPF, inspect the policy at the exact owner used by the envelope sender. Keep one SPF record there and preserve all still-required senders. Review RFC7208 §4.6.4’s ten evaluated DNS-causing-term limit, including nested evaluation, rather than simply counting visible include terms. An SPF policy at the company's root does not automatically authenticate a separate bounce subdomain. RFC 7208, SPF records and evaluation limits.
Handle older Nutshell records as a migration
Nutshell retains a help article about an **April 2022** delivery-system change. It says affected customers see a sender-address banner and receive new records, with old records removable after confirmation. Treat this as a legacy migration branch, even though the page's displayed update date is newer. It is not evidence that every present-day customer must replace five records or delete everything mentioning a previous delivery service. Nutshell legacy DNS update.
If the tenant actually displays that migration notice, save the old and new record sets and ask support whether queued mail or other active accounts still depend on the old records. Add and verify the new configuration before removing obsolete values. Record the approval and timing for retirement. Another application can use a similar service domain, so a text search through the DNS zone is not a safe deletion rule.
If no migration notice appears, use the account's current configuration and document that the historical procedure was not applied. A careful no-change decision is better than turning a dated support article into an unnecessary production incident.
Complete the Nutshell campaign acceptance worksheet
Use one row per sender domain and marketing message class. This is a proposed procedure; no entries represent live observations.
- Account and scope: tenant identifier, Email Marketing feature, campaign or automation name, sender-address verification status and owner.
- Domain configuration: intended From domain, current Domains view, support case if required and record-generation date.
- Public DNS: exact bounce owner, MX destination if supplied, SPF owner, each DKIM owner/type/value and tracking-domain records kept in a separate group.
- Change safeguards: previous values, unrelated dependencies, DNS editor suffix behavior, full SPF lookup review and rollback owner.
- Provider verification: status of each required record and any activation or migration step still outstanding.
- Received campaign: controlled recipient, UTC time, message identifier, visible From, Return-Path, every DKIM d and s pair and trusted receiver results.
- Operational checks: expected reply destination, representative link behavior, bounce-processing evidence if available and independently recorded delivery placement.
- Approval: aligned passing path, remaining exceptions, reviewer and release decision.
Send a harmless campaign through the real marketing route to an authorized test audience. Inspect the recipient's original message rather than only the campaign dashboard. DKIM verification uses the selector and signing domain from that message to locate the public key. A successful lookup alone cannot prove the message signature passed. RFC 6376, verifier actions.
For DMARC, compare the visible From domain with the passing SPF envelope identity and each passing DKIM signing domain. At least one must align under the applicable mode. Record the actual evidence, not merely Nutshell's statement that customized mail is aligned. RFC 9989, identifier alignment.
Diagnose a fictional campaign and a separate sales reply
**Fictional illustration only. No Nutshell account or received message was tested.** A company sends a campaign from newsletter@orchard.example. Its imagined receiver shows a passing DKIM signature for orchard.example and an unaligned service-owned envelope domain. The campaign passes DMARC through aligned DKIM. SPF alignment is not required in addition to that passing aligned path.
A salesperson then sends from the same company's address through a separately connected mailbox. The imaginary message has a different DKIM domain and fails DMARC. The campaign's success does not diagnose this second route. Inspect the connected mailbox provider's authentication and actual sending settings; adding more marketing DNS records would not establish that the mailbox uses them.
A CRM Sales inbox deserves another row. Nutshell's current inbox guide describes outbound domain verification separately from automatic forwarding and uses its domain workflow before shared-address replies are ready. Do not treat an inbound-forwarding verification as proof of outbound signing. The precise shared-inbox authentication instructions remain outside this marketing branch until the tenant's generated records and a received reply are reviewed. Nutshell CRM Sales inbox.
Recover without abandoning the domain policy
If marketing verification fails, compare the exact owner and value first, then check authoritative publication, domain suffix duplication and tenant assignment. If messages are signed but unaligned, resolve the sender domain and signing route rather than adding unrelated SPF permissions. If a change disrupts mail, restore the affected configuration through the approved rollback plan and retest.
Do not weaken organization-wide DMARC enforcement to compensate for one unfinished marketing migration. Keep the affected rollout paused while the route is corrected. This manuscript is a documentary candidate: live tenant inspection, authoritative DNS checks, received-message evidence, visual review and human subject-matter approval remain pending. Only after those checks should the organization treat the selected Nutshell route as accepted.