Virtuous SPF, DKIM & DMARC Setup: Step-by-Step Guide

For Virtuous Raise, add your sending domain under Settings > Email Settings > Domain Authentication, publish the records generated for that domain, verify every required check, and then update the From address on the General tab. Keep automatic security enabled for the CNAME-based route described here. Domain verification alone does not update the sender address. Official Raise setup instructions.

This guide covers Virtuous Raise, documented in the RaiseDonors help center, for donation receipts, acknowledgments and notifications. It is not a guide to Virtuous CRM's separate Email Sender Identity settings, a generic SendGrid account or donation-page website branding.

Before you start

You need Account Settings permission set to View & Edit in Raise, plus authorized access to the domain's DNS. Decide which organizational address donors should see, and which monitored mailbox should receive replies. The domain belongs in the sender configuration; a donation-page URL does not belong there.

Confirm you are configuring Raise, not another Virtuous product. The official article describes SendGrid-powered authentication within Raise's own interface. That does not mean you should create an unrelated SendGrid account, generate API credentials or follow a separate CRM tutorial. The reviewed instructions do not establish a universal plan or region entitlement. Resolve missing controls with the account administrator before proceeding.

Record current DNS dependencies, including other email senders and existing DMARC protection. Select an unused routing owner if you intend to supply one. An occupied mail hostname can have important MX, A or other dependencies; do not displace them to match a tutorial example.

Generate the Raise authentication records

Open Settings > Email Settings > Domain Authentication and choose Add Domain.
Enter the root domain intended for the visible From address, without https:// or a subdomain prefix, as specified by Raise's documented form. If your requirement is a subdomain From address, obtain product-specific confirmation rather than assuming this root-domain form supports it.
The optional Subdomain field is a DNS routing label, not the donor-visible From domain. Use an unused label or leave it blank for automatic assignment.
Leave Custom DKIM Selector blank unless there is a specific coordinated requirement. A custom selector must not collide with another sender's records.
Keep Enable automatic security on. Select Add Domain and retain the resulting DNS Records panel for this exact domain.

These are Raise's documented domain creation controls. Turning automatic security off produces a different MX/TXT route, outside this guide. Do not use that switch as a workaround for a CNAME conflict: it changes the DNS configuration and requires separate route assessment.

Interpret the record panel correctly

Copy the Type, Host and Value for every required issued row. The official example shows a routing CNAME and two DKIM CNAMEs; its text says the displayed set can vary and may include an SPF check or record. Your current account packet governs, not a fixed count or the example's tenant values. Do not add a fourth record simply because a generic list mentions SPF.

There is a practical inconsistency in the official material: its prose says Host values are relative, but its DNS-record screenshot shows fully qualified names. Therefore, inspect the actual copied value and your DNS zone rather than blindly assuming either format. A Host ending in your complete zone name already contains that suffix. An editor that appends the zone must not append it twice. The goal is the exact issued full DNS owner, regardless of the editor's preferred input format.

The Cloudflare screenshot is a general proxy-status illustration using A records, not the issued DKIM packet. It does not tell you to replace authentication CNAMEs with A records. Use the account-issued types and destinations and the DNS-host rules below. Official instructions and embedded examples.

Publish DNS without breaking other services

Use the authoritative DNS zone, not necessarily the company that sold your domain. Save the current records before approved changes. Copy each issued record's type, full owner and destination exactly. These are public DNS values; you should never need to publish a DKIM private key.

Check what your DNS editor appends. For the illustrative full owner selector._domainkey.example.org, an editor for the example.org zone may require only selector._domainkey. In a separately delegated _domainkey.example.org zone, the relative name is selector. These are owner-format examples, not provider selectors or records to publish. A child-zone delegation changes where records must be entered; preserve NS delegations and coordinate with their owner rather than deleting them.

An issued CNAME owner cannot also contain TXT, A, AAAA, MX or another CNAME. If an owner is occupied, investigate dependencies and request a supported alternative where possible; do not overwrite another sender's record. A CNAME destination is a hostname, not a URL, and its trailing-dot treatment depends on the DNS editor. Check the resulting public owner and target instead of trusting the input form alone.

For Cloudflare, authentication aliases should be DNS only, not HTTP-proxied. Where literal CNAME answers are required, turn the applicable per-record Flatten option off when available and ensure whole-zone flattening does not conceal those aliases. Do not disable a global setting without assessing other records and obtaining authorization. Apex flattening is automatic; same-zone targets can be flattened regardless of that setting. If mandatory behavior prevents the required alias answer, stop and coordinate a supported configuration rather than inventing a switch or moving a selector. See Cloudflare proxy status and CNAME flattening controls.

Verify the domain and activate From

Return to Raise and select the domain's three-dot menu, then Verify. Inspect each individual result rather than accepting one successful row. Correct failed owners, types or targets and use Re-verify. Raise documents up to 48 hours for DNS propagation. All required checks must pass before the domain becomes Verified with a green badge; Pending is not readiness.

Once verified, open Email Settings > General and set From to the intended address at the verified domain. Raise prevents saving a From domain that does not match a verified domain. Set the optional Reply To deliberately; when blank, donor replies go to From. Reply To is not the identity that DMARC authenticates, and changing it does not fix signing alignment.

Do not remove an authenticated domain casually. Raise limits how many domains can be added, but the published instructions do not give a universal numeric quota. Removing the domain used by the current From resets that address to the system default. Plan a replacement, preserve dependent records and test the new route before approved retirement. Verification, sender activation and removal behavior.

Understand SPF and preserve DMARC

SPF evaluates the SMTP envelope sender, commonly reported as smtp.mailfrom, not automatically the visible From address. A custom routing subdomain and a visible sender domain are different identities. Do not add an apex SPF include merely because the service uses a particular delivery backend. Use only the actual account-issued configuration and investigate the received message's evaluated identity.

If an authorized setup requires an SPF TXT policy, keep one v=spf1 policy at that exact owner, preserving legitimate existing authorizations and qualifiers. The SPF limit is ten evaluated DNS-dependent terms, including nested mechanisms, not simply ten includes. A redirect is ignored when an all mechanism is present. Do not blindly merge or replace a policy, and do not treat a qualifier as a guarantee of delivery or rejection. SPF specification.

DMARC passes when either SPF or DKIM passes and aligns with the visible From. Relaxed alignment uses an Organizational Domain match; strict alignment requires an exact domain match. A child envelope domain may align in relaxed mode but not strict mode. A passing provider-domain signature that does not align is not enough. For the new branded DKIM route, require the intended provider signature to pass and align, even if SPF could independently yield a DMARC pass. Read DKIM alignment and the visible From domain and the current DMARC specification.

Preserve existing direct and applicable inherited DMARC policies and approved reporting destinations. Authentication setup is not permission to downgrade quarantine or reject to none. Only if no applicable policy exists, the owner approves, and a monitoring plan is in place, an initial TXT policy can be v=DMARC1; p=none at _dmarc beneath the actual From domain. For example.org, that full owner is _dmarc.example.org; for news.example.org, it is _dmarc.news.example.org. Enter names relative to the actual authoritative zone and publish only one policy at an owner. This minimal example sends no aggregate reports by itself.

Choose any report recipient deliberately. A destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination within the same Organizational Domain is excepted. DNS authorization does not replace the owner's privacy and data-sharing approval. Do not copy a tutorial's reporting address. See RFC 9990, section 4.

Prove the actual messages authenticate

Provider verification checks DNS configuration. It is not proof that every message stream uses the intended signing domain. After configuration, an authorized administrator should test the actual application route with a controlled, valid recipient. This guide did not perform customer sends or change DNS.

Save the recipient's original message and use authentication results produced inside the actual receiving service's processing boundary. Consult that service's documented handling of externally supplied Authentication-Results, or obtain a receiving administrator's trace. A familiar authserv-id string or header position alone is not proof of authenticity. Ignore injected or otherwise untrusted result fields. Authentication-Results specification.

Record the visible From, envelope sender, intended DKIM signature's signing domain and selector, and the trusted receiver's SPF, DKIM and DMARC results. Acceptance requires the intended provider DKIM signature to pass and align with the intended From under the active alignment policy, plus a trusted receiver DMARC pass. A generic DMARC pass via SPF alone does not prove DKIM works. A rewritten provider From is not proof of brand-domain authentication.

Investigate SPF fail, temperror and permerror separately, even when aligned DKIM makes DMARC pass. Temporary errors suggest a transient lookup problem; permanent errors indicate a configuration/evaluation problem; neither should be silently marked passed. Test materially different sending paths separately. Authentication does not guarantee inbox placement, indexing or search rankings.

For Raise specifically, test the donation-receipt or notification workflow you intend to use, not an email composed in your normal mailbox. Use an authorized test facility or controlled legitimate transaction path; do not create a paid donation solely to test without the necessary approval. Confirm the donor-visible From and replies as well as the authentication results. Test other materially different Raise notification streams separately.

Troubleshooting and FAQs

What SPF include should I add for Virtuous Raise?

Do not guess one. The documented automatic-security route generates account-specific DNS records. Use that packet and the actual envelope identity; do not copy the SPF policy of virtuous.org, raisedonors.com or another organization's domain into your apex.

Can I use these instructions for Virtuous CRM?

No. These steps describe Raise's Email Settings and Domain Authentication screens. A shared brand or sending backend does not establish the same issuance and activation workflow in CRM. Identify the actual product before making changes.

The domain is Verified but receipts still use the default sender

Check Email Settings > General. Verification and selecting From are separate steps. Also check whether a previously configured domain was removed, which can reset From. Test the actual receipt path after correcting the intended sender.

Why do one or more DNS checks fail?

Compare the complete public owner and target with the current panel. Common problems are duplicated suffixes, editing the wrong zone, an occupied routing label, an incorrect type, HTTP proxying or flattening that hides the required CNAME. Correct the cause before retrying; waiting 48 hours will not repair a misnamed record.

Should I disable automatic security if CNAMEs are difficult?

Not as a shortcut. The alternate mode produces MX/TXT records and needs its own supported routing assessment. First resolve owner conflicts and authoritative-zone placement with your DNS administrator. Do not change inbound mail routing just to clear a validation badge.

Why does DKIM pass but DMARC fail?

Compare the signing domain with the actual visible From under the active alignment mode. A pass for an unrelated domain does not supply alignment. Conversely, DMARC passing through SPF alone does not establish that Raise's intended DKIM setup works. Investigate using trusted receiver evidence, not just the presence of a signature header.

Can the routing label be the same as our existing mail host?

Only an unused owner fits this documented optional-label choice. Do not replace an existing mail host, website record or another sender's selector. Leave the field blank for system assignment or coordinate a different unused label.

Who should receive replies?

Use a monitored mailbox your organization authorizes. If Reply To is blank, Raise says replies go to From. DNS domain authentication does not create that mailbox or prove it is monitored; confirm reply handling separately.

Sources and review limits

Primary product source: RaiseDonors by Virtuous: How Do I Set Up a Custom Email Sending Domain?. The textual workflow and relevant record/proxy illustrations were inspected. Example tenant DNS values were not reused.

This is documentary guidance, not hands-on account certification. No customer account was accessed, no DNS records or sender settings were changed, and no donations, sends or received-header tests were performed. Live CMS rendering, publication and search performance remain untested.

Virtuous SPF, DKIM and DMARC setup, step by step

On this page