Confirm the quoting product and sender route
This guide applies to the Quotient quoting application at quotientapp.com and its customer quote emails. It does not describe unrelated products with the same name. Record the business account, quote workflow, intended From address, team member, and DNS owner before making a change. The account's own configuration is the authority for the records that must be published.
Quotient supports sending from an owned-domain email address through Custom Domains for Email. Its current help path is Account Settings, Emails, Custom Domains for Email. The service supplies the DNS instructions. The documented SPF and MX entries use a separate subdomain, with an example such as quotient-mail.yourdomain.com, and the MX supports bounce and complaint handling. Do not replace existing mailbox MX records. Quotient custom-domain help
An example subdomain is not a literal value to paste into every customer's DNS. Copy the actual owner and target shown in the account. Before the change, explain which customer emails should carry the owned domain and which routes are outside this scope. A quote email, an employee mailbox message, and an unrelated marketing campaign can share a visible brand while using different authentication systems.
Quotient's 2021 announcement also describes a default provider-domain sender and CNAME, TXT, and MX records for custom-domain authentication. Use that announcement as historical product context, not as a current pricing or menu guarantee; the current help page and live account should determine the setup. Quotient custom-domain announcement
Gather the current record set without changing receiving mail
Open the account's current Custom Domains for Email instructions and capture every issued record type, owner, and public value or target. Assign an administrator who can edit the authoritative zone. A registrar's billing page or an old hosting panel is not proof of where DNS is served.
Export the existing records before editing. Mark whether each proposed entry is new, a modification, or a conflict with an existing service. Check the generated subdomain for pre-existing use. A record can be “new” in the product's instructions while already occupied in the customer's environment. Resolve that collision with the affected service owner instead of overwriting it.
Keep the mailbox domain's MX records distinct from the dedicated bounce-handling subdomain. Write both names in the change ticket, not just “MX.” The operator should be able to explain which record affects employee mail and which belongs to quote delivery. If the instructions appear to require changing the main mailbox MX, stop and clarify the current tenant configuration before proceeding.
After publication, query each full owner name at the active authoritative service and from an independent resolver. Check that a DNS editor has not duplicated the zone suffix. Follow CNAME targets when inspecting delegated public-key records, and preserve the exact target rather than replacing it with a guessed key. Record TTLs and collection times so later tests can be compared to the published state.
Review the retired SPF include as a migration
Quotient's dedicated legacy-SPF article says include:_spf.quotientapp.com is no longer required and points users to Custom Domains for Email. It advises care not to remove authorizations required by other services. This is an explicit first-party retirement notice, so a fresh deployment should not revive that old include as the current configuration. Quotient legacy SPF notice
For an existing domain, treat removal as a reviewed migration step, not automatic cleanup. First record the existing SPF policy, identify any approved legacy dependency, and obtain confirmation of the currently used quote-sending route. Validate the new custom-domain records and a representative received message before scheduling removal. If a customer-specific dependency is unresolved, retain the question in the change ticket and ask the provider to reconcile it with the retirement notice.
When removal is approved, remove only the obsolete mechanism from the applicable single SPF policy. Preserve unrelated authorizations and the rest of the intended policy. Recheck the complete result rather than judging the edited fragment in isolation. A rollback record should contain the exact prior value, owner, time, and responsible operator.
SPF permits one policy at an owner and imposes a limit on DNS-dependent evaluation. Adding a second record or a growing list of historical includes is not a safe migration strategy. The evaluated identity is the message's SMTP identity, so distinguish the main organizational domain from the dedicated envelope subdomain when assessing which policy is actually used. SPF RFC 7208
Confirm sender addresses and real quote messages
Quotient notes that email-address verification may also be needed after domain authentication. Record which team members' addresses are confirmed and which address is actually selected for the controlled quote. Domain DNS changes do not automatically establish control of every mailbox. Quotient custom-domain help
Send harmless test content through the real quote workflow to approved recipients. If the business uses follow-ups or other customer-email paths, include those in a separate test row rather than assuming they inherit a successful initial send. Capture the delivered From address, Reply-To, envelope domain, DKIM signing domains and selectors, and the receiver's trusted authentication results.
DKIM uses the signature's signing domain and selector to locate a public key. DMARC requires a passing aligned SPF or DKIM mechanism relative to the visible From domain. A provider-signed message can pass DKIM without proving the organization's custom From identity is aligned. Check the actual domains and alignment settings. DKIM RFC 6376 DMARC RFC 9989
Keep authentication results separate from commercial delivery outcomes. A message can authenticate and still encounter a recipient rule, poor reputation, or an invalid address. A successful test also does not establish that every past quote or scheduled follow-up used the new route. Document the configuration cutover time and retain representative evidence from after that point.
Quotient acceptance worksheet
Use this proposed worksheet for the current quote-email route. No customer configuration has been observed.
- Product and account: quotientapp.com account, authorized administrator, team member, workflow, and desired sender identity.
- Domain setup: live feature availability, generated record set, current verification state, and sender-address confirmations.
- DNS separation: main mailbox MX owner and values, generated bounce subdomain, its SPF and MX records, and any delegated signing records.
- Public checks: full owner names, actual answers or CNAME chains, authoritative nameservers, TTLs, timestamps, and record collisions.
- Legacy review: presence of the retired include, approved dependency assessment, provider clarification if needed, removal approval, and preserved prior policy.
- Message tests: quote or follow-up, receiver, timestamp, From, envelope, DKIM domains and selectors, trusted results, and aligned mechanism.
- Decision: untested routes, rollback trigger, DNS operator, business owner, and remaining human approval.
Fictional diagnosis of an unsafe MX change
This example is fictional. A business wants quotes to come from its own domain. An operator sees an MX instruction and prepares to replace the domain's existing mailbox MX records. The change reviewer notices that the instruction belongs to a generated subdomain used for bounce processing.
The proposed correction is to publish the record at its exact issued owner while preserving employee-mail routing. The team then verifies the custom domain and sends a controlled quote. An old Quotient SPF include is discovered during the inventory, but its removal is scheduled separately after the existing route and approved dependencies are checked. This scenario illustrates two different risks; it is not a performed migration or an assurance about a live account.
Evidence and release gates
The current help pages support the custom-domain workflow and retirement notice. They do not provide the actual customer's generated selector, targets, or signing behavior. Those remain tenant-specific evidence requirements. Current feature availability and any commercial commitment must be confirmed in the account before activation. Live DNS, received headers, legacy dependency review, visual review, human SME approval, and publication approval remain pending.
Separate the two DNS decisions
Use separate approval lines for adding the generated bounce-subdomain records and retiring the historical root-policy include. The first decision requires a collision check at the exact generated owner. The second requires the existing sender inventory and recovery value. One successful quote cannot establish all scheduled follow-up identities or authorize unrelated SPF removals.
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.