Bloomerang SPF, DKIM and DMARC setup, step by step

Bloomerang CRM custom-domain authentication requires the documented SendGrid SPF authorization and the account-specific DKIM CNAME records supplied by Bloomerang Support. Publish those records with your DNS host, ask Support to verify them in SendGrid, select the custom From address in CRM, and inspect a fresh CRM-delivered message. Adding a generic SendGrid record or testing your ordinary mailbox alone does not complete the setup. Bloomerang's SPF and DKIM procedure.

This guide applies to email sent natively from Bloomerang CRM templates using an organization-owned domain. It does not establish the configuration for Bloomerang Fundraising, Volunteer, legacy products, an external Mailchimp integration or your own standalone SendGrid account. No authenticated account, customer DNS or delivered-message testing was performed.

Identify the CRM sender and preserve existing mail

Start with the actual From address you intend supporters to see, such as giving@example.org. Confirm who owns the domain, controls its authoritative DNS, manages the CRM sender settings and can work with Bloomerang Support. The public setup guide does not establish a universal subscription tier or a named CRM permission for this task; if your controls are unavailable, ask your administrator or Support rather than assuming a plan upgrade is required.

Keep three routes separate:

Bloomerang's procedure includes tests of both CRM and ordinary-mailbox/BCC behavior. Record existing DNS and sender dependencies first so adding CRM does not break everyday correspondence. Official setup and testing sequence.

A public mailbox address such as @gmail.com is a different case: you cannot edit that provider's DNS. Bloomerang documents rewriting personal-provider senders and some unauthenticated custom-domain senders to a platform domain. Do not attempt to publish records for a domain you do not own. Custom sender-address guidance.

Add Bloomerang's SPF authorization safely

Bloomerang's current CRM guide specifies this mechanism:

include:sendgrid.net

Add it to the single SPF TXT policy at the domain Bloomerang instructs you to configure. For giving@example.org, that is the organization domain example.org. Confirm separate subdomain senders with Support instead of assuming the parent SPF record covers them. A DNS editor may use @ for the root of its selected zone, but that symbol does not identify your organization's root everywhere. Bloomerang SPF instructions.

If there is no SPF policy and SendGrid is the only authorized sender at this owner, Bloomerang's documented starting example is:

v=spf1 include:sendgrid.net ~all

Do not use that short example to replace a working policy containing other services. Instead:

1. Retrieve the current TXT records and identify the existing v=spf1 policy.
2. Preserve every still-authorized sender and the intended terminal qualifier.
3. Add include:sendgrid.net once, before the terminal all mechanism.
4. If the policy uses redirect=, have its maintainer evaluate the combined logic rather than appending a second policy.
5. Publish one final SPF policy and check the full evaluation, including nested provider includes.

SPF is stored as TXT. Two separate v=spf1 records at one owner are not a safe merge. Other unrelated TXT records can coexist, and multiple character strings inside one TXT record are not automatically duplicate policies. RFC 7208, record publication.

The limit is ten lookup-causing terms across an SPF evaluation, not ten visible include strings. include, a, mx, exists, ptr and redirect can consume that budget, including nested processing; ip4, ip6 and all do not. Exceeding the limit causes permerror. Do not replace SendGrid's managed authorization with a manually frozen IP list to make a checker turn green. SPF lookup limits.

Why the include does not prove SPF alignment

SPF normally checks the SMTP envelope sender, reported as smtp.mailfrom and usually reflected in Return-Path. DMARC compares that authenticated domain with the visible From domain. Publishing an include on example.org does not itself make CRM use example.org as its envelope domain.

The reviewed Bloomerang procedure does not establish one universal emitted envelope domain or a self-service custom Return-Path workflow. Capture the actual CRM message identities. An SPF pass for an unrelated SendGrid-controlled domain can coexist with DMARC passing through branded DKIM. That is different from an SPF error, which still needs diagnosis. SPF identity; DMARC alignment.

Obtain account-specific DKIM records from Support

Contact Bloomerang Support through your established support channel and request the DKIM DNS records for the exact CRM account and From domain. The official procedure makes this a Support-assisted step, not a generic SendGrid dashboard task. Bloomerang DKIM procedure.

Ask for a complete list of:

• Each record's type, fully qualified owner and target.
• The sender domain/account it authenticates.
• Any existing selector conflicts or additional records required for that configuration.
• The verification step Support will perform after publication.

The public guide specifies CNAME and illustrates a selector under _domainkey. It does not establish a universal record count, selector or target for all CRM accounts. Publish every record actually supplied. Do not reconstruct a target from an account number, reuse another organization's records, or copy the illustrative hostname from the article. An example is not your issued configuration.

If your DNS already has the same selector owner for another SendGrid-based service, stop and ask Support for a nonconflicting arrangement. Two applications sharing an infrastructure provider do not necessarily share the same account key or domain-authentication configuration.

Publish CNAMEs without changing the whole zone

Consider an illustrative owner s1._domainkey.mail.example.org. This is an owner-format example, not a required Bloomerang selector.

Confirm the actual zone delegation and your DNS host's input convention. Preserve legitimate child-zone or _domainkey NS delegation and publish within the authoritative delegated zone; do not delete a working delegation to place a record in its parent. The CNAME target must remain the complete exact value from Support. Avoid doubled domain suffixes or accidentally making an absolute target relative.

At a CNAME owner, do not add a DKIM TXT record alongside the alias or overwrite existing A, AAAA, TXT or other conflicting data. A CNAME directs lookups to its target; it is not the public key itself. Keep unrelated selectors and mail records untouched. DNS alias rules.

If using a DNS service with proxying, publish these authentication aliases as DNS-only where applicable. Keep the authentication record's Flatten option off where that per-record control exists, and ensure any zone-wide flatten all CNAMEs setting does not suppress these aliases. A zone-wide setting can override the per-record control, so verify the literal public CNAME answer rather than relying only on the displayed toggle. Bloomerang's validator needs the issued alias to be visible as required, not a substituted address record. Cloudflare documents that all-CNAME flattening can interfere with third-party verification. Cloudflare flattening controls.

Do not turn off unrelated DNS security controls, change nameservers or alter flattening for every website in a shared zone just to fix one selector. If a narrow exception is unavailable, involve the DNS owner and Bloomerang Support before choosing an alternative. Keep this authentication work separate from inbound MX routing: the documented DKIM step does not call for moving your organization's mailbox service.

Complete Support verification and choose the CRM From address

After the records are public, notify Bloomerang Support so it can verify the configuration in SendGrid. A DNS dashboard saying “saved” is not the same as this provider-side verification. Obtain confirmation for the intended CRM account and domain. Required Support verification.

Configure the custom sender address in the organization's settings, then use it in the CRM email's From Email field. Recheck templates rather than assuming every existing message inherited the address. These are the documented places the current sender-address guide identifies; it does not supply a universal deeper settings-menu path. Choosing the custom sender.

If From changes to mailman.bloomerang-mail.com

Bloomerang documents this rewriting for mass email when SPF has not been configured and for personal email-service addresses. Its rewriting explanation says the original From address is used as Reply-To. A reply reaching your normal mailbox therefore does not prove the visible brand domain was authenticated. Bloomerang's rewriting explanation.

Inspect the delivered From, not only the template setting. If a correctly configured owned-domain sender is still rewritten, provide Support with the actual recipient route and headers. The help center also mentions recipient-specific rewriting behavior. Do not promise that one SPF change prevents every possible rewrite, or try to fix a platform decision by changing your domain's A record or disabling DMARC.

Keep DMARC policy and reporting under organizational control

Look up the policy for the intended From domain and its applicable inheritance before adding anything. Retain existing enforcement, strict-alignment decisions, subdomain policy and approved reporting destinations. Bloomerang's DMARC page gives quarantine/reject examples, but elapsed time after DNS publication is not evidence that all of your organization's senders are ready for enforcement. Bloomerang DMARC page.

Only where no direct or inherited DMARC policy applies, an owner-approved initial observation policy for example.org can be a TXT record at _dmarc.example.org:

v=DMARC1; p=none

This example does not request reports and does not guarantee delivery. Add an approved rua destination only after establishing who processes the data, access and retention. External aggregate-report destinations outside the applicable organizational domain need receiving-domain authorization. Do not copy a vendor's example reporting mailbox or enable detailed failure reports without a privacy review. DMARC policy; external report authorization.

DMARC passes through at least one successful aligned SPF or DKIM result. For this branded-DKIM setup, require the intended Bloomerang signature to pass and align as well as DMARC to pass. Exact matching is required under strict alignment; relaxed alignment follows the applicable organizational-domain relationship. Do not weaken adkim or aspf simply because another configuration would be easier.

Validate public DNS and a real CRM message

Use the exact owners supplied for your account. These example commands illustrate inspection only:

dig +short TXT example.org
dig +short CNAME s1._domainkey.example.org
dig +short TXT s1._domainkey.example.org
dig +short TXT _dmarc.example.org

Check each supplied alias at the authoritative nameservers and a recursive resolver. Confirm that the CNAME target is exact and its DKIM key resolves. A TXT lookup through an alias can show the final key; it does not replace checking the literal CNAME. If results differ, compare TTLs, negative caching and the actual delegation before editing correct records again.

Bloomerang's guide advises allowing 24 hours after SPF changes before its test sequence. Treat that as an operational allowance, not proof that a record is right. Once DNS and Support verification are complete, open a representative CRM template, choose Send Test, enter a controlled test mailbox and send. The official sequence names these controls. Also verify a representative real CRM send to an approved internal test audience when validating the production route. CRM test procedure.

Use harmless content. A public deliverability tester receives the test message and its headers; do not send donor details or sensitive fundraising content there merely to obtain a score.

Acceptance checklist

Read original headers or a receiving-server trace from infrastructure you control or trust. The receiver must establish which Authentication-Results it generated and remove or distinguish untrusted incoming fields. Attackers can insert fields and copy a plausible authserv-id; the name alone is not a trust check. If your receiver cannot establish provenance, use another trusted mailbox or trace. Authentication-Results trust boundary.

Confirm all of these:

• The delivered From is the intended owned-domain sender, or a documented exception is separately identified.
• The intended Bloomerang CRM DKIM signature has the expected signing domain and selector, reports dkim=pass, and aligns with the visible From.
• The trusted receiver reports dmarc=pass for that From. Another signature or SPF alone must not mask a broken configured DKIM signature.
• The actual envelope domain, SPF result and SPF alignment are recorded separately.
• Existing ordinary-mailbox sending still works. If you use BCC to Bloomerang, separately check that its CRM interaction appears as expected.

EmailAuth's raw DKIM versus aligned DKIM guide explains why a provider-domain signature can pass without proving your branded setup. Retest after From-domain changes, key rotation, DNS moves or changes to the sending integration.

Troubleshooting Bloomerang CRM authentication