Emails were arriving at a Maryland / DC private foundation that appeared to come from the executive’s own address. The foundation asked us two questions: how is this possible, and is our email set up securely?
The short answer: if your domain is missing a few email security settings, anyone can send a message with your address in the “From” line. This is called email spoofing. It can land in your own inbox, your staff’s, your vendors’ or your donors’. To the person reading it, it looks like it came from you. That one email can be used to:
- approve a payment or a wire transfer
- change a vendor’s or grantee’s bank details
- redirect a staff member’s payroll deposit to a new account
- send supporters to a fake donation page
- request passwords, donor lists or other sensitive files
Most small organizations don’t know whether their domain is protected until something like this happens.
At a glance
| Client | A private foundation in Maryland |
| Setup | Google Workspace for email, a WordPress website, two domains |
| Services | Domain and email security assessment, DNS cleanup and documentation, Google Workspace security review |
| Timeline | Core changes in the first week, then a monitoring period before full enforcement |
What we found
No one had a clear picture of how the foundation’s domains were set up. Earlier setups had added DNS records without removing the old ones, and none of it was documented. Over time the configuration became a mix of current, outdated and invalid entries:
- Mail routing was a patchwork. The email domain’s MX records combined current Google entries, legacy ones and a Google web-services host that doesn’t handle mail. Google Workspace showed Gmail as not fully activated.
- Old records pointed nowhere. The website domain still had a mail record for a host that no longer exists.
- Wildcard DNS on both domains meant any made-up subdomain would resolve, which can be used to build convincing look-alike links.
- No email authentication. The key is that neither domain had SPF, DKIM or DMARC, so nothing stopped someone from sending email that looked like it came from the foundation.
What we did
We started by recording the existing DNS setup as a baseline and taking a full inventory of the foundation’s systems and processes, confirming which of them could send emails from either domain. The inventory showed Google Workspace was the only legitimate sender on the email domain, and nothing sent mail from the website domain. Then we cleaned up the setup one change at a time, testing each with a live message.
Removed
- Invalid and legacy MX records on the email domain
- The dead mail record on the website domain
- Wildcard records on both domains
Added
- Google’s current recommended MX record, with incoming mail confirmed
- SPF records based on the inventory: Google Workspace as the only authorized sender for the email domain, and a deny-all record for the website domain
- 2048-bit DKIM signing in Google Workspace
- DMARC on both domains, first in monitoring mode
- Explicit records for the website in place of the wildcards
Enforced. Before tightening the policy, we reviewed the DMARC reports with the foundation as a final check that no legitimate email would be blocked. The reports also showed many unauthorized, illegitimate servers sending mail in the foundation’s name. We then moved the policy to enforcement, ending at reject, so those messages are now refused.
Documented. Every change went into a change log with before-and-after values. The foundation received a completion report describing the final configuration.
Reviewed. We also went through the foundation’s overall security posture and Google Workspace security: account settings, two-step verification, recovery options and admin controls. The foundation received a written report with a prioritized action plan.
Results
| Before | After | |
|---|---|---|
| Documentation | None | Baseline, change log and final configuration on file |
| Mail routing | Mix of current, legacy and invalid MX records; Gmail not fully activated | Google’s recommended record; delivery confirmed |
| Stale records | Dead mail record and wildcard DNS | Removed; explicit records only |
| SPF / DKIM | None | Google Workspace authorized; 2048-bit signing verified |
| DMARC | None | Enforced at reject |
Forged email in the foundation’s name is now rejected by receiving mail servers. The next person who manages the domains starts from a clean, documented setup instead of guesswork.
Why it matters
Foundations and nonprofits are frequent targets for email spoofing and impersonation because their staff, vendors and donors are used to acting on the director’s word.
Much of the risk came from the lack of documentation. Records were added over time and never removed, and no one knew which ones were still needed. Without documentation, every change is guesswork, and adding security records on top only hides the problem. With the setup documented, whoever manages it next can see what is there and why.
Want to know where your domain stands? We’ll check your SPF, DKIM and DMARC for free and walk you through what we find. Write to . See our cybersecurity services and nonprofit IT support.
