Email authentication for nonprofits

2 May 2026 · 14 min read

Nonprofits run on trust and on email. The donation receipt, the year-end appeal, the gift-aid confirmation, the volunteer rota, the grant report to a funder, the emergency match-campaign that has to land in the inbox within the hour: all of it moves through mailboxes, and most of it asks the reader to do something that involves money or personal data. That combination, a trusted brand plus a clear financial call to action, is exactly what makes a charity's From address one of the more profitable identities for an attacker to forge. It is also why a charity that does not authenticate its domain quietly loses fundraising revenue every month to the spam folder, without ever seeing the messages that never arrived.

This article is specifically about email authentication for nonprofits and charities. It is not a generic DMARC explainer. It covers why donor trust and deliverability are two sides of the same control, how the sender sprawl typical of a charity (a CRM, a fundraising platform, a mass-mail tool, a payment processor, plus staff mail) breaks DMARC alignment in ways that quietly suppress appeals, what the Gmail and Yahoo bulk-sender rules mean for an organisation that sends one big newsletter a month rather than daily marketing, and how BIMI can put your logo next to every message including, crucially via a Common Mark Certificate, for charities whose logo is not a registered trademark. If you want the underlying mechanics first, what is DMARC, what is SPF and what is DKIM are the companion pieces, and the glossary defines every term used below.

Why this matters more for a charity than for most businesses

Every organisation should authenticate its email. For a nonprofit the stakes are sharper for three concrete reasons.

The first is donor trust as an operating asset. A charity's entire relationship with its supporters is built on the belief that a message from appeals@yourcharity.org really is from you and that the link really does lead to your donation page. The moment a supporter is burned by a convincing fake, that trust does not just dent for one email, it dents for the brand. People who have been phished using a charity's name become harder to reach, slower to click, quicker to unsubscribe, and more likely to report your legitimate mail as suspicious. Spoofing damages the asset that fundraising depends on.

The second is margin. Commercial senders can often absorb a percentage of mail going to spam because their unit economics carry it. A small charity running a year-end appeal cannot. If even ten per cent of an appeal lands in spam, that is ten per cent of the most time-sensitive revenue of the year silently gone, on a budget that has no slack. Deliverability is not a vanity metric for a nonprofit, it is income.

The third is target attractiveness. Attackers know charities tend to run lean IT, lean security and a long list of third-party tools, and that the brand carries a halo of trust that makes recipients drop their guard. Disaster-relief and high-profile causes attract spoofing campaigns within hours of a news event, because a fake "emergency appeal" from a recognised charity is one of the highest-converting phishing lures there is. Your supporters are the victims, and your name is the weapon.

Email authentication, meaning SPF, DKIM and DMARC working together, is the control that addresses all three. It stops other people sending mail that claims to be from your domain, and it is also the single biggest lever you have over whether your own legitimate mail reaches the inbox. Those two outcomes come from the same records, which is why a charity gets both protection and deliverability from one project. You can see exactly where your domain stands right now with the DMARC checker, the SPF checker and the DKIM checker, or run all of it in one pass from the tools page.

The two failures that quietly cost charities money

Both of a charity's email problems trace back to the same gap: no enforced DMARC policy that the receiving mailbox provider can act on.

Failure one is impersonation reaching the inbox. Without a DMARC policy at enforcement, you have given receiving servers no instruction about what to do with mail that forges your domain. So a message from a forged appeals@yourcharity.org, pointing a donor at a cloned donation page, frequently lands looking entirely legitimate. The donor's card details, or the donation itself, go to the attacker. We walk through the mechanics in email spoofing explained, and the money mechanics in invoice fraud and the spoofed look-alike domain, which applies just as much to a charity paying a supplier as to any business.

Failure two is your own mail being suppressed. This is the failure charities underestimate, because it is invisible. When a fundraising platform or a mass-mail tool sends on your behalf but the mail is not properly authenticated as you, receiving providers treat it as suspicious. It does not bounce. It goes to spam, or it gets throttled, or it is delivered but down-ranked. You see "delivered" in your platform's dashboard and assume all is well, while a chunk of your appeal sits in spam folders nobody opens. The cruel part is that the same DMARC project that blocks the impersonators is what tells Gmail and Yahoo that your fundraising platform is genuinely authorised to send as you, which lifts that legitimate mail back into the inbox.

This is the framing to take to a board or a trustee: DMARC is not only a security control, it is a deliverability investment with a measurable return in delivered appeals.

Alignment: why "SPF pass" is not enough for fundraising mail

The subtlety that catches charity IT and operations teams out is that SPF and DKIM passing is not the same as DMARC passing. DMARC requires alignment, meaning the domain that authenticated must match the domain a human reads in the visible From header.

This matters enormously for nonprofits because charities almost never send only from one place. A typical setup looks like this:

• Staff and trustee mail through Microsoft 365 or Google Workspace.
• A CRM or donor-management system that sends receipts and stewardship mail.
• A dedicated fundraising or campaign platform for appeals.
• A mass-email tool such as a newsletter service for supporter updates.
• A payment processor or giving platform that emails donation confirmations.

By default, several of those platforms sign mail with their own domain and use their own return-path. The result is that a donation receipt can show SPF pass and DKIM pass and still fail DMARC, because what passed authenticated the platform's domain, not yours. To the donor the message reads as coming from your charity, to DMARC it is unaligned, and so it is indistinguishable from a spoof and treated accordingly.

Two flavours of alignment exist:

• SPF alignment requires the envelope-sender domain (the return-path / MAIL FROM) to match your From domain. This is why configuring a custom return-path on your sending platform matters, and why it is one of the first things to fix.
• DKIM alignment requires the d= signing domain in the DKIM signature to match your From domain. This is usually achieved by publishing the platform's DKIM CNAME records on your own domain so it signs as you.

You only need one of the two to align and pass for DMARC to pass, but you want both wherever you can, because DKIM survives forwarding and SPF does not. Charity mail gets forwarded constantly: a supporter forwards your appeal to a friend, a trustee forwards a report to a committee, a grant officer forwards your update internally. We cover the distinction in SPF vs DKIM: which one aligns and the forwarding problem in forwarding and DMARC.

The practical task for a charity is therefore an inventory. Before you touch any policy, list every system that sends mail with your domain in the From line, and confirm that each one is set up to align. This is precisely what DMARC aggregate reports reveal, which is why monitoring comes before enforcement, not after.

The Gmail and Yahoo bulk-sender rules apply to appeals too

Since early 2024, Gmail and Yahoo have required bulk senders, defined as anyone sending more than 5,000 messages a day to their users, to authenticate with SPF and DKIM, publish a DMARC record (at least p=none), keep spam complaints low and honour one-click unsubscribe. A charity sending a single newsletter or appeal to a list of 20,000 supporters is a bulk sender on that day, even if it sends nothing for the rest of the month. Many charities have been caught out precisely because their volume is spiky: quiet for weeks, then a single large send that trips the threshold and gets throttled because the authentication was never in place.

The honest reading of those rules for a nonprofit is that the minimum bar is now a published DMARC record and aligned authentication, and the practical bar for reliable delivery to the largest mailbox providers is higher than the literal minimum. We cover the requirements in the Gmail and Yahoo sender requirements, and the full picture is set out on the requirements page. If your appeals go out through a platform, do not assume the platform handles all of this for you. Many handle SPF and DKIM signing with their own domain, which is exactly the unaligned state described above, leaving your DMARC failing while the platform's dashboard reports success.

The staged path to enforcement, without breaking an appeal

You do not start at p=reject. You arrive there. For a charity the rule is non-negotiable, because the cost of accidentally rejecting your own year-end appeal is measured in lost donations, not just an awkward apology. The path is the same staged rollout we recommend for everyone, and it is set out in detail in reach p=reject without breaking email and the enforcement journey guide.

The stages, in order:

1. Publish p=none with reporting. This changes nothing about delivery. It simply asks the world's mailbox providers to send you reports about mail claiming to be from your domain. This is monitoring, not enforcement, and it is the most important step because it shows you every sender, including the fundraising tool you forgot about and the intern's mail-merge script.
2. Read the reports and fix alignment. Work through every legitimate source the reports reveal: configure custom return-paths, publish DKIM CNAMEs for each platform, and tidy your SPF record. The goal is to reach a state where 100 per cent of your real fundraising and stewardship mail passes DMARC aligned. The DMARC report analyzer turns the raw XML into a readable picture of who is sending as you.
3. Move to p=quarantine, optionally with pct. Now you begin enforcing, sending failing mail to spam rather than rejecting it. You can ramp gradually with the pct tag so only a sample is affected at first, which limits the blast radius if a legitimate source was missed.
4. Move to p=reject. Once quarantine has run clean through at least one full sending cycle, including your biggest appeal of the period, failing mail is rejected outright. Forged mail from your domain now simply does not arrive.

A worked example. Suppose yourcharity.org sends staff mail through Microsoft 365, appeals through a fundraising platform, newsletters through a mass-mail tool, and receipts through a CRM. An SPF record that authorises every legitimate source and nothing else might read:

v=spf1 include:spf.protection.outlook.com include:_spf.fundraising-platform.com include:_spf.newsletter-tool.com include:_spf.your-crm.com -all

A DMARC record for the monitoring stage, with aggregate reports pointed at your inbox or analyser:

_dmarc.yourcharity.org  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourcharity.org; fo=1; adkim=s; aspf=s"

And the same record once you have reached full enforcement:

_dmarc.yourcharity.org  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourcharity.org; adkim=s; aspf=s; pct=100"

Note the sp=reject. Charities often have subdomains nobody is watching: an old events.yourcharity.org, a shop.yourcharity.org, a microsite from a campaign three years ago. A subdomain policy of reject closes the door on attackers spoofing a forgotten subdomain. The DMARC generator will assemble a syntactically correct record for whichever stage you are at, and the DMARC checker confirms what is actually published.

The SPF lookup limit is a common charity trap

There is one technical failure that hits charities disproportionately, because of how many third-party tools they accumulate. SPF allows a maximum of ten DNS lookups when a receiving server evaluates your record. Each include: for a platform can consume one or several of those lookups. A charity with Microsoft 365, a fundraising platform, a newsletter tool, a CRM, an events system and a payment processor can blow straight through the limit, at which point SPF returns a permerror and, depending on the receiver, your mail can start failing authentication entirely.

The symptom is maddening because it appears intermittently and after you add a new tool, not when you first set things up. If you are close to or over the limit, the answer is SPF flattening, which resolves those includes down to the underlying IP ranges so you stay within ten lookups. We explain the mechanics in SPF and the 10-lookup limit and how SPF flattening works. You can test your own record against the limit with the SPF checker. For a charity adding and dropping seasonal campaign tools, this is not a one-off check, it is something that needs watching, which is where ongoing monitoring earns its place.

BIMI: your logo on every message, and the CMC route for charities without a registered trademark

This is the part that connects authentication directly back to donor trust, and the part where charities have a specific advantage worth knowing about.

BIMI, Brand Indicators for Message Identification, displays your organisation's logo next to your messages in supporting mailbox providers. For a charity that is not a cosmetic nicety. A recognisable logo in the inbox raises open rates, reinforces that the message is genuinely from you, and gives supporters a visual cue that the fake appeal sitting two messages above (which carries no logo) is not from you. BIMI turns authentication into something your donors can actually see. The background is in do you need BIMI and the BIMI glossary entry.

The hard precondition is that BIMI requires DMARC at enforcement. You cannot display a BIMI logo until your domain is at p=quarantine or p=reject. This is deliberate: the logo is a reward for having locked down your domain, and it would be worthless if spoofers could display it too. So BIMI is the natural finale of the enforcement journey above, not a separate project.

Here is the historic problem for charities. For mailbox providers that demand certificate-backed BIMI, most notably Gmail, you traditionally needed a Verified Mark Certificate (VMC), and a VMC is only issued for a logo that is a registered trademark in a recognised jurisdiction. Many charities have never registered their logo as a trademark. Registration costs money and legal time that a small nonprofit reasonably spends elsewhere, so a large number of charities were locked out of certificate-backed BIMI entirely, despite being exactly the kind of trusted, frequently-impersonated sender that benefits most from it.

The Common Mark Certificate (CMC) is the route that fixes this. A CMC is a certificate type designed for logos that are not registered trademarks, including marks that have been in prior use or, importantly, marks belonging to organisations such as charities and government bodies that fall outside the standard trademark path. It lets an organisation obtain a certificate-backed BIMI logo without first registering a trademark. For a nonprofit whose logo is well known to its supporters but was never formally registered, the CMC is the difference between displaying a logo in Gmail and not.

Two honest caveats, because this article is not a sales page:

• CMC support across mailbox providers is newer and narrower than VMC support. Gmail's CMC support arrived later than its VMC support, and not every provider treats a CMC identically to a VMC. The landscape is still settling. So a CMC is the right route for an unregistered charity logo, but set expectations that coverage will keep expanding rather than already matching VMC everywhere. See the CMC glossary entry and the VMC glossary entry for the current distinction.
• A CMC still has requirements. The logo must be supplied as a square SVG in the Tiny PS profile, the certificate must chain to a trusted root, and the logo embedded in the certificate must match the logo you publish at your BIMI l= URL. If you edit the published SVG after the certificate is issued, you silently break that match and the logo stops rendering. Treat the logo as frozen once the certificate exists.

A BIMI record with a certificate looks like this:

default._bimi.yourcharity.org  TXT  "v=BIMI1; l=https://yourcharity.org/bimi/logo.svg; a=https://yourcharity.org/bimi/cmc.pem"

The a= tag points at the certificate, whether VMC or CMC. You can validate the whole chain, the expiry and the logo match, and preview how the mark will render in an inbox, with the BIMI checker before you rely on it. The BIMI product page covers how the hosted setup handles the SVG profile, the certificate and the record together.

What a charity should actually do, in order

Pulling the whole thing together into a sequence a busy nonprofit can follow:

1. Inventory your senders. List every system that sends mail with your domain in the From line: staff mail, CRM, fundraising platform, newsletter tool, payment processor, events system, any mail-merge scripts. You cannot protect what you have not listed.
2. Publish p=none with rua reporting. This is safe, changes no delivery, and starts the flow of data that shows you reality rather than what you assumed. Pair it with continuous monitoring and change alerts so you are told when a record changes or a new unaligned sender appears.
3. Fix alignment for every legitimate source. Custom return-paths for SPF alignment, DKIM CNAMEs for DKIM alignment, and a clean SPF record under the 10-lookup limit.
4. Ramp through quarantine to reject, ideally testing across at least one full appeal cycle so your biggest send is proven before you reach full enforcement.
5. Add BIMI, using a VMC if your logo is a registered trademark or a CMC if it is not, so your logo appears next to every message and your supporters get a visual trust signal that the impersonators cannot copy.

None of this requires a large IT team, but it does require care and continuity, because a charity's sending mix changes with every campaign and a single new tool added without alignment can reintroduce both the deliverability and the spoofing problem. Continuous monitoring, rather than a one-off project, is what keeps a charity safe between campaigns. You can watch your domain and get alerted to changes through monitoring.

The practical takeaway

For a nonprofit, email authentication is donor trust and fundraising revenue expressed as DNS records. The same SPF, DKIM and DMARC work that stops attackers spoofing your appeals is what lifts your own legitimate appeals out of the spam folder, and BIMI then turns all of that invisible plumbing into a logo your supporters can see in the inbox. Crucially, a charity whose logo was never registered as a trademark is no longer locked out of that last step: the Common Mark Certificate route exists precisely so unregistered logos, common among charities and public-sector bodies, can carry a certificate-backed BIMI mark.

Start by seeing where you stand. Run your domain through the DMARC checker, the SPF checker and the BIMI checker, then publish p=none and read what the reports tell you. If you would rather not run the staged rollout, the SPF flattening, the alignment fixes and the BIMI certificate yourself, the managed DMARC service takes a charity domain from p=none to p=reject and on to a displayed logo, safely, with no email outage and no appeal lost on the way.