Define success as the delivered identity you intended
A Selzy campaign can be delivered while displaying a different sending domain from the one the campaign owner expected. Put the desired visible From, display name and reply destination in the change plan before starting authentication. A test that merely arrives is not sufficient acceptance evidence for a branded sending identity.
This guide covers the Selzy marketing-account workflow. The Selzy UniOne page’s product description presents a separate SMTP and API service. If your application sends through UniOne, confirm that route and use its account-specific instructions rather than assuming campaign settings carry over. The same brand family does not establish identical selectors, envelope behavior or setup controls.
Inventory every domain used by campaigns and automations. Include variants inherited from templates or selected by different staff members. Treat different domains and materially different delivery routes as separate tests. Do not add a second domain solely because a generic tutorial uses it in an illustration.
Confirm the mailbox before requesting domain settings
Selzy’s setup guide, “Add your email to confirmed emails” begins in Account → Settings → Account setup → Confirmed emails. It requires confirmation of an address on the domain before that domain can be added for authentication. Use an address the organization controls and monitors.
Confirming a mailbox demonstrates access to that mailbox; it does not publish a key, authorize a sending server in DNS or prove DMARC alignment. Keep the confirmation event in a different worksheet row from the DNS change. If the confirmation message does not arrive, investigate the address and mailbox rather than changing unrelated SPF records blindly.
Decide who will maintain the reply destination when staff change roles. Test the destination through the ordinary reply workflow using harmless content. Avoid putting an individual’s unmonitored address into a long-lived campaign simply because it was convenient for initial setup.
Obtain the current domain records from the account
The Selzy DKIM guide, “Create a DKIM record in Selzy” directs the administrator to Domain Authentication, add the domain and obtain its settings. Use the exact owner, type and public value shown for the actual domain. Record the source account and time so another administrator can distinguish current instructions from an old setup screenshot.
Check existing records at the proposed owner before publication. If the selector name is occupied, determine whether it belongs to the same account, an earlier key or another service. Do not overwrite it merely because a tutorial shows a familiar selector. Ask for a supported resolution when there is a conflict.
Publish only public verification material. A public DKIM key is not secret, but the private signing key must remain with the authorized signing system. Do not copy a sample key from the help page or another organization. Do not shorten a long key or change its characters to fit a DNS editor. Verify the complete returned DNS value after the edit.
The cited guide’s “How to test DKIM authentication” section separates DNS, application and real-message checks. Follow that separation in the change record. Each answers a different question: is the key published, does the service recognize the configuration, and did the receiving system validate a message signed using it?
Add SPF without rewriting the rest of the mail policy
Selzy’s SPF guide, “How to add an SPF record” starts with the Return-Path and sender inventory, then obtains the current account settings and publishes one policy. It shows include:spf.selzy.com as the service authorization. Review that dependency in the context of your actual domain and existing senders rather than copying a standalone policy wholesale.
Preserve the current policy and its business owners before proposing a change. Mailbox platforms, support systems and other applications may already depend on it. Identify any redirect modifier and the ending all mechanism. A simple-looking replacement can change what happens when no earlier mechanism matches.
The setup tutorial includes a broad instruction to change redirect into include and use a particular ending. Do not apply that transformation mechanically. The SPF guide’s syntax section distinguishes the two constructs, and RFC 7208, sections 5.2 and 6.1 defines their different behavior. Have the mail administrator review the whole policy and retain the organization’s intended semantics.
RFC 7208 sections 4.5 and 4.6.4 also cover single-policy selection and the limit on DNS-querying mechanisms and modifiers. Count nested lookups. Do not create another v=spf1 record at the same owner or remove unrelated authorizations merely to make a local checker green.
SPF evaluates an envelope identity, not the visible From by itself. Capture the identity from a received message and record whether it aligns. This review does not establish a universal campaign-account setting for a custom Return-Path. If aligned SPF is a firm requirement, confirm support for the exact route rather than inventing a bounce-domain field.
Read Enabled status alongside the actual DNS answers
In the setup guide’s status instructions, Selzy provides an Enabled state and a manual refresh control. It describes delays and error messages for missing records or authorization. Use the error to identify the failing layer instead of repeatedly re-creating the domain.
If a key is reported missing, query the exact owner shown by the account. Check for an accidentally doubled suffix, a record in the wrong DNS provider, missing content or inconsistent authoritative answers. If SPF is reported missing, inspect the policy at the expected domain and compare it with the account’s requirement. Record the resolver and time when answers disagree.
Do not treat application status as proof of the final message identity. A campaign can use a different From selection than the domain you just enabled, or a scheduled automation may inherit older settings. A fresh controlled send from the actual route remains necessary even when the domain panel appears healthy.
Check explicitly for From-address substitution
The setup guide’s “Why was my From email address replaced?” section describes substitution with a Selzy shared domain when DKIM is not enabled or a freemail sender is used. Its reply section explains that Reply-To is handled separately. Consequently, record the delivered From address rather than assuming it equals the campaign editor’s original input.
This behavior is particularly important during testing. A campaign that arrives under a shared domain can demonstrate delivery through the service without proving your own domain is authenticated. Do not count it as success for a custom-domain requirement. Save the difference between requested and observed identities and correct the intended domain’s setup before retesting.
Verify replies separately. Check the actual Reply-To header and send a harmless reply to the approved monitored destination. A valid reply route does not repair DMARC alignment, and an aligned campaign can still send replies somewhere the business does not monitor. Both checks belong in the launch record.
Capture the final authentication evidence
Send to controlled external recipients through the same campaign or automation route that will be used in production. Use no customer list, private customer details or production order content. Record campaign ID, Message-ID and UTC time so support can correlate the delivery without receiving unnecessary data.
Capture the visible From domain, receiver-reported envelope identity or Return-Path, all DKIM d= and s= values, and the receiving service’s trusted SPF, DKIM and DMARC results. RFC 6376, section 3.5 defines the DKIM identifiers. Use those observed values to check the key lookup, not a selector guessed from an older article.
RFC 9989, section 4.4 connects authenticated SPF or DKIM domains to the visible From through alignment. Record the passing aligned mechanism and the mode in force. A pass under a service domain, or delivery under a rewritten From, does not demonstrate authentication of the originally requested custom identity.
Keep the organization’s existing DMARC policy unless its owner approves a broader change. Do not interpret a beginner tutorial’s monitoring example or waiting recommendation as permission to disable existing enforcement. Investigate the sender first. Authentication is one part of delivery and does not guarantee inbox placement or message safety.
Use the sender-substitution worksheet
Use a separate review record containing mailbox confirmation, account-issued DNS records, Enabled status, requested and delivered From addresses, reply destination and aligned receiver results. The requested-versus-observed comparison is intentional: it prevents a shared-domain fallback from being mistaken for custom-domain completion.
If a field cannot be observed, record the next owner and action. Keep external message evidence separate from internal allowlisting or test-mode results. Add a retest for every meaningful sender-domain change, template update or move between campaign and API/SMTP products.
Fictional worked example: a delivered campaign that is not ready
Fictional written case only: SZ-01 assumes the requested sender is promo@example.org, but the delivered message uses a shared Selzy domain and retains Reply-To promo@example.org. The exact substituted mailbox, signing domain, selector and SPF result are unknown. A working reply does not meet the brand-identity requirement. The campaign owner should resolve domain authentication and collect a fresh external message showing the intended From plus aligned authentication before approving that requirement. No account, campaign or delivery test occurred.
Recover without hiding the original problem
Pause the affected custom-domain rollout when the required identity cannot be demonstrated. Preserve existing working authentication records and coordinate any restoration with the account and DNS owners. If shared-domain sending is considered as a temporary alternative, make the branding and reply consequences explicit for the business owner rather than silently treating substitution as a fix.
Retain selectors needed by messages still in flight until a reviewed retirement plan permits removal. Live account inspection, DNS observations, received-message proof and exact custom-envelope support remain pending here. This unpublished documentary draft also awaits visual review and human SME approval.
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.