Are Shared Mailboxes Safe for Payment Approvals?

Are Shared Mailboxes a BEC Risk for Payment Approvals?

Yes. A shared mailbox is a single email address used by multiple people. That convenience is exactly the problem when payment approvals are involved.

When a payment request lands in a shared mailbox, anyone with access can approve it. There is no record of who did the approving. There is no individual accountability. And that anonymity is what business email compromise (BEC) attackers are counting on.

DMARC monitoring can detect when someone tries to spoof your domain or a vendor's domain to target your AP team. But the structural problem that makes shared mailboxes dangerous goes deeper than email authentication alone.

If you run an accounts payable team on shared mailboxes, you are running a workflow where a convincing email and a shared inbox is all that stands between your organisation and a fraudulent payment. Here is what the risk actually looks like and which controls make a difference.

The Accountability Gap: Why Shared Mailboxes Break Payment Security

Shared mailboxes were built for collaboration. Multiple team members need access to the same inbox, so we give them all the credentials. For general enquiries, this works fine. For payment approvals, it creates a serious problem.

The issue is not that your team is careless. The issue is structural: when a payment request comes in and gets approved from a shared mailbox, there is no audit trail of which person reviewed and authorised it. If someone approves a fraudulent request, the system cannot tell you who did it.

In practice this means:

A requests payment to vendor X

B approves payment to vendor X

Both A and B had access to the same mailbox

There is no record of who actually clicked approve

This is not a hypothetical. BEC attackers specifically research which companies use shared AP mailboxes, then craft emails that look like internal payment requests sent to that shared inbox. Because the inbox is shared, the attacker does not need to compromise a specific individual's account. They just need to send a convincing message.

How Attackers Exploit Shared Mailbox Anonymity

A BEC attack against a shared AP mailbox typically follows this pattern:

1. Reconnaissance. The attacker finds your company on LinkedIn, your vendor portal, or your careers page. They identify who handles payments, what your vendor relationships look like, and the format of your invoices.

2. They spoof the vendor address. Using the real vendor name and a lookalike domain, they send a payment change request to your shared AP mailbox: "Please update our banking details for the next payment."

3. The shared mailbox makes verification almost impossible. Your AP clerk receives the email, thinks a colleague may have already verified it, and processes the change. Nobody checks because nobody is accountable for checking.

4. The payment goes to the attacker's account. By the time the real vendor flags the missed payment, the attacker is gone.

This attack works without any malware, without compromising a user account, and without touching your email server. It exploits the human and structural gap that shared mailboxes create.

BEC consistently ranks among the highest-loss crime types reported to law enforcement. The structural features of shared mailboxes - no individual accountability, no audit trail, shared access - make them a natural target for this attack type.

Where Email Authentication Fits in the Shared Mailbox Threat Model

Email authentication does not solve the shared mailbox problem on its own. But it addresses one specific part of the attack chain: the spoofed vendor email.

If your domains have weak or no DMARC, an attacker can send email that appears to come from your vendor's domain. Their message might pass SPF because it originates from an unrestricted server, or pass DKIM because it was signed on their own infrastructure.

With DMARC p=reject in place, that spoofed vendor email fails at the DMARC alignment check, regardless of whether it passes SPF or DKIM on its own server. The receiving mail system rejects it before it reaches your AP team.

Here is the breakdown:

SPF alone: Only checks if the sending server is authorised for the envelope-from domain. An attacker sending from their own server can pass SPF if their server is not on a blocklist.

DKIM alone: Checks that the email was cryptographically signed by the legitimate domain's mail server. The attacker cannot fake this if DKIM keys are not compromised.

DMARC alignment: The critical layer. DMARC adds an alignment check to SPF and DKIM. For an email to pass DMARC, the domain in the From: header must align with the domain that passed SPF or DKIM. An attacker who spoofs vendor.com in the From: header but sends from attacker.server.com fails DMARC alignment even if their SPF is technically valid.

For shared mailboxes, DMARC helps in two ways:

It reduces spoofed emails reaching your team in the first place

DMARC failure reports alert your security team when spoofing attempts occur on domains related to your payment workflows

DMARC does not prevent an attacker who has access to a legitimate mailbox account from sending from that account. That requires MFA, access controls, and user training.

How to Make Shared Mailbox Payment Approvals Safer

Technical controls and process controls work together. Here is what actually reduces risk:

1. Require MFA for all shared mailbox access
Every person with access to the shared AP mailbox should have a dedicated individual account with MFA enabled, then be granted access to the shared mailbox through that account. This separates authentication from the shared resource.

2. Implement a secondary verification channel for payment changes
Any request to change payment details, bank account numbers, or vendor contact information should require verification through a separate channel. Call the vendor on a known-good phone number from your own records, not from the email signature or the request itself.

3. Separate payment processing from shared mailbox access
Use dedicated individual accounts for anyone who initiates or approves payments. The shared mailbox handles incoming mail; individual accounts handle processing and approval workflows.

4. Enforce DMARC p=reject on your domains
This prevents attackers from sending email that appears to come from your domain, including spoofed vendor addresses used in BEC attacks against your team.

5. Monitor DMARC failure reports
When someone tries to send email that fails DMARC alignment, you should know about it. DMARC failure reports (RUA reports) sent to your domain contain details about which emails failed and why. Security teams can use this signal to catch spoofing attempts targeting payment-related email addresses.

DMARCFlow processes these failure reports and surfaces the ones that matter. Rather than manually reviewing raw DMARC failure report data, security teams can use DMARCFlow to monitor for suspicious patterns, such as a spike in failures on domains used in your payment workflows.

6. Run BEC-specific simulation training for AP teams
Generic phishing training misses the shared mailbox scenario. BEC training should specifically cover: how to verify a payment request, how to identify a spoofed vendor email, and what the approval chain looks like for your organisation.

7. Require a named individual approver, not a shared inbox
Every payment approval should require a named individual account and a recorded approver. If the workflow cannot support this without a major systems overhaul, implement a ticketing or approval system that attaches a named user to each request.

The Bottom Line

Shared mailboxes are convenient. They are also structurally incompatible with secure payment approvals. The anonymity they create - no named approver, no individual accountability, no audit trail - is exactly what makes them attractive to BEC attackers.

Email authentication alone will not fix this. DMARC p=reject helps prevent spoofed vendor emails from reaching your team. MFA helps prevent account compromise. But the core problem is process: if your payment approval workflow relies on a shared inbox and the honour system, you have a BEC risk that no technical control will fully solve.

The practical starting points: put named individuals in the approval chain, add a secondary verification step for any payment change, and make sure your domains are protected by DMARC p=reject.

---

FAQ

Can DMARC prevent all BEC attacks?
No. DMARC addresses email spoofing, which is one attack vector in BEC. DMARC cannot prevent an attacker who has access to a legitimate mailbox from sending email, nor can it detect a convincing spear-phishing email sent from a legitimate external account.

Is it ever safe to use a shared mailbox for payment approvals?
It is never fully safe. The accountability gap is structural. If you must use a shared mailbox for receiving requests, separate the receiving function from the approval function. Incoming payment emails go to the shared mailbox. Approval and processing require a named individual account.

Does DMARC affect legitimate vendor emails?
If your vendors have properly configured their email authentication (SPF, DKIM, DMARC), their legitimate emails will pass DMARC checks at your mail system. DMARC p=reject only blocks email that fails authentication and alignment - not email that is legitimately sent from properly configured vendor servers.

What is the biggest risk with shared mailboxes in payment workflows?
The biggest risk is that shared mailbox access removes individual accountability. When a fraudulent payment request is approved from a shared mailbox, there is no way to determine which person in the group approved it. This makes verification, auditing, and incident response significantly harder.

Are Shared Mailboxes Safe for Payment Approvals? The BEC Risk No One Talks About