i think that we can update kind of what we're doing is on the pauldolphin.com we don't need to say anything about what we're building outEmail Deliverability Deep-Dive — Brothers Redevelopment, Inc.

Prepared by: Paul Dolphin, Managing Partner — AXIA Capital and Homestead Capital Partners

Date: 2026-05-22

Subject domain: brothersredevelopment.org

Trigger: Mailbox from dmiller@brothersredevelopment.org landed in Gmail Spam folder on 2026-05-21 with the explicit Gmail warning: "This message might be dangerous. It contains a suspicious link that was used to steal people's personal information."

TL;DR (read this first if you read nothing else)

Three configuration issues, each independently sufficient to put your outbound mail into Gmail's spam folder:

1. DKIM key is 9 years old, 1024-bit, and was originally set to expire in May 2017. Gmail downgrades the trust of 1024-bit RSA keys and treats keys with stale or expired n= lifetime fields as a deliverability negative.

2. DMARC reports are routed to dmarc@rmtt.com, which is not your domain. Either rmtt.com is a former vendor that is not monitoring on your behalf, or it is an active vendor that no one inside Brothers Redevelopment is checking. Either way, the reports that would have warned you about the deliverability problem have been going to a mailbox you do not own.

3. The specific 5/21 email pattern (11 attachments, multiple shortened or redirector URLs in the body, an outbound newsletter platform footer, and the subject line "Rental Assistance") is the exact signature Gmail's safe-browsing layer treats as a high-probability phishing attempt. The flag was not random.

The combination of an old/weak DKIM signature, a DMARC reporting pipeline that no one inside the organization is reading, and a heavy-attachment + multi-link message body is the deliverability worst case. Each fix is straightforward; the order they should be addressed is in Section 7 below.

1. Authentication state, observed 2026-05-21 22:00 MT

1.1 SPF

Record (verbatim, queried 2026-05-21):

v=spf1 include:spf.protection.outlook.com include:spf-0.secureserver.net ip4:67.222.31.236 include:_spf.intacct.com ~all

Observations:

Primary mail platform is Microsoft 365 (Outlook / Exchange Online). The `spf.protection.outlook.com` include is correct for this.
A GoDaddy include (`spf-0.secureserver.net`) is also present. This typically indicates either a legacy GoDaddy mailbox that has not been retired or a parked secondary domain. If GoDaddy mail is no longer used, this include should be removed because it broadens the surface for SPF spoofing.
`ip4:67.222.31.236` reverse-resolves to `cp35-ga.privatesystems.net`. This is a shared hosting IP. Authorizing a shared hosting IP for outbound mail means any other tenant on that IP can send mail that passes SPF for your domain. This is a meaningful supply-chain risk and should be removed unless there is an active reason to keep it.
`_spf.intacct.com` is Sage Intacct (accounting). This is reasonable if Intacct sends invoices or vendor remittances from `@brothersredevelopment.org` addresses, but it should be reviewed quarterly.
The terminator is `~all` (softfail). Best practice for a mature sender is `-all` (hardfail) after you confirm the include chain is complete. Softfail tells Gmail "treat unauthorized mail as suspicious, do not reject." That is a hint, not a guard.

DNS-lookup count for SPF: 4 active includes plus the implicit MX/A lookups. SPF has a hard limit of 10 DNS lookups per evaluation; adding any new sender (HubSpot, Mailchimp, Constant Contact, Salesforce Marketing Cloud) without consolidating will break authentication for everyone.

1.2 DKIM

Microsoft 365 DKIM is enabled with two selectors (selector1, selector2), both pointing into the standard brothersredevelopment.onmicrosoft.com zone via CNAME. The actual key value resolved as:

v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFx6V9c5Bh0F5lZmlDmMmXJxGwiRBWVz9YoVwRz/SiS4m/68F6Vu0+E7ZIC377f3mnF4mE4GybqZthNPRTPy7UiFop4KPXTjyUeNvcjIu30cih/S2nPXsmd+1VAosdX2VH3AHW3qXnLruMnPbVZKKh4tSVTVjKKy6Sldan+Q4nZQIDAQAB;
n=1024,1478654302,1494292702

Decoding the n= field:

Field	Value	Decoded
Key bit length	1024	1024-bit RSA
Created (unix)	1478654302	2016-11-08 18:18 UTC
Original expiry (unix)	1494292702	2017-05-08 19:18 UTC

The key was created November 2016, was originally intended to be rotated by May 2017, and is still in production in May 2026. That is nine years past its declared rotation date.

Three independent problems with this:

1. 1024-bit RSA is below Gmail's preferred floor. Gmail accepts 1024-bit signatures but applies a trust discount, and has been signaling for years that 2048-bit is the new minimum. The signature still validates; it just earns fewer trust points. (Reference: Google's bulk-sender guidance updated February 2024.)

2. The stale n= timestamp signals key-hygiene neglect. Spam filters that parse the optional notes field treat keys past their declared expiry as a negative signal even when the cryptographic verification still passes.

3. Manual rotation in Microsoft 365 is one click. Exchange Admin Center → Mail Flow → DKIM → select domain → Rotate DKIM keys. The platform generates a 2048-bit key, publishes the new selector, and sunsets the old one with no email downtime. There is no operational reason this hasn't been done; it is almost always an "I didn't know it was a thing" problem rather than a "we evaluated and chose not to" decision.

1.3 DMARC

Record:

v=DMARC1; p=reject; rua=mailto:dmarc@rmtt.com; ruf=mailto:dmarc@rmtt.com; fo=1;

Observations:

Policy is `p=reject`, which is correct and mature. Receivers should reject mail that fails both SPF and DKIM alignment.
Aggregate reports (`rua`) and forensic reports (`ruf`) both go to `dmarc@rmtt.com`. rmtt.com appears to be Rocky Mountain Technical Team (a Denver IT-services firm) based on the domain registration metadata. This is plausibly your IT vendor.
The risk: if rmtt.com is an old vendor that you no longer work with, every Gmail and Yahoo DMARC report about your domain is going to a mailbox you can't read. You have no visibility into authentication failures, no early warning when DKIM breaks, and no audit trail. If it is a current vendor, the question is whether anyone inside Brothers Redevelopment ever reviews the digest. Aggregate DMARC reports without human review are a configuration that looks correct on paper and produces zero operational value.
Recommendation: at minimum, add a CC address inside `@brothersredevelopment.org` (e.g., `dmarc-rua@brothersredevelopment.org` routed to IT). At best, replace with a dedicated DMARC analytics service such as Postmark DMARC, Valimail Monitor, or DMARC Digests, all of which are free at this volume.

1.4 MX

brothersredevelopment-org.mail.protection.outlook.com — Exchange Online. Standard, no concerns.

2. Why Gmail's Safe Browsing flagged the 5/21 message specifically

Gmail's spam decision is multi-factor, but the "suspicious link" warning is a different system from generic spam scoring. That language is from Google Safe Browsing, which evaluates the URLs in the message body, not the sender. The two systems compound: a message can pass spam scoring and still earn the red warning bar from Safe Browsing.

Probable triggers, in order of likelihood:

1. Multiple bare URLs to non-brand domains in the body. The 5/21 email contained links to Denver TRUA program pages, CERA pages, a CARE Center landing page, a mediation contact, and at least one URL-shortener-style redirect that Gmail's link analyzer treats as an indirect-redirect pattern. Mass-mailers that ship users to multiple external destinations are common phishing infrastructure; a legitimate nonprofit sharing legitimate resources looks identical to the classifier.

2. 11 attachments on a single outbound message from an @brothersredevelopment.org user. Most legitimate email from staff at small nonprofits ships 0-2 attachments. Bulk attachment counts on case-management emails are a known phishing pattern (attackers send "your invoice" or "your subpoena" with PDF payloads). Gmail weights this heavily.

3. The subject line "Rental Assistance" is high-frequency in phishing corpora. Refund-and-grant subjects ("Rental Assistance," "Stimulus Available," "Your Application Status") are heavily abused in phishing campaigns. Legitimate senders should still use them when accurate, but they raise the bar for everything else in the message to look clean.

4. The body almost certainly contains links written as anchor text differing from the underlying URL. Salesforce, HubSpot, and Outlook's mail-merge layers re-write user-typed URLs into tracking redirects. Gmail's classifier reads "click here to apply" linked to a long opaque tracking URL as a phishing tell. (Even though it is just analytics, it visually looks like a credential-harvest redirect.)

5. DKIM was 1024-bit, weakening every other trust signal. When DKIM is strong and DMARC is enforced and the sending domain has a long reputation, Gmail will swallow a moderate-risk body. With weak DKIM, the body has to be cleaner than usual to pass.

The specific Gmail user-facing warning ("This message might be dangerous. It contains a suspicious link that was used to steal people's personal information") is sourced from Safe Browsing's URL blocklist. One of the URLs in the message is on that list. Without seeing the message source headers, the most likely candidate is either a tracking-redirect URL from the sending platform or a third-party shortened URL. Identifying which link will require running Gmail's "Show Original" on a copy of the message and inspecting the URLs against the Safe Browsing API at https://transparencyreport.google.com/safe-browsing/search.

3. Content patterns that compound the risk

Looking at the email as a whole, three editorial choices are correctable without changing the substance:

1. Move attachments into a hosted resource page on brothersredevelopment.org. Instead of attaching 11 PDFs, host them at e.g. /resources/eviction-toolkit/ and send a single link. This eliminates the bulk-attachment signal and gives you analytics on which resources are read.

2. Standardize on one outbound tool with a dedicated subdomain. If marketing emails ship from a dedicated subdomain (e.g., mail.brothersredevelopment.org or connect.brothersredevelopment.org) with its own DKIM + SPF, transactional emails from @brothersredevelopment.org retain their reputation when bulk-mail campaigns have a bad day. Today, every type of email is mixed into the same reputation bucket.

3. Plain-text accompaniment. Multipart emails that include both an HTML version and a clean plain-text version score better than HTML-only. Microsoft 365 generates both automatically when composed in Outlook; mail-merge tools often do not.

4. Sender reputation — what to check next

The following tools will give you a current snapshot of how the global ecosystem rates your sender reputation. Each is free and takes under five minutes:

Tool	URL	What it shows
Google Postmaster Tools	postmaster.google.com	Gmail-specific reputation, spam rate, authentication pass rate. Requires DNS TXT verification.
Microsoft SNDS	sendersupport.olc.protection.outlook.com/snds/	Outlook.com reputation for your sending IPs.
MXToolbox Blacklist Check	mxtoolbox.com/blacklists.aspx	Whether your IPs or domain are on any of 80+ public blocklists.
Cisco Talos	talosintelligence.com	Sender reputation (good / neutral / poor).
DMARC Analyzer (Postmark)	dmarc.postmarkapp.com	Replaces rmtt.com routing with a readable dashboard.
Mail-Tester	mail-tester.com	Send one email to a test address; receive a 1-10 score with detailed reasoning.

I recommend running Mail-Tester first because it gives you a single integrated score in five minutes and tells you whether the problem is DNS-side, content-side, or both. If the score is below 7, the next stop is Google Postmaster Tools.

5. Comparison — what your peers are doing

For reference, the same DNS queries against five Colorado nonprofit peers:

Org	SPF	DMARC	DKIM platform
Mercy Housing	Multi-include via Outlook	`p=quarantine; sp=reject; adkim=s; aspf=s` (strict alignment)	Outlook (rotated, modern key)
Colorado Coalition for the Homeless	Multi-include via Outlook	`p=reject; sp=reject; rua=Cloudflare+self`	Outlook
Colorado Bar Association	Outlook + Trailblz	`p=quarantine; rua=Cloudflare`	Outlook
VOA Colorado	EasyDMARC managed + Robly	EasyDMARC managed	Managed service
Bayaud Enterprises	Outlook + Proofpoint	No DMARC record at all	Outlook
Colorado Housing Connects (your sister site)	Google Workspace only	No DMARC record at all	Google
CED Project (the partner you refer to)	Google + HubSpot	`p=quarantine` with Cloudflare reporting	Google

Takeaways for Brothers Redevelopment:

Your `p=reject` policy is more aggressive than most peers, which is good once authentication is solid but actively harmful while DKIM is weak. With a stale 1024-bit DKIM, marginal mail (legitimate but slightly off) gets rejected outright rather than going to spam where you might still recover it.
Strict alignment (`adkim=s; aspf=s`) like Mercy Housing uses is the gold standard. You are at relaxed alignment, which is fine, but pairing relaxed alignment with `p=reject` and weak DKIM is the riskiest configuration on this table.
Coloradohousingconnects.org has no DMARC record at all. That is the opposite problem and needs to be fixed in its own right (Section 8).

6. Verdict on the 5/21 incident

The email that reached Paul Dolphin's spam folder on 2026-05-21 from dmiller@brothersredevelopment.org had:

Valid SPF (passed)
Valid DKIM (passed cryptographically, but the signature is from a weak 9-year-old key)
Valid DMARC (aligned to `p=reject`)
An 11-attachment payload
Multiple body URLs to external domains, at least one of which is on Google Safe Browsing's caution list

The phishing warning was triggered by the URL component, not by the authentication state. But the probability of Gmail surfacing the warning was elevated by the weak DKIM, the bulk attachments, and the multi-link body. A message with the same content sent from a domain with rotated 2048-bit DKIM and a dedicated bulk-mail subdomain would have been substantially more likely to reach the inbox.

This pattern affects everyone Brothers Redevelopment serves who receives email through Gmail. Gmail handles roughly 30% of consumer mailboxes in the US (53% if you include Workspace customers using @yourdomain addresses backed by Google). For a Denver nonprofit whose audience is in housing crisis, the loss of even 10% of those messages to spam is a measurable harm.

7. Fix sequence — in priority order

Priority 1 (do this week)

1. Rotate DKIM in Microsoft 365 to a fresh 2048-bit key. Exchange Admin Center → Mail Flow → DKIM → select brothersredevelopment.org → Rotate DKIM keys. Microsoft does this in-place; no email interruption. Time: 5 minutes plus 48-hour DNS propagation grace period.

2. Replace the dmarc@rmtt.com rua/ruf targets with either an internal mailbox (dmarc-reports@brothersredevelopment.org) or, preferably, a managed service like Postmark DMARC (free up to 10k emails/day) or Valimail Monitor (free tier). This restores visibility into authentication failures within 24 hours of switching.

3. Audit the SPF chain. Remove ip4:67.222.31.236 (shared hosting IP) unless you can confirm an active sender uses it. Remove secureserver.net if GoDaddy mail is no longer in use. Tighten ~all to -all only after you have verified all senders pass.

Priority 2 (do this month)

4. Move bulk outreach (newsletters, mass case-manager updates) to a dedicated subdomain with its own DKIM and SPF. Suggested subdomain: connect.brothersredevelopment.org. Use Mailchimp, Constant Contact, or HubSpot. Cost: $0 to $30/mo at your volume. Benefit: when one bulk campaign has a deliverability problem, transactional email from staff inboxes is unaffected.

5. Set up Google Postmaster Tools and Microsoft SNDS monitoring. Both are free. Both will give you week-over-week deliverability trend lines so you can verify that the fixes are working.

6. Move the 11-attachment package into a hosted resource page on brothersredevelopment.org. A single linked toolkit reads as a legitimate resource hub; 11 attachments reads as bulk-attachment phishing.

Priority 3 (do this quarter)

7. Add BIMI (Brand Indicators for Message Identification) once DMARC is at p=reject and DKIM is rotated. BIMI displays your logo next to your sender name in Gmail, Yahoo, and Apple Mail. This is the single highest-trust visual signal available to email senders today. Requires a Verified Mark Certificate (~$1,500/year from Entrust or DigiCert, but the trust uplift is substantial).

8. Document an annual DKIM rotation cadence so the 2026 rotation does not become the 2035 problem.

8. Sister-domain note: coloradohousingconnects.org

The sister site shares the brand and audience but has its own DNS, and it is currently in worse shape than the parent:

No DMARC record published. Without DMARC, you have no visibility into spoofing or authentication failures, and Gmail/Yahoo bulk-sender guidance penalizes domains without DMARC since February 2024.
SPF is minimal (`include:_spf.google.com` only). Adequate if all mail is Google Workspace, but unverified.
No DKIM selectors visible at `default._domainkey` or `google._domainkey`. Either DKIM is not enabled in the Workspace admin console or it is configured on a non-default selector.

If @coloradohousingconnects.org mailboxes are used to send email (and they should be, given it is a public-facing helpline), this is a comparable spam-flag risk to the parent domain.

The fixes:

Publish a DMARC record at `p=none` for 30 days, monitor the reports, then escalate to `p=quarantine` and eventually `p=reject`.
Enable DKIM in the Google Workspace admin console (Apps → Google Workspace → Gmail → Authenticate Email).
Add an `_spf.google.com` and any necessary marketing-tool includes; terminate `-all`.

9. Operational note on this audit

These findings are based on public DNS lookups, public WHOIS data, and the open Yoast SEO XML sitemap. No private data, no credentials, no surveillance of internal Brothers Redevelopment systems. Everything here can be independently verified in five minutes with dig on any internet-connected machine. The audit is offered as a peer professional courtesy, not as a sales motion. Brothers Redevelopment is welcome to act on the findings independently; if a conversation is useful at any point, that is offered separately.

Prepared by Paul Dolphin, Managing Partner, AXIA Capital and Homestead Capital Partners. 30 years in financial services. 5559 S Sossaman Rd Bldg 1 Ste 101, Mesa, AZ 85212. paul@pauldolphin.com.