Why Your Account Engagement Emails are Not Landing

SPF published. DKIM key generated. Green checkmark inside Account Engagement. Your test email landed in your own inbox in eight seconds, so you sent the appeal to 22,000 donors and the open rate came back at 4%.

Account Engagement won’t tell you why. The send shows as completed. There are no errors in the dashboard. The emails were handed off to receiving servers and either quietly filed into spam or refused at the door — a judgment call your platform never sees. That’s usually the moment a client calls us asking why their Account Engagement emails aren’t landing despite following every step of the SPF/DKIM setup guide. This is the diagnostic work we walk clients through in a Salesforce org review, and it almost never turns out to be a content problem.

1. Your SPF Record Broke When You Added the Tenth Service

SPF records can only process 10 DNS lookups. Exceeding that limit doesn’t cause the record to degrade gracefully. It fails completely, and every receiving server then treats your mail as unauthenticated — with no warning anywhere in Account Engagement.

Count a typical nonprofit stack and you’ll see how easily this happens. Google Workspace, Salesforce, Account Engagement, a donation platform, event registration software, a peer-to-peer fundraising tool, and a payment processor sending receipts already puts you at seven. Add a legacy eblast tool nobody formally turned off and you’re at eight or nine before anything unusual enters the picture.

Fix: Don’t just confirm the SPF record exists. Run it through an SPF lookup validator and check how many DNS lookups it actually resolves to. At 10 or over, flatten the record or remove dead services from it. The eblast platform from 2019 is almost always still sitting in there.

2. You Have SPF and DKIM But No DMARC

Most SPF/DKIM setup guides predate February 2024 and stop at two protocols. Gmail, Yahoo, and Microsoft now require a published DMARC record for bulk senders. They also require alignment, meaning the domain in your From address has to match your SPF or DKIM signing domain.

Two details catch nonprofits specifically. Enforcement escalated from temporary deferrals to outright rejection, so failed mail no longer lands somewhere a staff member can find and forward. Consequently, the 5,000-per-day bulk threshold is permanent once crossed — a single 30,000-person year-end appeal makes your organization a bulk sender for every 400-person newsletter you send in March.

Fix: Publish DMARC at p=none first. That’s monitoring mode, and it changes nothing about delivery while it starts reporting which of your connected services are failing alignment. Read a few weeks of those reports before tightening to p=quarantine. Tightening first is how organizations end up blocking their own donation receipts. Our guide on DMARC monitoring mode for Salesforce sending domains covers how to read the aggregate reports without a dedicated email deliverability tool.

3. You’re Sending From a Domain You Don’t Control

Account Engagement’s own documentation says not to send from a domain you don’t own. You can’t authenticate a domain that isn’t yours, and to receiving servers that mail looks like spoofing regardless of intent.

Unfortunately, the nonprofit sector runs on arrangements that produce exactly this setup. A fiscal sponsor sends on behalf of a sponsored project. A national office mails for local chapters. A co-branded partner appeal goes out under two organizations’ names. Or there’s a standing request to send the year-end letter from the executive director’s personal address because it’s supposed to feel personal.

Fix: Send from a domain you can add DKIM to directly. Chapters and fiscal-sponsor partners each need their own DKIM key generated before their first send — Account Engagement supports unlimited sending domains, but it won’t authenticate any of them for you automatically. For the personal-touch request, use a display name of “Maria Chen, Executive Director” with a From address on your own domain instead. It reads the same to the donor and it actually authenticates. See our post on multi-domain DKIM setup for chapter and fiscal-sponsor relationships for the step-by-step.

4. Your Tracker Domain Doesn’t Match Your Sending Domain

Account Engagement rewrites every link in an email through your primary tracker domain, regardless of which domain the message was actually sent from. That mismatch is a common, invisible cause of filtering.

If the message says it’s from @yourorg.org but every link points somewhere else, filters notice. This shows up most often after a rebrand, a merger, or a website platform change, when links quietly point at the old organization’s domain or a subdomain with an expired SSL certificate. Filters evaluate this on content, so perfect SPF and DKIM authentication won’t offset it.

Fix: Confirm your tracker domain is a subdomain of your current sending domain and that it has a valid SSL certificate. If your organization has renamed, merged, or changed web or marketing vendors in the last three years, check this before anything else on this list.

5. Your List Is the Actual Problem

Authentication only makes you eligible to send. Recipient behavior decides what happens after that. Complaint rate has to stay under 0.3%, and the real working target is under 0.1%.

Nonprofits accumulate the worst possible list conditions by default. Donor records go back fifteen years. Event lists were built without anyone formally asking permission. Spreadsheets get inherited from a merger. A twice-a-year sending cadence guarantees every campaign hits a stale list. A dormant list reactivated specifically for a year-end appeal is the single most common cause of sudden deliverability collapse — addresses have decayed into spam traps, recipients no longer remember signing up, and complaints spike on the exact send that matters most.

Fix: Suppress anyone who hasn’t opened in 12 months before your next major appeal, not after it. Warm dormant segments back in with something useful first, rather than leading with the ask. Confirm one-click unsubscribe actually works, too — a recipient who can’t find it uses the spam button instead, and that costs far more than a lost subscriber. This is the kind of donor-data audit we run as part of a Salesforce org review, because the DNS records are rarely the whole story.

Why Did Your Test Email Arrive When the Campaign Didn’t?

A test email landing in your own inbox proves almost nothing about deliverability. Internal sends often route differently than production sends do. Mail between colleagues on the same domain routinely skips the filtering that external recipients’ providers apply.

A successful test confirms the email was built correctly and sent. It doesn’t confirm that a Gmail user who has never heard of your organization will actually see it in their inbox.

Fix: Seed-test to external addresses across Gmail, Outlook, and Yahoo before every major send, not just the first one after a setup change.

What Order Should You Work Through These Fixes In?

Work through these checks in the order below, because some of them depend on data you don’t have yet at the start.

1. Read the actual send data first. Bounce reasons tell you whether mail is being refused outright or accepted and then filtered — different problems, different fixes.
2. Count your SPF lookups. The question isn’t whether the record exists. It’s how many lookups it resolves to.
3. Publish DMARC at monitoring mode and read at least two weeks of reports before changing anything.
4. Verify DKIM on every sending domain in use, not just the primary one.
5. Check the tracker domain for a mismatch and for SSL validity.
6. Suppress the dormant segment before your next send, not after.
7. Seed-test externally across the major consumer providers.

Frequently Asked Questions

Why did our test email arrive but the campaign didn’t?

Internal and test sends often route differently and skip the filtering external recipients’ providers apply. A successful test confirms the email was built and sent correctly, not that an unfamiliar recipient’s provider will accept it.

Do we need DMARC if we only send a few thousand emails a month?

Yes. The bulk-sender threshold is 5,000 emails per day, but a single large appeal can cross it in one send. The bulk classification doesn’t reverse once your volume drops back down. DMARC reporting is also the only reliable way to see which connected services are sending as your domain and failing alignment.

Can we send our appeal from a board member’s or partner’s email address?

Not without authenticating that domain first. Sending from a domain you don’t control produces unauthenticated mail that receiving servers treat as spoofing, and the reputation damage attaches to your organization. Use a display name on your own domain instead — it reads the same to the recipient and it actually authenticates.

How long until we see improvement after fixing our DNS records?

DNS changes typically propagate within about 48 hours. Sender reputation itself recovers more slowly, over weeks of consistent low-complaint sending. Fix the records well before your appeal window opens, not during it.

Does fixing SPF, DKIM, and DMARC guarantee our emails will land in the inbox?

No. Authentication only makes your mail eligible for inbox placement. Recipient engagement and complaint rate still determine what happens after that, which is why list hygiene is one of the five factors above rather than an afterthought.