ShipStation SPF, DKIM and DMARC setup, step by step

ShipStation can send shipment notifications from your own email address on eligible accounts created before April 1, 2024. The native setup has three distinct steps: add the address to the store’s Branding settings, verify access to that mailbox, then publish the CNAME records issued under Authenticate Domain and select Check Status. After the domain shows Authenticated, separately confirm that customer notifications are enabled for the intended store.

Do not start by adding a generic SendGrid SPF include to your root domain. ShipStation’s native connection supplies the authentication CNAMEs, including the SPF-related configuration. Its current example shows three CNAME rows, but your account’s complete records are the authority. The default sender, tracking@shipstation.com, already has provider-managed SPF and DKIM and does not require changes to your own DNS. ShipStation’s configuration guide and authentication explanation establish these routes.

Check eligibility and the exact sending route

This guide covers ShipStation’s native customer shipment and delivery notifications, not a standalone SendGrid account, your staff mailbox service or another platform’s marketing emails.

ShipStation expressly limits domain authentication to accounts created before April 1, 2024. Its documentation says accounts created after that date use the default email. It does not clearly resolve accounts created on April 1 itself. If your creation date or available controls leave eligibility uncertain, ask ShipStation to confirm it before making DNS changes. Do not treat an absent feature as a DNS fault or assume a paid upgrade will unlock it.

You need permission in ShipStation to update the affected store’s email settings, an approved, working sender mailbox on a domain you control, and an authorized administrator for that domain’s authoritative DNS. ShipStation names the required capability, not a universal role title. Public addresses such as gmail.com, yahoo.com or aol.com cannot be authenticated as domains you own.

Record the existing sender, notification settings and DNS records before changing anything. Agree with the store owner which address may replace the default sender and when that change may take effect. Domain authentication authorizes ShipStation to send on that domain’s behalf; it is not merely a cosmetic branding change.

1. Add the sender and verify mailbox access

Follow the native sender-address procedure:

1. Open Account Settings.
2. Select Selling Channels > Store Setup.
3. Beside the intended store, open Actions > Edit Store Details.
4. In Branding, enter the approved address in the email field and save.
5. Follow the verification pop-up’s link to Settings > Sender Emails.
6. Select Verify Email beside the correct address.
7. Choose Send Confirmation Email.
8. Have the authorized mailbox operator open ShipStation’s confirmation email and follow its verification link. Confirm completion in ShipStation.

Check the exact address before requesting the email. Do not send verification messages to an unrelated person, share mailbox credentials or assume that changing a display name verifies an address.

An address entered but not verified can still appear on packing slips, email templates and branded tracking/returns pages. That appearance is not evidence that ShipStation has switched the actual notification From address. Complete both mailbox verification and domain authentication before expecting branded sending.

2. Obtain the account-issued CNAME records

Open Settings > Account > Sender Emails, find the verified address and choose Authenticate Domain. If the button is unavailable, recheck mailbox verification, domain ownership and account eligibility rather than guessing records.

Copy every complete CNAME owner and target from that account’s dialog into a change plan. The current official screenshot contains one envelope-related-looking alias and two _domainkey aliases. Its account numbers, domain, selectors and SendGrid targets are examples, not reusable configuration. Do not derive your records from that image, another store or a generic SendGrid tutorial.

The DKIM CNAMEs let the receiving service locate the public keys maintained for this connection. You should not generate, paste or send a private key. The separate non-selector alias is also part of the issued packet; do not omit it because your immediate goal is DKIM.

Resolve an existing SendGrid connection without overwriting it

ShipStation’s Advanced Options includes Subdomain and DKIM Selector fields for a domain that already has a SendGrid connection outside ShipStation. The documented action after choosing the desired values is Update DNS Records. This is account-side record generation, not permission to replace another service’s selector.

Have the domain and existing sender owners coordinate a supported, nonconflicting choice. Compare the resulting complete packet with the records already in DNS. Do not casually change these fields after publication, reuse another account’s targets, or delete the older connection. If the intended relationship between the two connections is unclear, stop and resolve it with the responsible administrators and ShipStation before proceeding.

3. Publish the aliases in authoritative DNS

Use the DNS service named by the domain’s actual authoritative nameservers. A registrar, website host and DNS host may be different organizations. A delegated child zone can have a different administrator again. ShipStation does not edit your DNS for you; its guide directs DNS configuration questions to your IT team or DNS provider.

For each issued row:

1. Confirm the full owner, type CNAME, complete target and existing record/delegation state.
2. Work out whether your DNS editor expects the full owner or a name relative to its selected zone.
3. Enter the owner once, without duplicating a suffix the editor adds automatically. Paste the exact issued target, not a web URL with https:// or a path.
4. Save only the approved record and check the final displayed fully qualified name.
5. Query the authoritative answer and compare it with the issued target.

The following names are structural examples only. Replace SELECTOR and ENVELOPE-LABEL with the actual labels issued by ShipStation. Repeat the selector mapping for each issued DKIM alias.

At a CNAME owner, do not add a conflicting TXT, A, AAAA, MX or second CNAME record. If it is already an NS delegation or an alias used by another system, do not remove it to make this tutorial fit. Resolve the collision through an approved alternative packet or the existing delegation’s operator. Preserve root MX, nameservers, DNSSEC and unrelated senders.

Keep the required CNAME answers visible

These authentication aliases are DNS records, not web traffic. Where a DNS provider offers an HTTP proxy, use DNS only, not a proxied record. Cloudflare explains the distinction in its proxy-status documentation.

Flattening can also hide the literal CNAME answer. For an issued alias that must remain visible, turn its per-record Flatten control off where available and ensure any applicable whole-zone setting does not flatten it. Cloudflare’s CNAME flattening setup explains that a zone-wide setting can prevent a per-record override, apex aliases are flattened by default, and same-zone targets can be flattened regardless of that setting.

Coordinate shared-setting changes with the DNS owner instead of disabling a global feature without checking other records. If mandatory apex or same-zone behavior cannot preserve a required answer, stop and arrange a supported record configuration. Do not invent an unavailable switch or move a delegation.

These read-only query templates do not publish anything. Replace both placeholders before running them:

dig @AUTHORITATIVE_NAMESERVER FULL_ISSUED_OWNER CNAME +noall +answer
dig FULL_ISSUED_OWNER CNAME +noall +answer

Compare the returned alias target with ShipStation’s complete issued target, allowing DNS’s trailing-dot presentation. No answer, a doubled domain suffix or an unexpected target needs investigation. Cached recursive results can lag the authoritative service; do not repeatedly recreate keys while waiting.

4. Check status, then understand what SPF is doing

Return to Settings > Account > Sender Emails and select Check Status after all issued records are published. The expected account result is Authenticated. ShipStation says emails from the store will then use your address, so obtain approval for that sender transition before completing the setup. Its guidance allows a few hours for DNS settings to take effect, not a guaranteed completion time.

ShipStation regularly rechecks the records. If they are changed or removed, it can stop using the custom sender and revert to tracking@shipstation.com. Receiving an email from that default address is therefore not proof that your branded setup works. Source: configuration and lifecycle notes.

There is no separate universal ShipStation apex SPF recipe

ShipStation’s authentication page says branded SPF configuration is provided through its CNAME records. Publish the issued packet rather than adding an unrequested include:sendgrid.net at your root or creating TXT at an issued CNAME owner.

SPF evaluates the SMTP MAIL FROM domain, with HELO used in relevant cases, not automatically the domain visible in From. Record the actual Return-Path/envelope identity from a trusted received notification before concluding which SPF policy was evaluated. A CNAME record and an SPF pass are different pieces of evidence.

If a separate, explicitly supported change requires editing an SPF TXT policy, preserve the existing legitimate mechanisms and qualifiers and keep one v=spf1 policy per evaluated owner. SPF’s budget is 10 evaluated DNS-dependent terms, including nested lookups, not simply 10 includes. An all mechanism means redirect is ignored. A qualifier does not guarantee a receiving service’s delivery decision. These rules come from RFC 7208; they are not an instruction to modify apex SPF for this native route.

5. Preserve the domain’s DMARC policy

ShipStation’s optional DMARC TXT sample is not permission to overwrite a working policy. Discover the policy that applies to the exact visible From domain, including any applicable inherited parent policy. Preserve established p, sp, alignment settings and authorized reporting destinations. Do not create a weaker child policy or change strict alignment merely to obtain a green status.

Only when no direct or applicable inherited policy exists, the domain owner approves a first policy, and someone will monitor the rollout, this minimal TXT value is a possible starting point:

v=DMARC1; p=none

It requests monitoring rather than DMARC enforcement; it does not force acceptance or guarantee inbox placement. It contains no reporting destination. Add a real, approved rua=mailto: destination only after agreeing who may receive the reports. Do not copy a tutorial’s recipient, publish duplicate DMARC records or add an obsolete pct rollout tag.

Check the final full owner after saving. The table is name mapping, not a reason to override an inherited policy. DMARC passes when at least one supported authentication path passes and aligns with the visible From domain. Both SPF and DKIM should be diagnosed, but DMARC does not require both paths to align. See RFC 9989.

For aggregate reports, compare the destination’s Organizational Domain with the domain where the applicable policy was discovered, not merely with an arbitrary hostname. A destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; one in the same Organizational Domain is excepted. RFC 9990, section 4 defines this rule. Protocol authorization does not replace the owner’s privacy and data-sharing approval.

6. Confirm notification settings for each store

Domain authentication alone does not enable customer notifications. First review the store’s existing state and obtain approval for any notification changes: these settings affect future customers, not just the person configuring DNS.

Current workflow: the Preview Emails button is present

In Account Settings > Selling Channels > Store Setup > Actions > Edit Store Details > Emails:

1. Review the checkboxes for the notification types the owner wants to send.
2. Select only the approved types. The current workflow supports Shipment Confirmation, Estimated Delivery Date, Out for Delivery and delivery notifications.
3. Use Preview Emails if you need to review content.
4. Select Save Changes for approved changes.

Review optional Additional Settings carefully. Adding a BCC recipient there sends that address copies of customer notifications; it is not a harmless testing shortcut. Keep it unchanged unless that recipient and data sharing are approved.

The current notification guide identifies this workflow by the Preview Emails button at the top left of the Emails tab. Do not infer the UI from account creation date alone. The authentication eligibility cutoff and notification-interface version are different checks.

Legacy workflow: the Preview Emails button is absent

The legacy notification guide documents different controls in the store’s Emails tab:

• Choose an approved template from Shipment Confirmation Email and, if wanted, Delivery Notification Email.
• Select Save Changes to enable those notifications.
• The corresponding (don’t send email) option disables that notification when saved.

Do not apply the current checkbox instructions to a legacy account. Legacy notification status can be inspected in the Shipment Notification and Delivery Notification columns or Smart Document Tracking. A Sent or Notified indication is useful delivery-workflow evidence, not a DKIM or alignment result.

Respect marketplace and shipment boundaries

Some channels, including Amazon and Walmart, prohibit third-party customer notifications; their controls can be absent. An order also needs a valid email address. Neither condition is repaired by changing SPF.

By default, creating a shipping label triggers shipment and marketplace notifications together. Delivery messages depend on carrier updates, and only shipment-confirmation timing can be delayed. Do not create labels, mark orders shipped, change order recipients, alter carrier events or resend customer messages solely to test authentication. A trial limitation on manually marked-shipped notifications is not a reason to purchase a plan as part of this setup.

7. Validate the intended native message safely

A preview verifies content, not delivery or authentication. Prefer an authorized, suitably redacted existing native notification after the change, or a separately approved synthetic, non-purchasing test arrangement restricted to controlled valid recipients. Do not assume ShipStation has a standalone test-send control that these sources do not document. If no safe native test is available, record message-level acceptance as pending rather than manufacture a real order event.

For each store/domain and actual notification path being accepted:

1. Confirm the visible From is the approved custom address, not the default ShipStation fallback.
2. Obtain the raw message from the actual receiving service.
3. Establish which authentication results were produced inside that service’s known processing boundary, using its documented handling of externally supplied Authentication-Results. Header position or a familiar authserv-id string alone does not prove trust. Ignore attacker-supplied result fields; ask the receiving administrator when provenance is uncertain. RFC 8601 explains the trust boundary.
4. Find the intended ShipStation connection’s DKIM signature and retain its d= signing domain, s= selector and trusted verification result. Require DKIM pass and alignment with the intended From under the existing policy, plus trusted DMARC pass.
5. Record SPF’s actual evaluated envelope identity and result separately. A DMARC pass through SPF does not prove the intended DKIM signature works. Investigate SPF fail, temporary DNS errors and permanent evaluation errors separately even if DKIM supplies DMARC pass.
6. Confirm the approved recipient and message type, and retain only the diagnostic data authorized for the investigation.

Strict DKIM alignment requires an exact signing-domain/From-domain match. Relaxed alignment uses the applicable Organizational Domain relationship. SPF has its own alignment setting; a child envelope domain does not prove strict SPF alignment. Do not promise either alignment mode from the CNAME labels alone. For the distinction between a valid provider signature and a valid branded signature, see EmailAuth’s raw DKIM versus aligned DKIM results.

Troubleshoot the failed step, not every record

For escalation, provide the affected store, approved sender domain, account eligibility information, exact public record owners/targets, authentication state and a minimally redacted diagnostic message where authorized. Do not send passwords, private keys or unnecessary order/customer details. DNS-host configuration belongs with the DNS administrator; missing ShipStation features or native account behavior belong with ShipStation.

Rollback and ongoing maintenance

Keep the original settings and a change log. If a planned sender change causes trouble, have the owner authorize the supported rollback for that store and review its notification consequences. Do not deliberately break DNS to force ShipStation’s fallback. Likewise, deleting every record with a familiar SendGrid target can damage another sender.

Retain working selectors while mail using them may still be in transit, and coordinate any replacement packet with all users of the relevant labels. Remove only records confirmed to belong exclusively to the retired connection after dependencies are resolved. Leave other SPF authorizations, DMARC protection, reporting recipients, MX and delegations intact.

Recheck actual native messages after material sender, selector, domain or notification-route changes. Authentication improves identification; it does not guarantee delivery, prevent every phishing message or prove that a shipment occurred.

Sources and documentary review

No account, DNS, customer notification or shipment operation was performed for this guide.

• [Configure Domain Authentication in ShipStation](https://help.shipstation. Native issuance, verification, eligibility and fallback; current record and Advanced Options images inspected.
• [Email Domain Authentication (DMARC)](https://help.shipstation. Native SPF/DKIM routing. Protocol standards, rather than simplified delivery/policy claims, govern the explanations above.
• [Customer Notifications Settings](https://help.shipstation. Current per-store controls and notification side effects.
• [Set Up Legacy Customer Notifications](https://help.shipstation. Legacy controls and status interpretation. These displayed times do not specify a timezone.