Separate sender authentication from branded links
Remarkety presents two related domain workflows that deserve separate acceptance checks. The sender workflow obtains DNS instructions from support and checks verification in Manage Senders. The newer Custom Domain workflow creates branded tracking, browser-view, unsubscribe, and landing-page links. A verified link domain is useful, but it is not evidence that the visible From domain has a passing aligned DKIM signature. Remarkety sender DNS setup Remarkety Custom Domain Setup
Start with the store account, the intended From address, and the workflows that need that identity. List newsletters and the automations actually enabled for the store. Give each a business owner and identify the domain administrator. This guide covers the documented Remarkety route; it does not establish authentication for the store platform’s separate order emails, mailbox provider, or another connected application.
Define a small release scope before touching DNS. A store with several brands should record which brand owns each domain and which account may use it. Agree who receives replies and who can approve new sender addresses. Keep production customer lists out of the authentication worksheet. The evidence should show domain configuration and harmless test messages, not purchasing history or other customer information.
Obtain the sender-specific configuration
Remarkety’s 2025 deliverability guide directs administrators to support for DKIM instructions, supplying the domain or account name. Its sender-DNS article additionally asks for the intended Send from address. After publication, notify support and request verification; check the resulting status on the deliverability page in Manage Senders. These are documented checkpoints, not a claim that this account has completed them. Remarkety 2025 deliverability guide Remarkety sender DNS setup
Ask for a complete set of public record owners, record types, and values tied to the exact account and domain. Ask which identity will appear in the SMTP envelope and which domain will sign the message. If different stores share a domain, ask whether existing selectors or delegations can coexist. Do not substitute a screenshot’s sample key for the issued configuration.
Prepare the DNS change with a before-and-after record list. Confirm the authoritative DNS service, which may differ from the registrar or website host. Check whether its editor appends the zone name. A full hostname pasted into a field that already supplies the suffix can create the wrong owner. Publish only the approved records and preserve unrelated mailbox and website records. Keep the change time and previous TTL with the evidence.
Remarkety’s SPF page currently shows include:spf.remarkety.com and include:spf.remarkety.net. It also says to merge with an existing SPF policy instead of publishing another. Treat those as documented provider authorizations to assess for the actual route, not a complete replacement policy for every customer. Its example a and mx mechanisms should not become additional permissions merely because they appear in a sample. Remarkety SPF setup
SPF applies to the SMTP identity evaluated by the receiver. Maintain one applicable SPF policy at the relevant owner and check the DNS-lookup budget, including nested evaluation. Adding an include to an unrelated owner cannot rewrite a message’s envelope identity. SPF RFC 7208
Verify authentication before link appearance
Send through a controlled version of a real campaign and at least one enabled automation. Choose test recipients who have authorized the check. Record the visible From, the envelope domain, all DKIM signing domains and selectors, and trusted receiver authentication results. Keep the message timestamp and the test workflow beside those observations so another reviewer can reproduce the comparison.
DMARC needs a passing authentication path whose domain aligns with the visible From domain. A pass for an unrelated service domain is insufficient. A DKIM signature’s d= identifies the signing domain and s= identifies the selector; preserve both rather than recording only a green status indicator. DMARC RFC 9989 DKIM RFC 6376
Compare the receiver result with the support-issued record set. If DNS verification succeeds but no aligned signature appears, check that the tested campaign uses the intended sender and the correct store account. Ask support whether activation is complete and whether the automation follows the same configuration. If a signature fails, preserve the exact failure and public lookup result before changing anything. Avoid replacing working keys without evidence that the key is the problem.
Next, inspect the branded links as a separate functional test. Remarkety documents Settings > Account > Custom Domain, generated CNAME records, and additional records for selected Custom Links options. Copy current account values and test each enabled use. A browser-view URL and an unsubscribe link can need independent functional review even when the email authenticates. Remarkety Custom Domain Setup
Do not promise inbox placement from either result. Authentication, working links, permission to contact subscribers, and campaign quality are different acceptance criteria. Do not weaken the whole organization’s DMARC policy to rescue an unverified store sender. Route the unresolved sender issue to its owner while preserving other legitimate mail flows.
Fictional diagnosis: links work, sender alignment does not
Consider a fictional store using offers@shop.example. Its administrator verifies a branded link hostname and sees the expected store URL in a test. The team assumes domain authentication is finished. In this invented example, the receiver instead reports a passing signature for an unrelated service domain and no aligned SPF path. DMARC therefore fails for shop.example. These observations are illustrative, not Remarkety tenant measurements.
The investigator separates the two changes. They retain the working link configuration, obtain the sender-specific DNS instructions, and confirm the selected campaign sender. After the provider verifies the new sender setup, they rerun the campaign and automation tests. The case closes only when the receiver evidence supports the aligned path; a disappearance of a “via” label is not the closure criterion.
Implementation worksheet
Complete one row for each sender and workflow:
- Account and store: owner, approved From domain, reply handling, and workflows included.
- Provider instructions: support reference, issue date, public record owners, types, values, and activation confirmation.
- DNS evidence: authoritative host, previous values, published values, TTLs, lookup time, and reviewer.
- Message evidence: workflow, test time, visible From, envelope identity, each DKIM d=/s= pair, and trusted results.
- Branding evidence: enabled link uses, generated CNAMEs, and results for view, tracking, and unsubscribe links.
- Recovery: previous supported sender, change owner, rollback conditions, and scheduled retest.
When retiring a store or brand, review both sender trust and custom-link dependencies. Previously sent links may still serve legitimate recipients. Inventory those dependencies before deleting a provider-managed DNS dependency or removing permissions used by another active account.
Evidence and release limits
This is a documentary implementation candidate. Account-specific records, live DNS, received headers, current interface screenshots, and provider activation have not been inspected. Human SME review must confirm the distinction between sender setup and link branding and approve the final supported scope. Visual review and publication remain pending. Keep these gates open until the actual store evidence is attached.
Account for the additional link records
After the initial custom domain verifies, the documented Custom Links choices can produce further CNAME entries. Track each enabled use and its generated records separately from Manage Senders. A successful initial verification does not show that every selected link function has its required records or works for previously sent messages.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.