The Spoof Your Paid Gateway Will Not Stop

In our sweep of 405 credit union domains, 215 route their mail through a named security gateway. Fifty-two of those still publish a DMARC policy of p=none. They pay five figures a year for email security and leave the one setting that blocks a forgery of their own name switched off.

That is not a tooling gap. It is a misunderstanding about what the tool does. The cleanest way to explain it is to walk through the attack. What follows is a composite, built from incidents we have worked and the public record of the sweep. No real institution is described.

The setup

A credit union with about 30,000 members. Mail on Microsoft 365, front-ended by a gateway they chose carefully three years ago. In 2022 the IT manager published a DMARC record at p=none "to start collecting reports before we tighten it." The reports go to a shared mailbox. The IT manager left in 2024. Nobody has opened that mailbox since.

The domain check shows all of this to anyone who looks: SPF pass, DKIM pass, DMARC fail with p=none, a gateway named in the MX record. An attacker does not need to break in to learn it. It is a DNS query.

Tuesday, 6:40 a.m.: the attacker reads the same record we did

The attacker runs a list of credit union domains through a lookup much like ours and filters for one thing: p=none. The list is short and it is gold. Each name on it is a domain they can send as, to anyone, and have it delivered.

They pick this one. The website gives them the logo, the color scheme, the CEO's name, and the online-banking URL. They register a look-alike domain for the landing page. Total prep: under an hour.

7:15 a.m.: the message to the members

Twelve thousand messages go out. The From address is the credit union's real domain, not a look-alike. The display name is the credit union. The subject line says online-banking access will be suspended unless the member confirms her identity by end of day. The link goes to the look-alike domain, which shows a perfect copy of the login page.

Here is where the gateway question gets answered. The gateway sits in front of the credit union's inbox. It inspects mail arriving at the credit union. These messages are not arriving at the credit union. They are arriving at Gmail, Outlook.com, Yahoo, and a few hundred small ISPs. Those providers do exactly what the world's mail system is designed to do: they look up the credit union's DMARC policy to ask what to do with a message that claims to be from it. The policy says none. So they deliver it.

Gmail may show a small "be careful with this message" banner on some of them. Most members are reading on a phone. They see their credit union's name, their credit union's logo, and a deadline.

9:30 a.m.: the message to accounting

The second wave is smaller and worth more. Four messages, sent to the credit union's own accounts-payable staff, from the CEO's real address, asking for a vendor's updated remittance details to be applied to Friday's payment run.

These do pass through the gateway. Whether the gateway blocks them depends on one setting: does it enforce the credit union's own DMARC policy on inbound mail claiming to be the credit union? Most gateways can. Most are configured to honor the published policy. The published policy says none. Two of the four messages land.

By noon

About 300 members have entered their online-banking credentials on the look-alike page. The attacker's script tries each one against the real site in real time and prompts for the one-time code, which the member types in because the page asked for it. Roughly 40 accounts are open. Transfers start.

The call center sees the first confused member at 10:10. The fraud team sees the first disputed transfer at 11:45. Nobody connects the two until early afternoon, because the email that started it never touched the credit union's mail system. It is not in the gateway logs. There is nothing to search.

What it costs

Under Regulation E, unauthorized electronic transfers are largely the institution's loss, not the member's. Forty accounts at a few thousand dollars each is a six-figure Tuesday before the vendor payment is counted. If Friday's run goes to the attacker's account, add whatever that invoice was.

Then the costs that do not fit on one line. Card reissues. Password resets across 30,000 members. The 72-hour reportability decision, which now has to be made about an incident with no internal artifacts. The examiner's follow-up question about why the DMARC policy was still at none in a program that had been "collecting reports" for four years. And the member who moves her accounts to the bank down the street, which never sent her a scam email, because its policy says reject.

Why the gateway did not save them

Because it was never designed to. Think of the gateway as the guard at your door. It inspects what comes in. DMARC is different. It is a notice you publish to every other building in the world saying "if someone shows up claiming to be from us and cannot prove it, turn them away." You can have the best guard on the block and still leave that notice reading "let them in, just tell me later."

The reflexive fix, when a board hears this, is to ask the gateway vendor for a quote on a bigger package. The vendor will happily sell one. It will not change what Gmail does with a forged message, because Gmail does not ask your vendor. It asks your DNS.

The fix that works

It is a change ticket, not a purchase order. It takes two to six weeks, mostly waiting.

1. Open the reports mailbox. DMARC aggregate reports list every source sending as your domain. Two to four weeks of them tells you exactly who legitimately sends as you: the core, the statement vendor, the marketing platform, HR, the ticketing system. Free tools turn the XML into a table.
2. Align every legitimate sender. Each one needs to be in your SPF record and to sign with DKIM using your domain, not the vendor's. This is the step most people skip, and it is why they are afraid to enforce.
3. Enforce gradually. Move to p=quarantine; pct=25. Watch the reports for a week. Raise it to 100. Then p=reject. Add sp=reject so a subdomain nobody uses cannot be forged either.
4. Tell the gateway to honor it. Now the inbound guard has a policy to enforce, and the CEO-spoof to accounting bounces.
5. Put the mailbox on a calendar. Someone reads the reports monthly. When a new vendor starts sending as you, you find out from the report, not from a bounce.

A credit union at reject changes the attacker's math completely. The 12,000 messages to members get dropped at Gmail and Outlook before anyone sees them. The four messages to accounting bounce off the gateway. The attacker moves on to the next domain on the list that still says none.

Find out which list you are on

Run the Domain Security Check on your domain. The DMARC row tells you your policy in one line. If it says none, you now know what that means on a Tuesday. If you want every other row explained the same way, the full breakdown covers all nine findings from the sweep, with the fix for each.

And if you would like a second set of eyes on the enforcement plan before you flip it, we are happy to walk through it. No pitch required.