To authenticate Blackbaud Development Agent email in Raiser’s Edge NXT, use the records and forwarding destination supplied during agent onboarding, configure the intended signing domain, and verify the actual outbound and reply paths. Do not substitute a generic Blackbaud SPF include or treat central domain verification as proof that this agent is ready. The agent’s email setup and the organization’s Email Authentication Settings portal are separate workflows. Development Agent email configuration, central domain authentication.
This guide covers Development Agent, not Award Management, AcademicWorks, Stewardship Management, eTapestry or every other Blackbaud sending product. No customer account, public DNS or delivered-message test was performed for this guide.
Confirm the product and approve the permanent address
Start in Portfolio > Development Agent in Raiser’s Edge NXT and open the onboarding tasks. The agent’s email address cannot be changed after creation. Choose the long-term address and domain with the person responsible for donor communications before entering it. A display-name change is not an email-address change. Blackbaud onboarding.
Before configuration, assemble:
- An approved organizational From address, such as the illustrative
agent@example.com. - Access to the relevant Blackbaud account and an administrator who can obtain its current configuration values.
- The authoritative DNS administrator, which may be different from the website host or domain registrar.
- A mailbox administrator responsible for the agent’s reply-forwarding route.
- A safe test plan using controlled recipients, not a live constituent campaign.
- A before-change export of relevant DNS records and a record of existing working mail services.
Do not start with a public webmail address that your organization cannot authenticate. The central Blackbaud guide excludes consumer domains such as Gmail and Yahoo from this domain-authentication process. A domain claimed for single sign-on does not count as a domain claimed for email. Blackbaud domain requirements.
Collect the agent’s exact setup values
The agent’s Inbox configuration screen supplies values for the IT team. Forwarding and DKIM are required; the page labels DMARC recommended and bounce and tracking domains optional. It recommends a forward-only inbox where possible. Use its Copy controls rather than transcribing an example. Those labels describe this screen, not permission to ignore organization-wide policies. Agent configuration requirements.
Record each item separately:
| Item | Purpose | Evidence to retain |
|---|---|---|
| Forwarding destination | Deliver replies to the agent’s supplied inbox | Exact destination, forwarding rule owner and test result |
| DKIM | Sign agent email using the intended domain | Record type, full owner, public value or target, selector, signing domain and activation status |
| Bounce domain | Identify and handle delivery failures | Account-issued owner/type/value and expected envelope MAIL FROM domain |
| Tracking domain | Support the selected engagement-tracking configuration | Separate hostname and record requirements |
| DMARC | Express the domain owner’s authentication policy | Effective policy, alignment settings and report destination |
Before activating forwarding or any routing record, compare the exact supplied destination, addresses and record types with the owner-authorized reply-routing plan. An account-supplied destination is not itself permission to forward private donor replies. Resolve any mismatch with the mailbox and communications owners, then use only a controlled, non-sensitive reply test.
These are not interchangeable DNS records. A tracking hostname does not authorize sending. Forwarding a reply does not prove the original outbound message authenticated. Publishing a public DKIM key does not prove the service has started signing with its corresponding private key. Never publish or request a private signing key for this DNS task. DKIM specification.
Apply SPF only to the identity the route uses
SPF checks the SMTP envelope MAIL FROM domain, usually visible in the delivered Return-Path, rather than simply checking the address shown to the recipient. Record that identity before deciding which DNS owner needs authorization. A record at example.com does not automatically apply to bounce.example.com. SPF identities and record selection.
For its conditional existing-SPF/bounce-domain instruction, Blackbaud documents the following mechanism:
exists:%{i}._spf.sparkpostmail.com
This is a mechanism fragment, not a complete SPF policy. The same page also refers to an existing policy containing include:sparkpostmail.com. Ask the current agent setup or Blackbaud to confirm the expected envelope domain and which authorization applies. Do not add both forms indiscriminately, or add them to every organizational domain. Agent-specific SPF instruction.
At a customer-managed SPF owner, merge an approved change into the one existing v=spf1 TXT record before its terminal all mechanism. Preserve active staff-mail and other service authorizations and the existing approved qualifier. If the record uses redirect=, review that design rather than blindly adding an all mechanism: any all makes redirect ignored, and mechanisms after all are unreachable. Preserve the reviewed redirect-based authorization and final semantics. SPF -all failure does not guarantee receiver rejection. SPF all and redirect rules.
Evaluate nested dependencies against SPF’s ten DNS-lookup-term limit. include, a, mx, ptr, exists and redirect can consume that budget; ten visible includes is not the correct test. Do not solve a limit problem by adding a second SPF record, using +all, or deleting working senders. SPF DNS limits.
If the actual envelope uses a provider-owned domain, adding authorization to your unrelated apex does not turn that SPF result into an aligned result. The intended branded DKIM signature must still be tested. A provider-owned SPF pass and an actual SPF error are different conditions.
Keep central authentication separate from agent provisioning
Where your organization uses Blackbaud’s central portal, open app.blackbaud.com > Admin > Settings > Email. Add the domain, open its details and obtain the DNS TXT values for ownership, DKIM and DMARC. The official guide says to repeat this for each sending domain or subdomain, and describes automatic DNS checks and a confirmation email. Allow its stated verification window of up to 72 hours without treating that as a guarantee. Central Email Domain Authentication.
Central verification is useful evidence, but it is not the agent’s forwarding test or proof of an outbound signature. Keep both records of work: the central domain status and the agent-specific configuration. If the two screens request different selectors, record types or values, confirm whether they serve different routes before editing either. Do not overwrite a working key merely to make two screens look identical.
If a required DMARC record already exists, preserve it. Reconcile a portal request with the DNS administrator instead of publishing a second DMARC policy or replacing a stronger policy with a starter example.
Put each record at the correct DNS owner
Use the record type and full hostname issued by the current configuration. The following names are illustrative name-mapping examples, not Blackbaud-issued values. Replace selector, domains and hostnames with the actual instructions.
| Intended full owner | Relative name in the example.com zone |
Relative name in a delegated mail.example.com zone |
|---|---|---|
example.com |
@ or blank, according to the host |
Not in this zone |
bounce.example.com |
bounce |
Not in this zone |
selector._domainkey.example.com |
selector._domainkey |
Not in this zone |
selector._domainkey.mail.example.com |
selector._domainkey.mail, only if the parent serves those records |
selector._domainkey |
_dmarc.mail.example.com |
_dmarc.mail, only if the parent serves those records |
_dmarc |
If _domainkey.mail.example.com is delegated, full owner selector._domainkey.mail.example.com maps to relative name selector in that zone. Preserve the NS delegation and its other users.
If a child zone is delegated, edit its authoritative service, not an ineffective record left in the parent. Check whether the DNS console appends the zone name: entering a full name in the wrong field can create selector._domainkey.example.com.example.com.
Do not replace existing MX records or mail routing to authenticate this sender. If a supplied record is a CNAME, it cannot coexist with ordinary TXT, A, AAAA, MX or another CNAME target at that same owner. Resolve the conflict with the affected service owners; do not delete unrelated data. A separate selector normally allows separate services to keep their keys. DNS aliases and zones.
If the current issued configuration specifically requires a CNAME, keep that authentication alias DNS-only and unflattened so its target remains publicly visible. In Cloudflare, turn the relevant per-record Flatten option off where available and ensure the zone-wide CNAME flattening for all CNAME records setting does not suppress the required literal alias. Zone-wide flatten-all cannot be overridden per record. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the selected setting; DNS-only by itself is not sufficient. If mandatory behavior cannot preserve the required CNAME, stop and coordinate a supported layout rather than assuming an off switch exists. Coordinate any shared-setting change with the DNS owner and affected services. Preserve valid subdomain delegation and publish at its authoritative provider instead of deleting NS records to force verification. This conditional safeguard does not mean every Blackbaud route issues a CNAME. Cloudflare CNAME verification, flattening settings.
TXT presentation can contain multiple quoted character strings within one resource record. Those are not the same as multiple separate SPF records. Preserve the complete public value, including key material, without truncation or smart quotes. TXT record format.
Preserve DMARC and arrange reporting
DMARC compares the visible From domain with a passing SPF or DKIM identity. One passing, aligned mechanism is sufficient for protocol DMARC pass. Relaxed alignment permits the same organizational domain; strict adkim=s or aspf=s requires an exact domain match. For this DKIM setup, require the intended branded signature to pass and align even if another path already produces DMARC pass. Current DMARC specification.
For example, a passing intended signature with d=mail.example.com and visible From agent@example.com aligns in relaxed mode when both share Organizational Domain example.com, but not in strict mode. Passing d=example.com matches that From domain in both modes. These are illustrative identities, not an observed Blackbaud signer.
Review the policy for the actual From domain and its applicable parent policy. Do not assume every sender is governed only by an apex record. Do not lower p=reject or p=quarantine to accommodate incomplete agent onboarding.
Only where no direct or applicable inherited policy exists, the domain owner explicitly approves monitoring, and someone will review reports, a DNS administrator could adapt this non-production example:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the report address with an approved, monitored destination. For this apex example, the relative owner in example.com is _dmarc. For an approved policy on From mail.example.com, full owner _dmarc.mail.example.com maps to _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. Do not create a child monitoring override of inherited enforcement.
Compare the Organizational Domain of the report URI host with that of the domain where the DMARC policy was found. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted even when its hostname differs. Coordinate any required authorization with the report operator and separately obtain owner approval for sharing report data. RFC 9990 section 4. Aggregate reports can show unexpected sources and authentication failures, but do not replace a message test or prove inbox placement. Do not add forensic reporting casually: it has privacy implications and uneven receiver support.
Verify DNS, outbound authentication and forwarding
Use read-only DNS lookups before an authorized email test. In these command examples, replace every illustrative domain, selector and nameserver with the actual setup. ns1.example.net means the authoritative server for the queried owner, not necessarily the apex domain’s server.
dig +short NS example.com
dig @ns1.example.net selector._domainkey.example.com TXT +noall +answer
dig +short TXT selector._domainkey.example.com
dig +short TXT bounce.example.com
dig +short TXT _dmarc.example.com
Query CNAME as well if that is the issued record type, then inspect the target’s public TXT record. Compare authoritative and recursive answers. Confirm the exact owner, full value, one applicable SPF policy, the intended DMARC policy and no conflicting CNAME. A blank result, NXDOMAIN or SERVFAIL needs diagnosis; it is not a successful propagation check.
After IT completes configuration, an authorized operator can run Start email test, then Retry email test after a correction if needed. Blackbaud gives an agent-specific propagation estimate of 24 hours or more, separate from the central portal’s up-to-72-hour verification window. It warns that public DNS can validate while the product test still fails. It also says the email configuration becomes inaccessible after setup completes. Preserve configuration evidence before finalizing. Agent connection test.
For a new message from the real agent route to a controlled receiver, inspect the original headers and the receiving system’s trusted Authentication-Results. Do not accept a sender-inserted header as proof. Authentication-Results trust boundary. Establish trust through receiver-controlled diagnostics or the mail administrator’s confirmation of which fields are generated inside its known processing boundary and how externally supplied Authentication-Results are stripped or distinguished. Ignore attacker-supplied fields. A familiar authserv-id name or a header’s position alone does not establish that trust; both can mislead when untrusted results are retained. RFC 8601: forged authentication headers.
| Acceptance check | Required observation |
|---|---|
| Correct route | Message came from Development Agent, not a staff mailbox or another Blackbaud product |
| Branded DKIM | dkim=pass for the expected header.d/d= and selector s=, with alignment to the visible From domain |
| SPF result | Inspect the actual smtp.mailfrom identity; distinguish unaligned pass from fail, softfail, neutral, none, temperror or permerror |
| DMARC | dmarc=pass for the intended From domain under the effective policy |
| Reply forwarding | The approved reply test reaches the supplied agent destination without a loop or unintended delivery |
| Provisioning | Required product tests completed; retained evidence supports the decision to finish onboarding |
Do not accept a provider-rewritten From or SPF-only DMARC pass as proof that this intended branded DKIM setup works. A real SPF failure or error remains an investigation item even when DKIM supplies DMARC pass. For a failed original send, check the envelope owner and policy evaluation; for a forwarded copy, compare the direct-delivery baseline. An SPF fail calls for checking authorization for the actual envelope and connecting IP; permerror calls for syntax, duplicate-policy and evaluated DNS-budget checks; temperror calls for investigation of temporary DNS availability or other transient evaluation failures. SPF result meanings. Reply forwarding and outbound authentication must both be checked because they solve different problems.
EmailAuth's raw-versus-aligned DKIM guide explains why signature verification is distinct from alignment with the intended From.
Troubleshoot the layer that failed
DNS is correct but the agent test fails. Compare the issued records and forwarding destination with the implemented configuration. Check recipient routing, aliases and forwarding restrictions. Save the test time and error for Blackbaud rather than repeatedly replacing a correct DKIM key.
DKIM passes for an unexpected domain. Inventory all signatures. A provider signature is not proof that the requested organizational signing domain is active. Check the selected From domain, selector and activation state.
SPF passes but DMARC fails. Compare the envelope and DKIM domains with the visible From domain and the strict/relaxed settings. More SPF includes cannot fix an unrelated envelope domain.
SPF produces permerror. Check duplicate SPF policies, syntax, redirect/include dependencies and the full lookup budget. Preserve other working authorizations while correcting the actual defect.
Mail authenticates but lands in spam. Investigate the receiver’s response, domain reputation, consent, content and complaint history. Authentication does not certify the message is wanted or guarantee inbox delivery.