Limit the plan to the documented Drift sending domain
The official “Drift - Setting Up Email Sending Domains (DKIM)” page is dated 6 October 2026 and appears under Legacy Drift. It describes paid plans starting with Premium, an administrator audience and one sending domain per instance. The illustrated route includes fallback email and meeting reminders. Its path is Settings, App Settings, Chatbot, Communication, then Edit sending domains. Add Domain starts setup; View and Verify DNS settings expose the required account-specific entries. Publish those entries through the authorized DNS operator and complete verification. Its SPF FAQ gives route-specific sending addresses, not a universal recipe for every related product. Drift sending-domain guide
This manuscript applies only to that bounded workflow. It does not authenticate connected personal mailboxes, every Drift Email bot route, another vendor with a similar name or a successor product by implication. The actual subscription, interface, sending identities and generated records have not been inspected. The broader catalogue implementation requirement therefore remains open even though the documented workflow can inform a useful change plan.
Resolve the one-domain decision before publication
An instance-level sending identity is an organizational decision. Before anyone requests records, list the teams sharing the instance, the message categories in scope and the visible From address expected for each. If several brands or customer organizations are involved, determine who is authorized to choose the domain and who can approve use of that identity. Do not assume that a single completed domain setup automatically authorizes every unrelated brand address.
A practical planning record should identify the current domain, the proposed domain, the reasons for any change and the message categories that could be affected. Keep the intended reply behavior as a separate field. A recipient can see one author address while a reply is directed elsewhere, and neither field alone identifies the SMTP envelope used for SPF. The record should make these distinctions clear without collecting private correspondence unnecessarily.
Where the available product configuration cannot meet the intended identity requirements, retain a product-fit decision rather than constructing guessed DNS records. A DNS administrator cannot increase application capabilities by adding more selectors or domains to a zone. Similarly, changing a domain in an application is not a harmless display edit when existing routes, approvals and recipient expectations depend on it. This is proposed governance, not a claim that any particular account has those dependencies.
Treat generated records as a controlled handoff
Capture the actual account instructions in an approved change record when an authorized administrator obtains them. Preserve the record owner, type and complete value as separate fields, together with the sending domain and account context. Avoid manually reconstructing a public key from a screenshot or copying a selector from another organization. The public DNS data can be shared with the responsible DNS operator; private keys and account credentials do not belong in this handoff.
A DKIM signature contains a selector and signing domain that tell a receiver where to locate verification material. This protocol relationship is why exact owner names matter. Publishing a key under a similar-looking but different name does not make it available to the signature that actually references another selector. Nor does publishing a key prove that the application signed the message with its corresponding private material. RFC 6376, sections 3.5 and 3.6.2.2
Review DNS-editor behavior before entering the records. The intended fully qualified name should be written independently of the editor's Host or Name field. Some interfaces append a zone suffix to relative input; the operator must follow the actual DNS host's rules rather than a universal shortcut. DNS master-file conventions and a provider's graphical editor are not interchangeable instructions. Preserve the source value and compare the resulting published owner against it. RFC 1035, section 5.1
Keep TXT formatting separate from key policy
TXT resource records can contain multiple character strings. A long logical value may therefore appear split in a DNS interface without becoming several independent records. Distinguish string boundaries within a record from separate resource-record values at the same owner. Confirm the logical content expected by the verifier rather than treating line wrapping or presentation quotes as evidence of a new key. RFC 1035, section 3.3.14
A key-length choice is also separate from DNS formatting. Apply current supported implementation requirements and the organization's security policy; do not convert an older interface default into a universal cryptographic recommendation. If the supported choice and organizational requirements conflict, leave that decision open for the responsible administrator. This article does not generate keys, supply private material or claim that a specific key choice has been validated in the tenant.
The public record is only one part of acceptance. The change owner needs evidence of the application's intended signing configuration and, after an authorized test is separately arranged, the signature actually received. A green domain state can be useful operational information but should not replace a message-level review. Keep configuration status and observed authentication results in different worksheet fields.
Reconcile SPF without replacing unrelated senders
Any proposed SPF authorization must match the current route and the SMTP identity actually used. Do not assume that values documented for one application feature apply to all products in the same corporate family. Obtain current applicable egress details before proposing a policy change, and retain the existing legitimate senders rather than replacing the entire policy with a short example.
SPF evaluates the relevant MAIL FROM identity, with HELO used in the applicable cases. Its policy is published as TXT, and multiple applicable SPF policies do not combine into a larger permission set. The DNS-querying evaluation limit concerns evaluated terms, including nested dependencies, rather than merely the number of visibly listed top-level includes. These protocol rules apply regardless of the application's account status. RFC 7208, sections 2.3–2.4, 3.1–3.3 and 4.6.4
A passing SPF result can still be unaligned with the visible From domain. Likewise, a valid DKIM signature can identify a different domain that does not meet the required alignment relationship. DMARC accepts a qualifying aligned SPF or DKIM result, but it does not turn every unrelated pass into success. Record the actual identities and results before drawing a conclusion. RFC 9989, section 4.4
Fictional diagnosis: the wrong evidence answered the question
Imagine a fictional business, Fernline Services, whose operations team prepares a sending-domain change. The DNS operator confirms that a public TXT record exists. Another team then presents a successful message from its ordinary employee mailbox and declares the application ready. Neither observation, by itself, establishes how the intended application route signs its messages. This is a fictional review exercise; no account or message was tested.
The reviewer separates the evidence. The DNS record is compared with the account's actual instructions, while the employee-mailbox message is classified as evidence for a different route. The planned application message remains unverified until an authorized sample from the intended category is available. The team does not weaken DMARC, overwrite another sender's SPF authorization or infer broad product support merely to close the checklist.
Blank route acceptance worksheet
- Applicable Drift product, plan, instance and current documentation check: ____.
- Approved sending domain and business owner: ____.
- In-scope message categories and excluded routes: ____.
- Expected visible From, reply address and envelope identity: ____.
- Actual generated DNS owner, type, value and source reference: ____.
- Authoritative DNS operator and fully qualified owner review: ____.
- Existing SPF senders and proposed route authorization: ____.
- Application verification state, timestamp and unresolved errors: ____.
- Authorized received-message selector, signing domain and alignment result: ____.
- Rollback conditions, key-policy decision and release approver: ____.
The worksheet is intentionally unfilled. Original evidence, human/SME review, source applicability, production routes, visual/accessibility review and owner release remain open. No tenant actions, DNS changes, key creation or messages were performed. Even successful authentication would not guarantee inbox placement or establish that a business request is safe. RFC 9989, section 2.4