Do small charities really need DMARC?

Yes, and since February 2024 the major mailbox providers effectively require it for bulk senders. Even small charities that send a monthly newsletter from a domain that also handles donation receipts should publish DMARC, because the alternative is allowing anyone to spoof your domain in phishing attacks against your own supporters.

What does a DMARC policy of "p=none" actually do?

It tells mailbox providers to send you reports about what email passes and fails authentication for your domain, without rejecting anything. It is the correct starting policy. You move to p=quarantine and then p=reject after several weeks of clean reports.

Why do some of our emails still go to spam after we set this all up?

Authentication is necessary but not sufficient. Content, sender reputation, list quality and engagement all influence inbox placement. Authentication tells the mailbox provider it is really you. Reputation tells them whether the real you is worth showing.

Can we use our donation platform to send our newsletter?

You can but it is rarely the right call. Donation platforms optimise for transactional delivery. Newsletter platforms (Mailchimp, Brevo, Beehiiv, the Microsoft 365 newsletter add-ons) handle list hygiene, engagement tracking and authentication alignment far better. Use the right tool for each job and authenticate both.

Email Deliverability for Charities: SPF, DKIM and DMARC

Most charity email problems are not creative problems. They are deliverability problems. The three DNS records that decide whether supporters see your appeals at all, set up properly with the habits that keep them working.

A small charity emailed 4,200 supporters about a Christmas appeal last December. Open rate showed 17 percent. They assumed the appeal was weak. The actual problem was that 38 percent of the send never reached an inbox at all. It was filtered to spam by Gmail and Outlook on the way in. The appeal was fine. The DNS records were wrong.

This is now the most common single cause of disappointing charity email results. Since February 2024, Google and Yahoo have enforced authentication requirements for bulk senders. Microsoft followed with stricter rules through 2025. A charity domain that lacks correctly aligned SPF, DKIM and DMARC will see deliverability fall, slowly at first and then sharply, regardless of the quality of the content.

What each record actually does

SPF: who is allowed to send as your domain

A Sender Policy Framework record is a single line in your DNS that lists which servers may send mail on behalf of your domain. When a mailbox provider receives an email claiming to be from `you@yourcharity.org.uk`, it checks SPF to confirm the sending server is on the approved list.

A typical record for a charity using Microsoft 365 for staff mail and Mailchimp for newsletters looks like `v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all`. The `-all` at the end tells mailbox providers to reject mail that fails the check. Use `~all` (soft fail) only during initial setup.

DKIM: a signature that proves the message was not altered

DomainKeys Identified Mail adds a cryptographic signature to outgoing email. The recipient checks the signature against a public key published in your DNS. If the message body has been altered in transit, the signature fails and the message is flagged.

Every sending platform you use needs its own DKIM key published in your DNS. Microsoft 365 generates two CNAME records (`selector1` and `selector2`). Mailchimp generates its own. Brevo, Stripe, your donation platform: each one has setup instructions that produce DNS records. Add them all.

DMARC: the policy and the reporting

DMARC sits on top of SPF and DKIM. It tells mailbox providers what to do when a message claims to be from your domain but fails authentication, and it gives you a daily report of what was sent in your name.

A minimal starting DMARC record looks like:

v=DMARC1 - the version tag (always this).
p=none - the policy (none means observe only, the correct starting point).
rua=mailto:dmarc-reports@yourcharity.org.uk - the address to receive aggregate reports.
fo=1 - request reports for any failure (more useful than the default).

Read those reports for at least three weeks before changing the policy. You will discover sending services you forgot existed: an old fundraising platform, a HR provider sending payslips, a survey tool. Add DKIM and SPF for the ones that should send as you. Disconnect the ones that should not.

Alignment, the bit that catches people out

A common failure mode is having SPF and DKIM technically pass while DMARC still fails. This is alignment. DMARC requires that the domain in the visible `From:` header matches the domain used in the SPF check or the DKIM signature, not just that the signatures themselves verify.

A charity sending its newsletter through Mailchimp with `From: appeals@yourcharity.org.uk` needs Mailchimp to be configured to use `yourcharity.org.uk` as the DKIM signing domain, not Mailchimp's default `mcsv.net` domain. The setting is called "Verify Domain" in Mailchimp, "Authentication" in Brevo and similar in every other platform.

The setup order that avoids breakage

Inventory every service that sends email as your domain. Include: staff mail, newsletter platform, donation platform receipts, ticketing platform, HR/payroll provider, helpdesk, survey tool, fundraising regulator notifications.
For each, follow its DNS-record setup instructions. Add SPF includes one at a time. Add DKIM CNAMEs as supplied.
Publish DMARC with p=none and a reporting address.
Wait two to three weeks. Read the daily aggregate reports (use a tool like Postmark DMARC Digests or Valimail Monitor; both have free tiers for low-volume domains).
Resolve any unauthenticated sources, either by authenticating them or removing them.
Move the DMARC policy to p=quarantine for another two weeks.
Move to p=reject. Keep monitoring.

Monitoring rhythm

Deliverability is not set-and-forget. Mailbox providers change requirements, sending services rotate IPs, your team adds new tools. A small monthly check protects what you set up:

Review the DMARC aggregate report summary once a month. Investigate any new sources.
Check Google Postmaster Tools for your domain reputation monthly if your supporter list skews Gmail-heavy (most UK charity lists do).
Check Microsoft SNDS quarterly if your list skews Outlook/Hotmail.
When adding a new sending service, do the DNS work before sending the first email, not after.

Bonus: BIMI, when it is worth it

Brand Indicators for Message Identification lets your verified logo display next to the sender name in Gmail and Apple Mail. The qualifying conditions are: a strict DMARC policy (p=quarantine or p=reject), a Verified Mark Certificate from one of three approved providers, and a square SVG logo in a specific tiny-file format.

For charities that send to large consumer lists, BIMI noticeably lifts open rates because supporters visually recognise the sender before opening. For charities sending mainly to organisational addresses, the certificate cost (roughly 1,200 to 1,500 pounds annually) usually outweighs the benefit. Implement only after the rest of the stack is solid and stable for at least six months.

The cheapest fundraising win available to most UK charities right now is not a new appeal. It is making sure the appeals they already send actually reach an inbox.

When to escalate

If you have authenticated everything correctly and you are still seeing material inbox-placement issues after a month, the problem is reputation rather than authentication. That requires a different remedy: warm a new sending IP through your platform, reduce send frequency to the most engaged segments only, run a reactivation programme, and let the reputation recover. The DNS work is the precondition. The list and content work is the rest.