Limit the implementation claim to Award Management
Blackbaud’s product documentation supplies a dedicated procedure for Award Management and Stewardship Management. This article focuses on Award Management and does not assume that instructions for Raiser's Edge NXT, Development Agent or Luminate are interchangeable. A shared company name does not make product settings, selectors or onboarding processes identical.
The retained page instructs organizations to have DMARC configured before completing its setup. Treat that as a product prerequisite to assess with the domain owner, not permission to overwrite an existing organizational policy. Record the Award Management site, responsible administrator, intended sender and the business workflows being reviewed before opening a change request. No live site settings were inspected here. Blackbaud Award Management: Set Up DMARC Compliant Emails
Find the sending domain through the documented setting
The procedure begins in Site, Settings, Content and uses Email Settings, DMARC DNS Setup. It directs the administrator to obtain the sending domain from the Site Email field by taking the text after the @ character. That is a concrete product-specific starting point, not evidence that every message from the broader Blackbaud portfolio uses the same address.
Preserve the intended address and domain in a restricted working record while minimizing unnecessary personal information. Check whether the site sends through additional workflows or identities that need separate review. An administrator should not infer that a domain associated with the organization’s website is automatically the actual sending domain configured in this product.
Before making changes, identify the authoritative DNS administrator. The registrar may also host DNS, but that relationship must be confirmed rather than assumed. A proposed change entered in an unrelated registrar panel will not establish the required public state. Award Management product procedure
Generate the unique records and preserve the before state
The guide instructs the administrator to enter the domain and select Create Domain to generate unique DNS records. It then directs the user to copy the records from Email DMARC DNS Settings and publish them through the organization’s DNS administrator. This is why a guide should not invent universal selectors or reuse values from another customer or Blackbaud product.
Retain the record owners, types and values exactly as supplied for the actual site, together with the generation time and product context. Compare them with existing records before approval. Identify whether a proposed owner already contains data, whether the DNS editor appends the zone suffix and whether another service depends on the same name.
The product page does not authorize broad DNS cleanup. Do not remove unrelated DKIM selectors, replace a complete SPF policy or create duplicate DMARC policies merely because the generated configuration appears self-contained. Any conflict needs a scoped decision by the relevant domain and mail owners. Award Management: Create Domain and copy DNS records
Preserve DMARC policy ownership
An existing DMARC policy can cover several legitimate sending routes. The product’s setup objective should be integrated into that wider inventory rather than treated as an isolated policy island. Verify which policy applies to the actual From domain and preserve current reporting destinations, alignment choices and approved enforcement decisions unless a separately reviewed change is required.
DMARC depends on aligned authentication, not simply on the presence of DNS records. A raw SPF or DKIM pass under an unrelated identity does not necessarily satisfy alignment for the Award Management From domain. The proposed implementation review should therefore connect the product’s configured domain to the identities observed on an authorized received message.
The core standard does not make a provider configuration screen a substitute for receiver evidence. Keep the documentary setup, public DNS state and message evaluation as different layers. This also prevents a successful product check from becoming an unsupported promise of inbox placement. RFC 9989, section 4.4 and 5
Use Verify as one acceptance step
After publishing the unique records, the product guide tells the administrator to return to Email DMARC DNS Settings and select Verify. It directs users to DNS support if validation is unsuccessful. Capture the actual result, time and scope when this step is eventually performed under authorization. This manuscript does not claim that Verify was clicked or that any domain passed.
A successful validation should be accompanied by retained authoritative answers for the intended owners. It does not by itself demonstrate every production message route, receiver or cache state. If the validation fails, compare the generated values, fully qualified names, record types and actual authority before changing unrelated configuration.
Do not use repeated speculative edits as a substitute for diagnosis. An unresolved DNS response, wrong account context or stale generated value needs a specific explanation. Keep the original supplied records and the observed discrepancy together so the next reviewer can reproduce the investigation. Award Management: Verify
Acceptance worksheet and fictional diagnosis
The worksheet should identify the Award Management site, Site Email domain, generated-record set, current records, proposed diff, DNS owner, approval and product verification result. A separate received-message table should include the exact workflow, From domain, envelope identity, DKIM d= and s= values, trusted authentication results and alignment interpretation. Redact unrelated recipients and message content.
Imagine a fictional administrator who copies a selector from another Blackbaud guide because the company name matches. The product’s Verify step would not establish correctness merely because that other selector exists. No real validation was performed for this example. The correct review would return to the Award Management-generated records and compare their owners and values with the authoritative answers.
A second hypothetical issue is a correct DNS record paired with a message from an unexpected Site Email domain. That requires route and identity review, not automatic repetition of the DNS change. The acceptance decision should remain bounded to the site and workflow actually evidenced, with other routes explicitly unresolved.
Operational evidence and publication hold
The catalogue requires current Award Management first-party setup evidence and a received-message identity table from the exact product and route. The retained product guide supports the described configuration sequence. Actual site access, generated records, authoritative answers, Verify outcome and received-message evidence remain open.
No DNS record was created, no product setting changed and no message was sent. All six release gates remain open. Before operational publication, a qualified reviewer must confirm that the current site uses this workflow and that the final evidence supports the intended alignment claim. Broader Blackbaud product coverage remains outside this narrow documentary implementation scope.