For Blackbaud Award Management, use Site → Settings → Content → Email Settings → DMARC DNS Setup to generate the unique DNS records for the domain in Site Email. Publish those records, return to the application and select Verify. Blackbaud requires an existing DMARC policy for this custom-DKIM workflow. Treat SPF separately: its policy belongs to the actual envelope-sender domain, not automatically the address displayed to applicants. Award Management setup.
On this page: Scope and prerequisites · SPF decision · Generate and publish DKIM · DMARC policy · DNS checks · Message acceptance · Troubleshooting · FAQs · Review boundary
Scope and prerequisites
This guide covers the current Blackbaud Award Management sending workflow associated with the former AcademicWorks name. It does not apply Raiser’s Edge NXT, Luminate Online or another Blackbaud product's selectors to Award Management. Blackbaud's joint Award/Stewardship documentation supports custom DKIM; this walkthrough focuses on Award Management and its Site Email domain. Product-specific DKIM support.
Arrange access to the Award Management settings, an administrator for the authoritative DNS zone, and an approved test workflow. An institutional domain may also serve staff mail, admissions and fundraising. Coordinate changes with the team responsible for that shared domain before scholarship notifications are due.
Record these identities separately:
| Item | Where to establish it | Why it matters |
|---|---|---|
| Award Management site and workflow | Your actual account and notification configuration | Authentication must be checked on the route applicants use |
| Visible From domain | The Site Email field, then a received message | This is the domain DMARC protects |
| Envelope MAIL FROM domain | Trusted receiving-server results and Return-Path | This is normally the SPF evaluation domain |
| DKIM domain and selector | Issued DNS instructions, then the message's d= and s= |
These locate the public key and establish signing identity |
| Applicable DMARC policy | Exact From domain and policy discovery | An existing institutional policy may already cover it |
The domain after @ in Site Email is the starting point for Create Domain. An academicworks.com login hostname, the university website name or a Reply-To address is not a substitute for that field. Confirm any additional From domains before assuming one setup covers all notifications.
Decide whether your domain needs an SPF change
SPF checks the connecting server against the policy for the SMTP MAIL FROM domain. For mail with an empty reverse-path, SPF uses the HELO identity; that is not a reason to substitute a HELO pass for the MAIL FROM identifier in current DMARC evaluation. SPF identity rules, DMARC SPF identifier.
If the actual envelope uses a Blackbaud-owned domain, Blackbaud controls its SPF policy. Adding an include to your institution's visible From domain cannot change the envelope identity or make an unrelated provider domain align. Use custom DKIM for the branded signing path and verify what the real message uses.
Blackbaud's product-specific SPF reference identifies include:_spf.academicworks.com for Award Management and Stewardship Management. Its retained SPF help page shows this single-service example:
v=spf1 include:_spf.academicworks.com ~all
This is not a replacement policy for an institution already sending mail. Use the authorization only where Blackbaud's instructions for your route require an SPF policy under your control. The full accessible reference is a retained Blackbaud help page; the current knowledgebase sends readers to the Email Resource Center for the latest applicability. Confirm that applicability before changing a custom envelope arrangement. Do not replace this value with outboundmail.blackbaud.net merely because another Blackbaud product uses it. Blackbaud product-specific SPF reference, current SPF knowledgebase.
For an existing policy, add only the approved include before the existing final all mechanism. Preserve other legitimate senders and the approved final qualifier. Do not concatenate two complete v=spf1 policies or add a second SPF TXT record at the same owner. Multiple quoted strings in one TXT record may be one logical value; multiple separate SPF records are different and produce permerror.
SPF does not inherit from a parent domain. If the envelope domain is bounce.example.edu, a policy at example.edu is not its policy. Nor does a DNS-only SPF lookup prove that the production message uses the domain queried.
Count the full evaluation path: include, a, mx, ptr, exists and redirect are subject to the combined limit of ten DNS-querying terms, including nested dependencies. This is not ten literal include strings or ten packets. ip4, ip6 and all do not consume that term budget. Separate address-query and recommended void-lookup limits also apply. Avoid adding speculative authorizations or flattening provider ranges into a static list that will become stale. SPF record and lookup rules.
Generate and publish the Award Management DKIM records
Blackbaud's knowledgebase distinguishes its default provider-domain DKIM from custom DKIM for your sending domain. A valid signature under Blackbaud's own domain is not sufficient evidence of alignment with an institution's domain. DKIM signs message data; it does not encrypt the email for the recipient. Award Management custom DKIM, DKIM specification.
- Open Site → Settings → Content and read Site Email. Retain the intended address and domain in your change notes.
- Under Email Settings, select DMARC DNS Setup.
- Enter the sending domain in Domain. Use the portion after
@, without the mailbox name or a website URL. - Select Create Domain. The application generates unique DNS records for this configuration.
- In Email DMARC DNS Settings, copy every issued record's full owner, type and complete value. Keep the record set associated with the correct site and domain.
- Give those public DNS records to the authoritative DNS administrator. Publish the issued types and values rather than borrowing a selector from another customer or Blackbaud product.
- After DNS is correct, return to Email DMARC DNS Settings and select Verify. If validation fails, the product documentation directs you to DNS support. Complete product procedure.
There is no universal DKIM selector or public key to copy from this article. Publish only the supplied public record. Never publish a private key, password or API secret in DNS. If the interface offers a different flow, ask Award Management support to reconcile the current account with these instructions instead of creating records in a different product.
DNS placement and conflict checks
First confirm which provider actually serves the authoritative zone. A registrar can be different from the DNS host. If a subdomain or _domainkey zone is delegated through NS records, publish in that delegated zone, not in the parent zone's inactive copy. Keep the delegation unchanged unless its owner approves a separate migration.
For each issued name, determine whether the DNS editor expects the complete name or a label relative to its zone. For example, SELECTOR._domainkey.example.edu is the full owner; in the example.edu zone an editor may expect SELECTOR._domainkey. In a delegated _domainkey.example.edu zone it may expect only SELECTOR. Replace the placeholder with the issued selector and verify the resulting full name.
A CNAME owner must not also hold ordinary TXT, A or another CNAME record. Resolve a collision with the existing service owner rather than deleting a working selector. If Blackbaud issues a TXT value, preserve its complete key data, including any DNS-editor string splitting. DNS alias rules.
If an issued record is a CNAME and your DNS host offers proxying or flattening, it must remain publicly resolvable as the required CNAME. On Cloudflare, use DNS-only and no per-record flattening; also check whether zone-wide flattening overrides that choice. Coordinate any shared zone-setting change with its owner, and do not remove a legitimate NS delegation to force the parent panel's copy to work. Cloudflare CNAME verification, flattening behavior.
Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the CNAME Flattening setting. Where available, keep per-record Flatten off and ensure applicable whole-zone settings preserve the literal issued CNAME answer. If mandatory apex/same-zone behavior or shared settings prevent that answer, stop and coordinate a supported configuration without breaking other records or removing an existing delegation. Cloudflare flattening limits.
Preserve the institution's DMARC policy
Blackbaud requires DMARC to be configured before its custom-DKIM setup. Inspect the policy applying to the Site Email From domain; do not weaken an existing quarantine or reject policy to follow a tutorial. Preserve reporting recipients, adkim, aspf and relevant subdomain policy choices unless the domain owner separately approves changes.
DMARC passes when at least one passing DKIM signing domain or passing SPF MAIL FROM domain aligns with the visible From domain. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. A related subdomain can therefore align in relaxed mode but fail in strict mode. Use the applicable policy and receiver evidence, not a visual similarity between names. Current DMARC policy discovery uses the DNS tree walk described in RFC 9989; a missing TXT response at a subdomain alone does not prove there is no applicable policy. DMARC alignment and policy discovery.
If no policy applies, have the domain owner establish a monitored rollout before completing Blackbaud's workflow. This illustrative starter belongs at _dmarc.example.edu, and the mailbox must exist and be approved before use:
For that approved first policy, use type TXT. For From example.edu, the full owner is _dmarc.example.edu, or _dmarc in an editor relative to example.edu. For From news.example.edu, use full owner _dmarc.news.example.edu: the relative name is _dmarc.news in the parent example.edu zone, but _dmarc in a separately delegated news.example.edu zone. Publish at the actual authority, preserve its NS delegation, and do not add a child monitoring policy over existing inherited protection. DMARC record publication, relative DNS names.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.edu
p=none requests no DMARC enforcement; it does not by itself create reports. rua requests aggregate reports, whose arrival also depends on participating receivers and a working destination. For an external reporting service, follow its domain-specific authorization instructions. For example, reporting for example.edu to reports.example.net ordinarily requires authorization at example.edu._report._dmarc.reports.example.net, managed by the destination operator, not a guessed TXT record in example.edu. Do not copy a vendor's sample reporting mailbox or add failure reporting containing message information without a privacy review. DMARC aggregate reporting and external destinations.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Do not use pct as a modern percentage-rollout control; RFC 9989 removed it. Plan enforcement around the domain's actual mailflows, including forwarding and mailing lists, rather than escalating policy solely because Award Management validates.
Verify public DNS and the application status
The following are reader-run diagnostic examples, not tests performed for this guide. Replace every uppercase placeholder. Determine the authoritative zone for each owner, since the SPF, DKIM and DMARC records need not share one DNS operator.
dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NS ISSUED_DKIM_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS ISSUED_DKIM_OWNER TXT +noall +answer
dig +short TXT ISSUED_DKIM_CNAME_TARGET
dig +short TXT ACTUAL_ENVELOPE_DOMAIN
dig +short TXT _dmarc.ACTUAL_FROM_DOMAIN
Run the DKIM query matching the issued record type. A direct TXT record should match the supplied public key. A CNAME should match the issued target, whose lookup should lead to usable DKIM key material. Do not expect a TXT key directly at a CNAME owner from an authoritative server that does not host the target. Compare authoritative answers with recursive answers after the relevant TTL; an arbitrary 48- or 72-hour wait is not evidence of success.
For SPF, expect one applicable policy at the actual envelope owner with the intended senders authorized and no evaluation errors. For DMARC, check the exact From domain and the applicable discovered policy. Then run Verify in Award Management and record the result and time. A green application status is a configuration check, not proof that a notification was signed or delivered.
Verify a real Award Management notification
After an authorized setup, send a synthetic application or award notification from the actual workflow to controlled test recipients. Avoid applicant names, financial information and other real scholarship data. Where internal delivery matters, include a campus mailbox and an external mailbox: a university's local anti-spoofing rules may differ from an external provider's rules.
Inspect the original message at the final receiving system. Use its documented authentication summary or the Authentication-Results added by a receiver within your trust boundary. Do not trust an arbitrary header simply because it says pass; senders can insert lookalike headers. A familiar authserv-id or a header's position alone is insufficient. Require a receiver-controlled diagnostic or an administrator-established provenance chain, including confirmation of how the receiving system strips or distinguishes external Authentication-Results headers. Authentication-results trust boundary.
Accept this branded-DKIM configuration only when the record shows:
- The expected Award Management workflow and visible From domain.
dkim=passfor the intended custom signing domain, and that domain aligns under the applicableadkimmode. Record its selector as well. A passing unrelated provider signature is not the target outcome.- The expected envelope domain and an explainable SPF result. Require normal direct-route SPF success; investigate
fail,softfail,neutral,none,temperrorandpermerrorseparately even if aligned DKIM makes DMARC pass. dmarc=passfor the visible From domain, consistent with your own alignment comparison.- Correct reply behavior and usable notification delivery for the tested recipients, without generalizing one message to every workflow.
DMARC can legitimately pass through SPF alone. That still does not prove the custom DKIM setup you were changing worked. Conversely, aligned DKIM can pass DMARC when SPF is unaligned; this does not excuse an unexplained SPF error.
Troubleshooting and recovery
| Symptom | Investigate before making another change |
|---|---|
| Verify cannot find the record | Check authoritative provider, delegated zone, doubled domain suffix, record type and complete issued value |
| Verify succeeds but DKIM is absent | Confirm the Site Email domain, site and notification route; ask support whether the custom signing configuration is active |
| DKIM passes only for a Blackbaud domain | Confirm custom DKIM rather than default signing; compare d= against the institution's From domain |
| DKIM fails after a gateway or forwarding step | Compare an authorized direct delivery with the modified path; message modification can break a valid signature |
SPF reports permerror |
Check duplicate SPF records, syntax and nested lookup/void-query limits; do not add another include as a blind fix |
SPF reports temperror |
Investigate DNS timeouts, SERVFAIL and dependency availability before rewriting policy |
| SPF fails or is missing | Confirm the actual envelope owner and authorized sending IP; a root-domain edit may be irrelevant |
| Campus delivery fails while an external test passes | Give campus mail administrators the redacted headers and SMTP outcome; do not lower DMARC or broadly allowlist all Blackbaud mail |
Save the old DNS answers and application configuration before a change. During a confirmed regression, pause affected notification runs and coordinate a return to the last known working configuration with the Award Management and DNS owners. Do not delete new or old selectors while queued mail still depends on them. Retest after any sender-domain change, DNS migration or provider-directed rotation.
For escalation, supply the site, workflow, intended From domain, issued public-record set, authoritative answers, Verify result and redacted trusted receiver headers. No private keys or applicant data are needed.
Documentation review and testing boundary
The Award Management setup and knowledgebase bodies were inspected. The accessible product-specific SPF reference is a retained Blackbaud help page; the current Email Resource Center SPF URL could not be opened directly during this review. Verify current route applicability through Blackbaud before an SPF edit. No customer account was accessed, DNS changed, notification sent or live delivery tested. The acceptance steps above are for the administrator implementing the configuration, not a claim that it is already verified.