SPF, DKIM, and DMARC are email authentication protocols that prove to inbox providers that your emails are actually from you. As of 2024, Google and Yahoo require proper authentication for bulk senders — making this a non-negotiable for any nonprofit sending fundraising emails.
This guide explains what each protocol does, why they matter for your mission, and how to set them up — in plain language, without requiring an IT background.
Why Email Authentication Matters
When you send an email from your nonprofit, you are not just sending a message. You are making a claim: "This email actually comes from [yourorganization.org]."
Without authentication, any server in the world can send email claiming to be from your domain. Spam filters know this, and they treat unauthenticated email with appropriate skepticism. The consequences for your organization:
- Deliverability problems. Unauthenticated emails from your domain go to spam folders, often silently. You send December appeals believing they reached thousands of donors. Many did not reach the inbox.
- Phishing and impersonation risk. Bad actors can send fraudulent emails appearing to come from your domain — targeting your donors with scam messages that damage trust.
- Gmail and Yahoo enforcement. Both providers announced 2024 requirements for bulk senders: authentication is mandatory. Non-compliant senders face email rejection, not just filtering.
Authentication is not a technical nicety. It is the foundation of a functional email program.
The Three Protocols Explained
SPF: Who Is Allowed to Send
What it does: SPF (Sender Policy Framework) is a list of servers authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from yourorganization.org, it checks your SPF record to confirm the sending server is on the approved list.
How it works in practice:
- You add a TXT record to your domain's DNS settings
- The record lists your authorized email providers (e.g., your email marketing platform, your Google Workspace)
- When an email arrives from an unauthorized server claiming to be you, it fails SPF
What an SPF record looks like:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The ~all at the end is a "soft fail" — unauthorized mail is flagged but not rejected. Once you have confirmed your legitimate senders are included, you can use -all for a hard fail.
Common mistake: Forgetting to include your email marketing platform. If you use a third-party ESP to send fundraising emails, it must be in your SPF record.
DKIM: Proving the Message Wasn't Tampered With
What it does: DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. The signature is generated using a private key on your sending server and verified by receiving servers using a public key published in your DNS.
If an email is intercepted and modified in transit, the signature will not match, and receiving servers will know the message was tampered with.
How it works in practice:
- Your email provider generates a DKIM key pair (private key on their servers, public key for your DNS)
- You add the public key as a TXT record in your DNS
- Every email you send is automatically signed with your private key
- Receiving servers verify the signature against your public key
What a DKIM record looks like:
mail._domainkey.yourorganization.org IN TXT "v=DKIM1; k=rsa; p=\[long public key string\]"
Your ESP provides the exact record to add — you do not need to generate the key yourself.
DMARC: What to Do When Authentication Fails
What it does: DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM by:
- Telling receiving servers what to do when authentication fails (allow, quarantine, or reject)
- Providing reports back to you showing authentication results across all email sent from your domain
Why DMARC matters: SPF and DKIM protect against specific attack vectors. DMARC ties them together and gives you visibility into what is happening with email claiming to be from your domain — including email you did not send.
DMARC policy options:
p=none— Monitor only. Authentication failures are reported but no action is taken. Start here.p=quarantine— Authentication failures are sent to the spam folder. Move here after reviewing reports.p=reject— Authentication failures are rejected entirely. This provides maximum protection but requires confidence that all legitimate senders are properly configured.
What a DMARC record looks like:
v=DMARC1; p=none; rua=mailto:dmarc@yourorganization.org; pct=100
The rua field is where aggregate reports are sent. These reports show which servers are sending email claiming to be from your domain — legitimate or otherwise.
Step-by-Step Setup Guide
Before You Start
Gather this information:
- Access to your domain's DNS settings (usually through your domain registrar or hosting provider)
- The name of your email marketing platform (Mailchimp, Constant Contact, sherbertOSOS, etc.)
- The name of your transactional email provider if different (SendGrid, Postmark, etc.)
- Your Google Workspace or Microsoft 365 account if you use them for staff email
Step 1: Set Up SPF
Log into your domain registrar or DNS provider
Create a new TXT record for your domain (e.g., yourorganization.org)
Set the value to include all your authorized sending services:
v=spf1 include:_spf.google.com include:yourESP.com ~allSave the record
Your ESP will provide their specific include value in their documentation.
Step 2: Set Up DKIM
- In your email marketing platform or ESP, find the DKIM settings (usually under "Domain Authentication" or "Sending Domains")
- The platform will provide a DKIM public key in the form of a TXT record to add to your DNS
- Add the TXT record to your domain's DNS exactly as specified
- Return to the platform and run the DKIM verification test
Each sending platform has its own DKIM key. If you use two platforms (e.g., Google Workspace for staff email and an ESP for fundraising), you need DKIM records for both.
Step 3: Set Up DMARC
Create a new TXT record at
_dmarc.yourorganization.orgSet the value to a monitoring policy to start:
v=DMARC1; p=none; rua=mailto:dmarc@yourorganization.orgAfter 2–4 weeks of reviewing reports, move to
p=quarantineOnce confident in your configuration, move to
p=reject
Step 4: Verify
DNS changes take up to 48 hours to propagate globally, but often take effect in 15–30 minutes. After 24 hours, use a free verification tool (MXToolbox, Mail Tester, or your ESP's domain verification feature) to confirm all three records are properly configured.
How Long Does It Take?
| Task | Time Required |
|---|---|
| Gather sending platform information | 15–30 minutes |
| Add SPF, DKIM, and DMARC records to DNS | 30–60 minutes |
| DNS propagation | Up to 48 hours |
| DMARC monitoring period before tightening policy | 2–4 weeks |
Total hands-on time: 1–2 hours. The waiting is automatic.
The sherbertOSOS Domain Authentication Wizard
sherbertOSOS includes a guided domain authentication setup wizard that walks through SPF, DKIM, and DMARC configuration with step-by-step instructions specific to your sending configuration. After setup, the wizard runs a verification test to confirm all records are active and correctly configured — no external tools required.
Frequently Asked Questions
What happens if I don't set up email authentication?
Your emails may go to spam folders, get rejected entirely, or display warning badges in recipients' email clients. As of 2024, Google and Yahoo block or heavily filter unauthenticated bulk email. Non-authenticated senders also face increasing friction as inbox providers tighten standards.
Do I need all three (SPF, DKIM, DMARC)?
Yes. SPF verifies the sending server is authorized. DKIM verifies the message content was not tampered with. DMARC ties them together and tells receiving servers what to do when either check fails — and gives you reporting visibility. All three together provide comprehensive protection. SPF and DKIM without DMARC leaves significant gaps.
How long does authentication take to set up?
DNS record changes take 15–60 minutes to configure and up to 48 hours to propagate. The actual setup is straightforward with proper guidance. Most nonprofit operations staff can complete it without developer assistance.
What if I use multiple email platforms?
Include all authorized sending services in your SPF record. Generate and install DKIM keys for each platform separately. DMARC sits above both and covers all of them.
How do I read DMARC reports?
DMARC reports are XML files that are difficult to read manually. Free tools like DMARC Analyzer (free tier) or MXToolbox's DMARC report reader convert them into readable dashboards. After a few weeks of monitoring, patterns become clear.
The Bottom Line
Email authentication is not optional in 2024 and beyond. It is the technical foundation that allows your fundraising emails to reach the inboxes they were sent to — rather than spam folders or nowhere at all.
The setup takes a few hours. The protection is permanent. The alternative — sending fundraising appeals that never arrive — is not an acceptable substitute.
sherbertOSOS includes a domain authentication wizard that guides SPF, DKIM, and DMARC setup with verification testing, so your team can complete configuration without technical support.
→ Start your free trial and complete email authentication setup in your first session.
Frequently Asked Questions
What happens if I don't set up email authentication?
Your emails may go to spam, get rejected entirely, or display warning badges. Google and Yahoo now block unauthenticated bulk email.
Do I need all three (SPF, DKIM, DMARC)?
Yes. SPF verifies the sending server, DKIM signs the message content, and DMARC tells receiving servers what to do with messages that fail authentication.
How long does authentication take to set up?
DNS record changes take 15-30 minutes to configure and up to 48 hours to propagate. The actual setup is straightforward with proper guidance.
Related Articles
Try sherbertOS free
See how sherbertOS simplifies your nonprofit operations.