Stamped.io SPF, DKIM and DMARC setup, step by step

To authenticate a custom From address in Stamped, open Settings > General > Deliverability, retrieve the DNS records for that sender, publish the exact account-generated records and select Validate Records. Stamped’s SPF/DKIM rows can receive green checkmarks. Its DMARC row does not receive a green checkmark: verify DMARC independently in DNS and on a delivered message. Stamped’s current authentication instructions

This guide covers the documented Stamped, also known as Stamped.io, workflow for review requests and related notifications such as coupons. It distinguishes Stamped’s default reviews@stamped.io sender from your own From address. It does not assume that a separate lifecycle product, external integration or Shopify’s own notification service uses this same sending route.

This is a documentary guide; no store account, customer DNS or live email delivery was tested.

Decide which sender you are authenticating

Stamped’s guide says the custom DNS workflow applies when you replace its default sender with your own email address. Select that sender in Settings > General > General Email Settings, where you can update From Name and From Email. Use an address on a domain your organization controls rather than a public Gmail or Hotmail address. Then return to Deliverability to retrieve the records for the selected sender. Stamped’s email-customization guide

Before retrieving records, confirm the exact From Email and domain you intend to use. A reply address, store URL and visible From address can differ; do not authenticate the storefront hostname merely because customers visit it. Default and custom sender scope

Make sure a Stamped administrator and the authoritative DNS administrator can coordinate. Export existing DNS records first. Record the old sender, current record values, TTLs and who can restore a change. If several storefronts use one domain, compare all issued owners before adding records so one store does not overwrite another’s DKIM delegation.

Retrieve the actual SPF and DKIM records

1. Open the Stamped dashboard for the correct store.
2. Navigate to Settings > General > Deliverability.
3. Select Get DNS Records for the displayed domain if records are not already present.
4. Copy each record’s type, full owner/hostname and value or target. Keep the domain associated with the record set in your change request.
5. Compare the displayed sender with your intended From address before continuing.

The published instructions show CNAME-based authentication and warn that your account values differ from their screenshots. Do not copy another store’s selector, SendGrid-style target or numeric account identifier. Do not assume a fixed record count if your current dashboard displays a different set. Record retrieval and account-specific values

Use a worksheet such as this, populated from your own account:

A heading labeled SPF/DKIM does not mean you must create a root SPF TXT record in addition to the displayed CNAMEs. Follow the actual record types Stamped supplies.

Publish the records without damaging existing DNS

Make the changes at the provider serving the authoritative nameservers. That may be different from your registrar, website builder or mailbox provider.

For each generated CNAME:

• Preserve the exact target. It is a DNS hostname, not a URL with https:// or a path.
• Check whether the DNS interface expects a relative name or a full name. If it appends example.com, enter only the prefix needed to produce the requested final hostname.
• Query the completed name to ensure you did not create selector._domainkey.example.com.example.com.
• Do not replace an existing CNAME, TXT or other record at the same owner without identifying its use. A CNAME generally cannot coexist with other ordinary data at its owner. Ask Stamped for help if a required owner conflicts with another active sender.
• On Cloudflare, use DNS-only records, not proxied records, as Stamped instructs. Where a DNS host offers CNAME flattening, ensure the required CNAME remains publicly visible rather than being returned only as address records.
• If the host rejects underscores, ask the DNS provider or Stamped for a supported solution. Removing _domainkey or changing a selector yourself breaks the requested name.

These provider-specific name, underscore and proxy cautions appear in Stamped’s publication instructions. The CNAME ownership rule is defined in DNS concepts and facilities; Cloudflare’s CNAME verification guide explains proxy and flattening failures.

For an issued SELECTOR._domainkey.news.example.com, use relative SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey in delegated news.example.com, or SELECTOR in delegated _domainkey.news.example.com. The apex owner SELECTOR._domainkey.example.com uses SELECTOR._domainkey in example.com or SELECTOR in delegated _domainkey.example.com. Substitute actual issued selectors, preserve NS delegations and publish at the correct authority. DNS delegation.

Do not change your main MX records to make Stamped’s authentication pass. Do not remove existing mailbox, domain-verification or other DKIM records. If Stamped supplies a TXT SPF requirement for your particular setup, merge that authorization into the existing policy at the specified owner, rather than creating a second v=spf1 policy or overwriting your employee-email authorization.

For each issued CNAME, keep the literal alias/target visible at authoritative and recursive resolvers. On Cloudflare, turn the relevant record’s Flatten off when available and ensure whole-zone flattening does not hide these aliases. Coordinate shared changes with the DNS owner and dependent services. Apex flattening is automatic, and same-zone targets are flattened regardless of the setting; a per-record control cannot override whole-zone behavior. If the required answer cannot be preserved, stop and agree a supported arrangement with Stamped and the DNS provider rather than removing delegation or inventing a switch. Cloudflare flattening behavior.

SPF permits one SPF policy per DNS owner and limits evaluation to ten lookup-causing terms across the evaluated chain. A nested include can consume more of that budget than the single visible term suggests. Preserve the existing final qualifier and any intentional redirect design; do not use +all to make validation appear successful. SPF record selection and limits

If a direct SPF edit involves redirect=, any all mechanism makes that redirect ignored regardless of term order. Identify and preserve the legitimate senders authorized by the redirect and the approved qualifier through a reviewed design; do not append an ending blindly. This is not permission to add local TXT alongside an authentication CNAME. SPF precedence.

Understand SPF identity and DKIM alignment

SPF verifies the connecting server against the SMTP MAIL FROM domain, usually visible in the delivered Return-Path. It does not evaluate your storefront URL, Reply-To or display name. The receiver’s smtp.mailfrom result tells you which identity was checked. For a null reverse-path, SPF uses the HELO identity. SPF identity rules

Stamped’s public guide does not promise one universal envelope hostname for every account. Record the actual identity from a delivered sample. If it belongs to Stamped or another provider domain, SPF can pass without aligning with your own visible From domain. Adding an include at your domain’s root does not change the envelope identity used by the sending service.

DKIM supplies a different path. A signature names a signing domain in d= and a selector in s=. Its public key is found through selector._domainkey.signing-domain, including any published CNAME delegation. For branded sending, check that the intended branded signature passes and aligns with your From domain, not merely that some provider signature passes. DKIM verification

DMARC passes when either SPF or DKIM both passes and aligns. Under relaxed alignment, the authenticated and From domains share an organizational domain. Strict aspf=s or adkim=s requires exact equality for that mechanism. A bounce subdomain such as bounce.example.com can align with example.com under relaxed SPF but not strict SPF. Do not assume a green dashboard check proves either alignment result. DMARC alignment

Validate Stamped and handle DMARC separately

After publishing the generated authentication records, return to Deliverability and select Validate Records. Stamped documents up to 72 hours for DNS propagation before validation can complete. Treat that as a possible caching interval, not an instruction to ignore a known typo for three days. Check authoritative DNS immediately when a row does not validate. Stamped validation

The DMARC row is different. Stamped explicitly states that it cannot automatically validate that record and you should not expect a green checkmark beside it. Replacing an already-correct DMARC policy repeatedly will not fix an absent checkmark.

The domain owner should:

1. Determine the actual visible From domain and inspect its existing DMARC record and applicable parent policy.
2. Preserve established enforcement, reporting and alignment settings. Do not add a duplicate policy or downgrade p=reject or p=quarantine to match a sample.
3. If beginning a new monitored deployment, choose an approved reporting destination and an initial policy appropriate to all legitimate senders, not just Stamped.
4. Verify the policy externally and inspect receiver results on a real Stamped message.

Only when no direct or applicable inherited policy exists and the domain owner approves an appropriate monitoring plan, an illustrative first TXT value at _dmarc.example.com is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This is not a record to copy unchanged. Replace the domain and reporting address with an approved, functioning mailbox or reporting service. p=none does not bypass spam filters or guarantee delivery. After identifying legitimate sources, the domain owner can plan a move toward enforcement. DMARC policy semantics

For _dmarc.example.com, enter relative name _dmarc in the example.com zone. For a deliberately separate news.example.com policy, use full owner _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in delegated news.example.com. Do not create a child override to weaken inherited protection.

Compare the report destination host’s Organizational Domain with the Organizational Domain where the DMARC policy was discovered. If different, the receiver generating reports must check external-destination DNS authorization; a destination within the same Organizational Domain is excepted. A different hostname alone is not external. Separately obtain the owner’s approval for recipient, data sharing and retention; protocol authorization is not privacy approval. Do not send reports to an address copied from documentation or enable ruf failure reports without a separate privacy and retention decision. Aggregate reports still reveal operational information about your mail streams. DMARC aggregate reporting and destination checks

Verify DNS, then inspect a delivered Stamped email

Public DNS checks

Replace all example names with the exact owners from Deliverability. record-owner.example.com represents any generated CNAME owner; it is not a prescribed Stamped name.

dig +short NS example.com
dig @ns1.example.net CNAME record-owner.example.com +noall +answer
dig +short CNAME record-owner.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Repeat for every generated CNAME. Compare the returned target with the current dashboard, not with a screenshot in a guide. For DKIM, inspect the delegated target’s TXT answer as needed to confirm the key resolves. Query the actual envelope domain’s TXT record when evaluating SPF, rather than assuming it is example.com.

Authoritative and recursive answers should agree after relevant cache lifetimes. A green Stamped row confirms that Stamped’s check succeeded; it does not establish the signature used on the next email.

Delivered-message acceptance

Use a later authorized test of the actual review-request or notification workflow with your intended From address. Check a direct external delivery first. If coupons or other active notification types are in scope, test representative samples separately rather than assuming one review preview covers all sending paths.

Use approved synthetic/test-account events and controlled recipients. Do not place a paid order, issue a real coupon or trigger customer notifications solely for authentication. Use a supported preview/non-chargeable test route first and leave production-route acceptance pending if no safe equivalent can be exercised; a preview alone does not prove every notification path.

In the recipient mailbox’s full message source, use the Authentication-Results added by its trusted receiving server, not an untrusted upstream header. Record From, Return-Path, smtp.mailfrom, DKIM d= and s=, and SPF/DKIM/DMARC outcomes. Authentication-Results trust boundary

Establish the actual receiving service’s known authentication-processing boundary from its documentation or mail administrator, including documented handling/removal or distinction of externally supplied Authentication-Results. Ignore attacker-supplied fields. Matching authserv-id text or header position alone is not proof; if provenance is uncertain leave acceptance open and obtain receiver-controlled diagnostics or an administrator-confirmed trace. Forged-header safeguards.

Accept the branded setup only when:

• The message uses the intended visible From address.
• The intended branded DKIM signature reports dkim=pass and aligns under the published adkim setting.
• SPF is evaluated for the expected envelope identity; its pass and alignment are assessed separately.
• The trusted receiver reports dmarc=pass for the intended From domain.

Do not accept a missing or failing branded DKIM signature merely because aligned SPF supplies a DMARC pass. Conversely, investigate SPF fail, softfail, permerror or temperror even when aligned DKIM lets DMARC pass. The two mechanisms have different failure modes.

Troubleshooting Stamped authentication

When escalating to Stamped, include the store, intended domain, affected workflow, failed row, public lookup output and a redacted header sample through an approved support channel. Do not include credentials, private keys or unnecessary recipient data. Keep the previous record set until other stores and senders using it have been assessed.