How to stop spam for your whole domain, not one inbox at a time

Spam reaches a business through one door: the mail server that accepts mail for your domain. Where you put the filter relative to that door decides how much it can do. This guide compares the four approaches people usually try, and shows how they fit together.

What does "MX-level filtering" mean?

Every domain that receives email publishes MX records. A sending server looks them up and delivers to the listed host with the lowest preference number (RFC 5321, section 5.1). With MX-level filtering, those records point to a filtering service instead of your mail server. The service accepts each message, checks it, and delivers only clean mail to Microsoft 365, Google Workspace, cPanel or Exchange.

Because it sits in front of the server, it covers every mailbox and every alias on the domain, with one policy, without installing anything on users' devices.

How do the four approaches compare?

Why aren't inbox rules enough?

Client rules run after the message is already in the mailbox. By then, links can be clicked, attachments opened on mobile, and the message has used storage and attention. Rules also live with each user, so ten users means ten different, partly broken rule sets. They're good for sorting newsletters, not for security.

Why doesn't blocking senders work for long?

Blocklists of senders work on the address in the message. Spammers change addresses and domains for each campaign, and they often forge real addresses. Blocking a forged address hurts the real owner and does nothing about the next campaign. Use block lists for a persistent sender who ignores unsubscribe requests, not as a spam strategy.

A stronger version is an approved-sender list that requires sender verification: the address is only trusted if the message also passes authentication. That stops a spammer from riding on a partner's address.

Where do SPF, DKIM and DMARC fit?

These are records you publish for your own domain:

• SPF lists the servers allowed to send mail using your domain in the envelope (RFC 7208).
• DKIM signs your outgoing mail so receivers can verify it wasn't altered.
• DMARC tells receivers what to do when mail claiming your From domain fails those checks. RFC 7489 described it originally; it was replaced in 2026 by RFC 9989, which keeps the v=DMARC1 record format.

They protect your customers and partners from mail that impersonates you. They don't filter what arrives in your own inboxes. An inbound filter, on the other hand, checks the SPF, DKIM and DMARC of every sender that writes to you. You want both.

You can check your records with the SPF Checker, DMARC Checker and DKIM Checker. A DKIM selector we can't find is unknown, not broken: selectors aren't listed publicly, so we can only check the ones we know or you tell us.

What does an MX-level filter check that the others can't?

Because it sees every message before delivery, a domain-wide filter can act on things a mailbox rule never sees:

• The connection itself. The sending IP, its reputation, and whether it behaves like a real mail server.
• Authentication of the sender. SPF, DKIM and DMARC results for the claimed sender, so mail forged to look like a partner can be held.
• Attachments before anyone opens them. Virus and malware scanning, plus rules by file type, such as blocking Office files with macros.
• Policy for the whole company. Geographic rules, attachment rules and custom domain rules apply to every mailbox and alias at once.
• Availability. If your mail server is down, the filter can hold mail and deliver it later, instead of senders getting bounces.

It also gives you one place to answer "did we receive this message?" Message history at the filter shows what arrived, what was held and why.

Who should own each layer?

In a small business, one person often owns all of this. It still helps to separate the layers:

How do you set up domain-wide filtering?

1. Check your current state. Run the Email Health Check to see your MX, SPF and DMARC today.
2. Add the domain at the filtering service and set your mail server as the delivery destination.
3. Prepare the mail server. Tell it the filter is a trusted gateway: a Partner inbound connector with Enhanced Filtering in Microsoft 365, the Inbound gateway setting in Google Workspace, or trusted IPs in cPanel/WHM. See the platform pages.
4. Change MX using a short TTL. Our MX cutover checklist covers the details.
5. Close the direct route so spammers can't skip MX and deliver to your server. See Block direct-to-tenant bypass.
6. Set up quarantine digests so users can see and release anything held.
7. Keep the built-in filter on as a second layer.

What are the risks and how do you roll back?

• False positives. Any filter can hold a good message. Quarantine digests and admin release are the safety net. Start with a regular digest so users learn the routine.
• Bypass. An MX change alone doesn't stop direct delivery to Microsoft 365, Google or your server. Lock the server down after the MX change.
• Double filtering. If your mail server doesn't know about the gateway, it may treat all mail as coming from the gateway's IP and mark good mail as spam. Use the platform's gateway settings rather than spam-bypass rules.
• Rollback. Remove any lockdown first, point MX back to your mail server, and keep the filtering service active until the old TTL has expired.

If your business has several domains, roll out one at a time; our multi-domain email security guide covers the inventory and staging.

How iBlockSpam helps

iBlockSpam is an MX-level filter for business domains. It checks inbound mail for spam, viruses, malware, phishing and spoofing before it reaches your server, and its approved and blocked sender lists can require sender verification. Each user gets a personal quarantine with scheduled digests (hourly, daily, a chosen weekday or custom), and admins get a shared domain quarantine. Pricing is per domain with unlimited mailboxes; 100,000 inbound messages per month are included. iBlockSpam doesn't publish SPF, DKIM or DMARC for you. Our free Check tools show where those records stand, and DMARC monitoring is included with every plan.

Next steps

1. See where your mail goes today with the free Email Health Check.
2. Compare the costs with per-domain vs per-user pricing.
3. If you add a gateway, plan the MX change with changing MX records without losing email.

You can see what domain-wide filtering looks like from the admin side in the iBlockSpam portal demo, with sample data for three domains.

Read our other guides on choosing a spam filter.