How to set up DMARC/DKIM/SPF for Blackbaud
Updated on 27 Oct 2026: We updated the Blackbaud setup steps for product-specific workflows, existing DKIM keys, and safer DMARC policy choices.
Blackbaud DMARC setup depends on DKIM that matches the visible From domain. Blackbaud normally authenticates SPF on a Blackbaud-owned Return-Path, so SPF can pass without matching your From domain and therefore does not satisfy DMARC for that message.
Set it up by claiming each sending domain in Blackbaud, publishing the DNS TXT values Blackbaud provides, and confirming domain ownership plus DKIM and DMARC. If the domain is new to DMARC, start at p=none, then consider enforcement after Blackbaud DKIM and every other legitimate sender pass consistently.
Blackbaud authentication priority
- Blackbaud mail needs a passing DKIM signature that matches the From domain for DMARC to pass reliably.
- Blackbaud manages SPF for its Return-Path in most products. Add an SPF value only when your Blackbaud product or tenant gives that exact instruction.
- Start with monitoring on a new deployment, confirm every legitimate source, then assess the appropriate policy for the domain.
Meet Blackbaud's current authentication requirement
Since July 1, 2026, Blackbaud has enforced DKIM and DMARC authentication for sending domains. If a domain is not fully configured, Blackbaud excludes its messages before they enter the outgoing mail stream, so recipients do not receive them and no delivery bounce is generated.
Check the portal before sending
- Add each domain and subdomain used by marketing messages, receipts, or automated Blackbaud mail.
- Domain ownership, DKIM, and DMARC must each show Verified.
- Do not schedule production mail until the sending domain shows Ready in Email Authentication Settings.
- A Ready status confirms Blackbaud's checks, while a received test message confirms the production stream signs correctly.
Check your Blackbaud product's setup path
The self-service steps below describe Blackbaud Email Services. Blackbaud's DKIM article identifies product-specific exceptions, so confirm the sending product before copying DNS records.
|
|
|---|---|
Blackbaud Email Services | Use Admin, Settings, Email to claim the From domain and configure the records shown in Email Authentication Settings. |
Blackbaud Award Management and Stewardship Management | Use Site, Settings, Content, then Email Settings, DMARC DNS Setup. Enter the Site Email domain, select Create Domain, publish the generated records, and return to select Verify. |
Luminate Online autoresponders, Tell-A-Friend, and Participant Center email | Only one DKIM domain can be configured per Luminate site for these messages. Multiple domains and wildcard DKIM domains are not supported. |
Blackbaud authentication setup paths
For the Award Management and Stewardship Management workflow, configure your organization's DMARC policy before completing Blackbaud's product-specific setup. Use the records generated by that product rather than substituting the Email Services example below.
Add your domain
Add the exact domain or subdomain that appears after the @ sign in Blackbaud's visible From address. If donors receive mail from gifts.example.org, authenticate gifts.example.org, not only example.org. Repeat the process for every sending domain used across your Blackbaud products.
Use a domain your organization controls and arrange access to its authoritative DNS host. A consumer email address such as @gmail.com cannot be authenticated by your organization for Blackbaud sending. Previously configured DKIM and an SSO domain claim do not replace the email domain claim.
Blackbaud sender authentication screen with a pending sending domain.
- Sign in to app.Blackbaud.com, then select Admin, Settings, and Email. You need Organization admin access or the Manage email authentication permission.
- In Email Authentication Settings, select Add domain, enter the exact From domain, and save it. Claiming a domain for SSO does not claim it for email.
- Open the domain details and copy each DNS TXT hostname and value Blackbaud shows for domain ownership, DKIM, and DMARC. Reuse a valid existing DMARC record rather than creating a second policy at the same hostname.
- Add the records at the authoritative DNS host. If its editor appends example.org automatically, enter sm._domainkey.gifts for sm._domainkey.gifts.example.org. Blackbaud checks public DNS automatically; most changes appear within minutes, but allow up to 72 hours.
- Wait until domain ownership, DKIM, and DMARC show Verified and the overall domain status shows Ready, then send a real Blackbaud test message.
|
|
|
|---|---|---|
From domain | Exact domain claimed | Email settings |
Required checks | All Verified | Domain details |
Overall status | Ready | Blackbaud portal |
Blackbaud domain setup checklist
Use Blackbaud tenant values
Blackbaud record names and values can vary by product, tenant, or an earlier setup. Use only the values shown in Email Authentication Settings or supplied for that Blackbaud product.
Set up SPF
For most Blackbaud products, no customer-side SPF change is required. Blackbaud uses a Blackbaud-owned Return-Path and maintains the SPF policy for that domain. SPF can pass there, but the different domain means it does not satisfy DMARC for your visible From domain.
- Confirm which domain appears in the message Return-Path. If Blackbaud owns it, Blackbaud also owns its SPF record.
- Do not add a Blackbaud include to your domain's SPF policy unless your product-specific instructions or tenant provide that exact value.
- Some Blackbaud product workflows and customer-controlled Return-Path domains require their own SPF value. Follow only the instructions for that sending source.
- Publish one SPF policy at each hostname. Merge any required include into the existing policy before its final all mechanism, and keep DNS-causing SPF terms, including nested includes, within the 10-lookup limit.
What SPF can prove
- SPF can pass for the Blackbaud-owned envelope domain.
- SPF can show that the connecting Blackbaud IP is allowed by that envelope domain.
What SPF cannot prove
- SPF does not satisfy DMARC unless the Return-Path domain matches the visible From domain under the domain's DMARC mode.
- The usual Blackbaud Return-Path does not provide that match, so DKIM must provide the passing DMARC result.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
SPF action for Blackbaud
If Blackbaud uses its own Return-Path and does not show an SPF value for your domain, make no SPF change for this source and focus on DKIM. Keep your domain's SPF policy accurate for other systems that use a Return-Path you control.
Set up DKIM
Blackbaud requires DKIM for every sending domain and subdomain. Blackbaud's DKIM article covers outgoing signatures. In the current self-service flow, publish the DNS TXT host and full public-key value exactly as Email Authentication Settings shows them. Use your account's record type and values rather than copying the screenshot.
Blackbaud DKIM setup screen with DNS record hostnames and verification status.
- In Email Authentication Settings, select the edit icon for the claimed sending domain and expand DKIM.
- Copy the full DNS host. Blackbaud Email Services uses the sm selector, producing a hostname such as sm._domainkey.gifts.example.org; the portal value controls.
- Create the TXT record with the complete DKIM public key Blackbaud provides. Paste the value without adding literal quotation marks; let your DNS host handle any required quoting or splitting of the long value.
- Wait for Blackbaud to detect public DNS, then confirm DKIM shows Verified and the domain shows Ready.
- Send a Blackbaud test message and confirm the passing DKIM d= domain matches the visible From domain under your DMARC mode.
DKIM TXT example for gifts.example.orgdns
type: TXT host: sm._domainkey.gifts.example.org value: copy the full public key shown in Blackbaud
If an existing sm._domainkey record matches the portal value, leave it in place. If it differs, contact Blackbaud Support before replacing it. Do not publish a second public key at the same selector hostname. DKIM records for other senders can coexist at different selectors.
With default relaxed DKIM matching (adkim=r), d=example.org can match a From address at gifts.example.org because they share an organizational domain. With strict matching (adkim=s), the DKIM d= domain must be exactly gifts.example.org for that From address.
Good DKIM result
- The received message has a passing Blackbaud DKIM signature.
- The DKIM signing domain matches the visible From domain as DMARC requires.
- Footers, link wrapping, or downstream routing do not alter signed content and break the signature.
Set up DMARC
Every domain and subdomain used to send Blackbaud mail needs DMARC. Publish an explicit record for each sending domain to match Blackbaud's setup requirements. Blackbaud's DMARC guidance explains the policy, and Suped's DMARC generator can create a starting record.
- Look for one DMARC TXT record at _dmarc on the exact Blackbaud From domain. A parent policy can apply to a subdomain at receiving servers, but confirm the exact sending domain's record also satisfies Blackbaud's verification.
- If the domain already uses quarantine or reject, keep that policy and configure Blackbaud DKIM within it.
- If no DMARC policy applies, start with the p=none example below. If an enforced parent policy applies, preserve the intended protection when adding an explicit subdomain record.
- Replace the rua mailbox with an address that can process aggregate reports. Confirm reports arrive; a reporting destination outside your organizational domain also needs the reporting provider's DNS authorization.
- Use aggregate reports to confirm Blackbaud volume, DKIM pass rates, source IPs, and failed messages before enforcing policy.
- Confirm DMARC shows Verified and the claimed domain shows Ready in Email Authentication Settings.
Starting DMARC TXT example for gifts.example.orgdns
type: TXT host: _dmarc.gifts.example.org value: v=DMARC1; p=none; rua=mailto:dmarc@example.org
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Do not weaken an enforced domain
If the domain already uses p=quarantine or p=reject, do not change it back to p=none just to add Blackbaud. Fix DKIM first, then watch the reports.
Do not stage policy with pct
RFC 9989 treats the pct tag as historic because receivers did not apply percentage sampling consistently. Where enforcement is appropriate, stage it by moving one verified sending domain or subdomain at a time, using a complete p=quarantine policy before considering p=reject.
Verify Blackbaud email and troubleshoot failures
Verification needs a real Blackbaud email from every production sending domain and each product stream that uses it. DNS and a Ready status prove that Blackbaud found the records, but only a received message proves that the intended stream carries a passing DKIM signature.
Blackbaud test email screen with authentication status.
- Send a Blackbaud test message from the final From address, then test each production workflow, including receipts or automated messages.
- Check the receiving server's Authentication-Results for dkim=pass and dmarc=pass. Compare the passing DKIM d= domain with the visible From domain under your DMARC mode, and use the s= selector to locate its DNS record.
- A Blackbaud-owned Return-Path can produce spf=pass without satisfying DMARC. Passing DKIM for the From domain still produces a DMARC pass.
- If DKIM fails, check for copied quotes, a doubled domain suffix, a truncated public key, or the wrong record type.
- Blackbaud stops automatic verification after two weeks if setup is abandoned. For Expired status, reconfirm ownership and records, then restart the check in Email Authentication Settings; the status alone does not prove signing stopped.
- Allow up to 72 hours for DNS publication, then send another Blackbaud message and read the new headers.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Common Blackbaud failures
- The domain claimed in Blackbaud does not match the visible From domain.
- The DNS host was edited during entry and no longer matches the Blackbaud value.
- The team expects Blackbaud SPF to satisfy DMARC even though the Return-Path uses a different domain.
- The domain shows Ready, but no production message was checked for a passing DKIM signature.
- The domain moves to reject before Blackbaud DKIM is confirmed across normal mail volume.
If Blackbaud excludes mail before sending, no receiving-server headers or DMARC report will exist for those messages. Check the product's sending status and authentication settings first. A DMARC pass also does not guarantee inbox delivery; receiving servers apply their own spam filtering.
Monitor Blackbaud authentication failures
Blackbaud authentication can break when a sender changes the From domain, a DNS record is removed, a DKIM key changes, or a product setting changes. Suped's DMARC monitoring product groups aggregate reports by sending source and flags authentication failures, so teams can investigate a Blackbaud stream before tightening policy. Reports arrive after delivery activity, typically daily, so these alerts depend on the reports received.
- Review Blackbaud DKIM pass rates when they drop or a new unsigned stream appears.
- Separate verified Blackbaud traffic from unknown senders using IPs, hostnames, and report patterns.
- Track domain and IP blocklist (blacklist) status alongside authentication results when investigating delivery failures.
- Use Suped's issue details to identify the affected domain and share the required DNS or Blackbaud settings change with its owner.
Blackbaud authentication triage
Use these review states rather than a universal pass-rate threshold. Investigate every legitimate failing stream, even when its volume is small.
Healthy
Expected mail passing
Expected Blackbaud streams have passing DKIM and DMARC results in received reports.
Review
Unexplained failures
Investigate a new source or an unexplained authentication failure before tightening policy.
Fix now
Legitimate mail failing
Resolve confirmed DKIM or DMARC failures affecting legitimate Blackbaud mail.
Choose the right DMARC enforcement policy
Consider p=reject for a dedicated Blackbaud sending domain only after Blackbaud DKIM passes, every other legitimate sender is known, and aggregate reports show no unexplained production traffic. Suped's Hosted DMARC helps teams stage complete policy changes by domain without repeated manual DNS edits after the initial setup.
RFC 9989 advises against p=reject for domains used for general correspondence because mailing lists and other indirect delivery paths can break authentication. Assess those uses before changing the policy, and consider a dedicated sending subdomain for Blackbaud. A quarantine policy still requires delivery testing.
- Collect enough aggregate reports to cover normal Blackbaud mail and infrequent legitimate streams, such as scheduled fundraising campaigns.
- Do not tighten policy until Blackbaud DKIM passes for each final From domain and every other legitimate source has been checked.
- For a domain suited to enforcement, move one verified sending domain or subdomain to a complete quarantine policy. Do not use pct for partial enforcement.
- Investigate legitimate sources that fail DMARC because neither DKIM nor SPF passes with the required domain match. Include forwarding and mailing-list paths in delivery tests.
- Consider reject only when the domain's use supports it and testing shows the delivery impact is acceptable. Receiving servers retain the final delivery decision.
Alternative DMARC policy values, publish only onedns
v=DMARC1; p=none; rua=mailto:dmarc@example.org v=DMARC1; p=quarantine; rua=mailto:dmarc@example.org v=DMARC1; p=reject; rua=mailto:dmarc@example.org
How Suped supports this rollout
- Hosted DMARC lets teams adjust policies by domain after the initial DNS setup.
- Review Blackbaud source reports alongside SPF and DKIM results; use blocklist monitoring (blacklist monitoring) when investigating reputation-related delivery problems.
- Suped's issue details give practical steps for each source that fails.
- The multi-tenant dashboard supports agencies and teams responsible for many domains.
FAQ
Usually no. Blackbaud manages SPF for its Blackbaud-owned Return-Path in most products, so you do not add Blackbaud to your domain's SPF policy. Use the exact SPF value only when a product-specific Blackbaud workflow or a Return-Path you control requires it. DKIM must match the visible From domain for the usual Blackbaud DMARC pass.
SPF can pass for Blackbaud's Return-Path domain while the visible From address uses your domain. DMARC counts only a passing mechanism whose authenticated domain matches the From domain, so DKIM provides the passing result in the usual Blackbaud setup.
Investigate Blackbaud when aggregate reports show reverse DNS tied to its mail infrastructure. Confirm the source using the sending IP, a known Blackbaud campaign or receipt, and the received message's authentication results. A reverse DNS hostname alone is not proof that traffic is authorized.
DKIM verification alone is insufficient. Confirm real Blackbaud traffic and every other legitimate sender in aggregate reports, then test delivery paths. For a dedicated sending domain suited to enforcement, test quarantine before considering reject. RFC 9989 advises against reject for general correspondence domains because indirect delivery can break authentication.
Check that the tested message uses the same From domain you claimed. Then inspect Authentication-Results, the DKIM d= domain, and the selector in the received message headers. A product stream using another domain needs its own claim and records. If DKIM and DMARC pass, investigate the product's sending status and the recipient's filtering.
Expired indicates that Blackbaud's DNS verification window ended; it does not by itself prove DKIM stopped working. For an abandoned setup, automatic checking stops after two weeks. Reconfirm domain ownership and the displayed DNS values, then restart verification in Email Authentication Settings. An existing DKIM key that differs from the portal value needs Blackbaud Support review before replacement.
