Identify the Blackbaud product and route first
Blackbaud has several email workflows, so one domain-authentication page should not be treated as a universal setup for every product. This manuscript scopes its concrete route to the Development Agent email workflow documented in the Raiser’s Edge NXT help area. The retained Configure your agent's email guide describes that workflow's address, forwarding, authentication and test sequence. It is not a blanket instruction for all Blackbaud mail.
A separate Email Domain Authentication portal guide describes organization-level domain claiming and TXT-based verification. Keep these sources separate rather than merging their controls into a fictional single screen. The actual product and tenant must confirm which process applies. No Blackbaud account was opened, address selected or configuration changed during this work.
Treat the agent address as a consequential decision
The Development Agent guide instructs the organization to choose a permanent agent email address and warns that it cannot be changed. That makes address selection an owner decision, not a disposable troubleshooting value. Record the business owner, intended organizational domain and long-term naming choice before an authorized operator proceeds. Do not create or enter an address merely to discover the next page.
The source recommends a forward-only inbox where possible and says it need not be monitored or used for sending manually. Those are route-specific operational instructions. They do not establish that a normal employee mailbox should be replaced or that all Blackbaud replies follow the same routing. The acceptance plan should identify the exact inbox and forwarding responsibility without collecting passwords or exposing private mailbox contents.
Separate required and optional configuration
The documented Inbox configuration page provides values for the IT team rather than asking the operator to invent them. It lists forwarding to the supplied inbox and DKIM as required, DMARC as recommended, and bounce and tracking domains as optional. Preserve those labels as product guidance while separately reviewing the organization's own authentication requirements. Optional in this workflow does not mean irrelevant to every business or alignment objective.
Use the Copy controls described by the guide to obtain the actual authorized values when setup is performed. This manuscript supplies no account-specific destinations, selectors or keys. The record plan must identify the exact DNS owner and type for each value from the current tenant. A tracking domain, bounce domain and DKIM owner have different purposes and should not be treated as interchangeable branding fields.
Handle the SPF instruction within its stated scope
The Development Agent guide includes a conditional SPF instruction associated with an existing SPF record and the bounce-domain path, using a SparkPost-related mechanism. That does not authorize adding a broad provider include to every organizational domain. The operator should preserve the exact tenant-supplied context and ask which SMTP identity the record is intended to authorize before preparing a change.
RFC 7208 defines SPF evaluation of the relevant SMTP identity and the logical DNS-query-term limit. Existing approved senders must be preserved in one coherent SPF policy, and multiple SPF records are not a valid merge strategy. This draft deliberately does not turn the guide's conditional example into a universal copy-and-paste record. No provider dependency or live DNS path was evaluated.
Keep central domain verification distinct
The central Email Domain Authentication guide describes claiming a domain in the portal reached through app.blackbaud.com, Admin, Settings, Email. It states that domain ownership, DKIM and DMARC verification details supply values for DNS TXT records. Those documented steps may apply to the relevant organization's central configuration, but they do not replace the Development Agent's separate forwarding and connection-test requirements.
The guide warns that third-party consumer domains such as public webmail addresses cannot be authenticated for Blackbaud sending in that process. It also says to copy supplied values exactly and notes that DNS providers have different entry conventions. The article retains these as source-scoped instructions, not evidence that any domain has been claimed or verified. A portal Verified label would be an observation to collect later, not a result already achieved here.
Preserve published DNS evidence
For an authorized change, retain the old complete record set, proposed exact diff, owner approval and restore material. RFC 1035 defines TXT record structure; split strings within one record differ from multiple records. Compare the published owner and value with the current tenant's instructions rather than treating a saved editor field as proof of publication.
Record authoritative and recursive observations separately with timestamps. The Blackbaud sources discuss propagation delays, but those time windows should not become a promise that waiting alone resolves a wrong owner name or malformed value. A discrepancy needs evidence of the actual published state and the requested target. No DNS observation or publication was performed for this draft.
Understand what the documented test does
The Development Agent guide says to wait for the IT team to confirm configuration before selecting Start email test. It describes a retry option after correction and notes that public DNS tools can validate while the email test still fails. It also states that completed provisioning, including the forwarding test, leads into the agent workflow and that email configuration is no longer accessible after setup is complete. These are meaningful workflow boundaries.
The test is an operational action involving the configured route, not a read-only documentation check. This manuscript did not start it, retry it or send any message. An authorized test plan should identify the expected forwarding behavior, evidence to retain and the owner who decides whether setup can be finalized. Do not click through completion merely because a DNS checker is green.
Build the exact-route identity table
An authorized received sample should record the Development Agent workflow, sending time, intended From address, observed envelope identity, DKIM signing domain and selector, trusted receiver results and alignment. RFC 8601 requires attention to the trust boundary for authentication assertions. RFC 9989 defines alignment to the visible From domain; an isolated SPF or DKIM pass is not enough without the relevant identity relationship.
Keep the forwarding-test outcome separate from outbound authentication. A working reply route does not by itself prove aligned signing, while a signed outbound message does not prove replies reach the intended agent inbox. The worksheet should retain both observations where the product workflow requires them. Neither result guarantees inbox placement, engagement or legitimacy of every future message.
Fictional diagnosis: verified DNS but incomplete forwarding
A fictional organization sees its public DKIM data resolve correctly and assumes Development Agent provisioning is complete. The product's email test remains unsuccessful because the acceptance evidence has not established the required forwarding route. The proposed investigation separates DNS publication, outbound identity and forwarding rather than repeatedly replacing the DKIM key.
The actual cause would need authorized evidence; this example does not claim that forwarding was observed to fail. It is a fictional diagnostic exercise with no real address, tenant, test or constituent message. It illustrates why the exact product workflow matters and why central authentication status cannot substitute for every route-specific step.
Release status
The catalogue requires current Blackbaud setup evidence and a received-message identity table from the exact product and route. The Development Agent and central-portal documents are retained, but product applicability, tenant values and original operational evidence remain open. All six release gates remain open. No permanent address was chosen, credentials generated, DNS changed, test triggered or setup finalized, and this draft makes no claim of completed authentication.