Choose the sender identity before editing DNS
Quentn offers two different sender choices: an address at a domain the organization controls, or an address using a Quentn domain. This guide covers verification of an organization-owned domain and explains where the provider-domain route differs. Decide which visible From identity the campaign should use before writing a DNS change. Access to a personal mailbox at a public email service does not provide authority over that service's domain.
In the documented sender workflow, open Emails, then Senders, and add a sender email. The Default type is intended for an owned domain; saving sends an address-confirmation email. The Quentn domain type instead offers a provider-domain address and asks for a forwarding destination, which must be confirmed. These are distinct routes, not two ways to publish records for a public mailbox provider. Quentn sender setup
Record the selected address, sender type, campaign owner, and reply destination. Changing a default can affect which identity a person selects in future campaigns, so check already prepared campaigns rather than assuming every draft automatically matches the new intention. Retain a controlled reply test in the acceptance plan. Authentication success does not establish that respondent replies reach the team expecting them.
Keep address confirmation and domain verification separate
The sender confirmation establishes control of an inbox. Domain verification is a separate DNS task. Quentn's verification guide directs users to Email, Verified domains, then Create domain. After creating the domain, open its verification information, publish the displayed DNS entries at the domain host, and check the resulting verification indication. Use the current account's issued records; the guide does not provide one universal set of values for every installation. Quentn domain verification
The DNS owner should first confirm which nameservers are authoritative. A zone visible in an old hosting account may no longer serve public answers. For each generated instruction, capture the record type, full owner name, target or public value, and the existing value at that owner. Read the DNS editor's convention for relative names so that it does not append the domain twice.
Do not infer a TXT record or selector from a screenshot filename. If the tenant issues a CNAME, preserve its target and check that no incompatible record already occupies the same owner. If it issues a TXT record, preserve the full public value. Escalate an owner-name collision rather than deleting an existing service's records to make verification pass. The change ticket should identify the affected service and owner before a replacement is approved.
Quentn's guide calls domain verification optional. That wording should not be translated into a promise that an unverified organization-owned From address satisfies the recipient's current authentication requirements. Treat it as a description of the documented product workflow and still require message evidence for the intended identity. Quentn domain verification
Build SPF from the real sending inventory
Quentn's authentication introduction tells customers to account for other systems, including membership and website mail, before changing domain policy. It also shows an SPF example and DMARC examples. Those examples are not a replacement for the tenant-issued configuration and the organization's actual mail inventory. Quentn authentication introduction
List the regular mailbox service, Quentn campaigns, website submissions, password resets, billing mail, and any other known use of the same From domain. For each, identify its real SMTP route. A website's public A record does not prove that the website sends email directly from that address. It may submit through a different provider. Authorizing the website address without checking the route can add unnecessary permission while leaving the actual mail path unfixed.
SPF belongs to the SMTP identity evaluated by the receiving server. Maintain one SPF policy at a given owner, merge only required authorizations, and evaluate the DNS lookup limit after changes. Do not create a second v=spf1 record next to an existing one. Do not assume an SPF pass for a provider-controlled envelope domain aligns with the visible organization-owned From domain. SPF RFC 7208
Record what was added, what was retained, and why. If the provider-issued SPF instruction is unclear or differs from a public example, obtain clarification for that account before publishing. This draft does not prescribe a universal Quentn include hostname.
Verify DKIM and DMARC on actual campaigns
Use a small controlled test representing the production campaign route. From the receiver's trusted authentication assessment, capture the From domain, envelope domain, DKIM signing domain, selector, and results. The DKIM signature's d= and s= values identify the public-key lookup; a general DNS scan that guesses selectors is not sufficient evidence. DKIM RFC 6376
For DMARC, establish which passing mechanism aligns with the visible From domain and which alignment mode applies. A passing aligned SPF result or a passing aligned DKIM signature can satisfy DMARC. The mere existence of three types of DNS records cannot establish that a particular message authenticated. Strict alignment must be checked using the actual domains, not an assumption that every subdomain is equivalent. DMARC RFC 9989
Preserve the existing DMARC policy while investigating unless the authorized domain owner approves a change. A monitoring policy and an enforcement policy serve different purposes. Do not paste an example p=reject policy into a shared organizational domain before validating its legitimate routes. Reporting destinations also need an owner, access controls, and appropriate review for the data they may receive.
Use the organization's approved access process for DNS work. The administrator can publish the public records without emailing domain-host passwords or session tokens to anyone. Keep secrets out of support tickets, screenshots, and article evidence. A provider support conversation should begin with the safe record names, public values, relevant timestamps, and exact error.
Quentn acceptance worksheet
The following is a proposed worksheet, not completed customer evidence. Keep a separate entry for owned-domain and Quentn-domain sending.
- Identity choice: sender type, visible address, campaign, business owner, reply destination, and whether the default selection changed.
- Address control: confirmation recipient, completion status, and reply test result, without storing confirmation links.
- Domain control: domain entered, authoritative DNS owner, current tenant instructions, and verification status.
- Public DNS: every generated owner, type, value or target, previous state, TTL, query time, and observed answer.
- Other senders: mailbox, website, membership, transactional, and remaining routes using the domain.
- Received campaign: safe test identifier, receiver, timestamp, From, envelope domain, DKIM d= and s=, and trusted authentication results.
- Acceptance: aligned mechanism, untested routes, support questions, rollback owner, and human approval status.
Fictional diagnosis of confirmed but unauthenticated mail
This example is fictional. A campaign owner confirms a new sender inbox and sees the address available in Quentn. A test reaches a recipient with a failing DMARC result. The team initially assumes the confirmation email completed authentication.
The investigation separates the address confirmation from domain verification. The DNS administrator finds that records were added to an inactive hosting zone, while the authoritative zone still lacks the required public configuration. The proposed repair is to publish the current account's issued values at the active host, check Quentn's verification state, and repeat the same campaign test. A reply test is also repeated because a correct sender identity does not validate reply routing. This scenario records a diagnostic method, not an observed incident.
Scope holds and review gates
No live Quentn account, issued DNS set, customer zone, or received campaign was inspected. Exact record types, targets, selector values, and signing behavior remain account-specific evidence requirements. The candidate deliberately avoids a universal SPF include and does not adopt unsafe credential-sharing instructions from the source. Human SME review, visual reader review, live authentication tests, and publication approval remain pending.
Mark the unknowns in the fictional case
In the fictional inactive-zone case, the campaign DMARC failure is an assumed input. Exact SPF and DKIM results, signing selectors and tenant-issued records are deliberately unspecified. Do not turn that scenario into a claim that a particular Quentn selector failed. The next evidence is the current issued record set, authoritative response and fresh receiver result, gathered by authorized owners.
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.