Disposable Email Blocker for WooCommerce - Block Fake and Temporary Emails at Checkout

No. The free version performs all checks locally on your own server using bundled lists. Nothing is sent to any external service. There is no telemetry, no analytics and no licence check in the free version. The only outbound request the plugin can make is to the Stackedboost API, and only if you deliberately enter a Pro licence key to activate it.

Yes. Email Guard protects the WooCommerce checkout and account registration. It does not touch WordPress core registration or comments, so if you want to block disposable email on a site without a shop, this is not the plugin for it.

Yes. Email Guard validates both the classic (shortcode) checkout and the newer Cart/Checkout blocks (Store API). On the block checkout, a blocked email stops the order when "Place order" is clicked and the message appears in the block's own error state. This is worth checking on any email plugin you evaluate. A plugin that only hooks the classic checkout does nothing at all on a block-based store, and it fails silently, which is the worst way to fail.

The bundled list contains disposable email and temporary email providers only, and the typo map covers near-certain mistakes. If a real customer is ever refused anyway, add their domain to the allow list on the settings screen: it overrules everything, including the bundled list, so you never have to switch protection off to let one person through.

Add their domain to "Always allow these domains" on the settings screen. The allow list is checked first, before every other rule, so the customer is through immediately and permanently. If you want to understand why it happened first, paste the address into the tester on the same screen. It will tell you which of the four checks refused it, so you know whether it was the bundled list, your own blocklist or the typo map.

Yes. An address at mail.example.com is refused if example.com is on any list, which is how throwaway email providers usually hand out addresses. The same applies to your custom blocklist: adding competitor.com also covers orders.competitor.com.

Yes. Put their domain in the custom blocklist, one per line. It is checked on every order, it covers their subdomains automatically, and it takes precedence over everything except your allow list.

In practice they are the same thing under different names, and this plugin treats them identically. A disposable email address, a temporary email address and a throwaway email address all describe an inbox that is meant to be abandoned: usually free, usually requiring no registration, and usually dead within minutes or hours. You will also see "temp mail", which is the same idea and is the brand name of several of the larger providers.

Neither is blocked, and neither should be. A catch-all domain accepts mail to any address at that domain. Plenty of legitimate small businesses run one. Blocking catch-alls would refuse real customers in volume. Plus addressing (name+shop@gmail.com) is a normal, supported feature of the major providers, used by people who want to filter their own mail. It is not disposable, and refusing it annoys exactly the sort of organised customer you want.

The list is bundled with the plugin, so it updates when the plugin updates. It went from about 50 domains to over 8,200 in version 1.2.0. A bundled list is a deliberate trade. It never phones home, never leaks a customer address, and works if your server has no outbound access, but it is a snapshot rather than a live feed. No blocklist is complete, and anyone who says otherwise is selling something: disposable providers register new domains constantly. If the tail of newly registered domains matters to your shop, that is what the DNS and MX checks in Pro are for.

Four common approaches, solving different problems. Regular expression format checks. Confirms an address looks like an address. WooCommerce already does this and it catches nothing that matters: x@mailinator.com is perfectly well formed. A bundled domain list, which is this plugin. Fast, private, free, works offline, no per-check cost, catches the providers used at volume. The trade is that it is a snapshot. Live DNS and MX lookups. Asks whether the domain can receive mail at all. Catches dead and misconfigured domains no list can know about, at the cost of a network round trip. This is what Pro adds. Third-party validation APIs. The most thorough and the most expensive in every sense: per-check fees, a network dependency inside checkout, and you are sending customer addresses to another company. That privacy decision should be yours, not a default someone picked for you. Neither this plugin nor Pro is a fraud system. A shop with real fraud exposure needs more than email validation.

No, and this plugin will never do it for you. You will see this advised for B2B shops, on the theory that a real business has its own domain. An enormous number of legitimate sole traders, contractors and small businesses buy using a free address, and plenty of large ones do too. Refusing free providers does not filter fraud. It filters customers, silently, at the exact moment they were about to pay you. If your business genuinely cannot serve consumer addresses, the custom blocklist will let you do it. That is your call to make deliberately, not a default.

A steady trickle of blocks. The normal, healthy state. Nothing to act on. One domain dominating. You are being probed rather than casually shopped. Check whether it lines up with a discount code being live. A spike from many domains at once. Somebody working through a list, usually against a first-order discount. The plugin is already refusing them, so the decision is about the offer, not the plugin. Typo corrections climbing. Often the most valuable number on the screen. Every typo caught is an order that would otherwise have completed with an address that silently bounces. Zero blocks after several weeks. Not a fault. Your traffic is clean. Confirm with the tester, then stop thinking about it.

Everything is on one screen at WooCommerce > Email Guard. Block risky emails at checkout. The master switch. Off means every check is skipped and nothing is refused or recorded. Suggest corrections for typos. On, a likely typo stops checkout and shows the corrected address. Off, typos are ignored and only disposable domains and your own blocklist are enforced. Custom blocked domains. One per line, or comma separated. Pasting a whole address works; the plugin takes the part after the @. Subdomains are covered automatically. Always allow these domains. Same format. Checked before every other rule, including the bundled list. Your override and your safety valve. The tester. Type any address and see the verdict and the reason. It runs the same code path as checkout and does not touch your counters.

Probably not. Check that "Block risky emails at checkout" is on, then use the tester with test@mailinator.com. If the tester refuses it, the plugin is working and your traffic is simply clean.

Confirm it is the WooCommerce Cart/Checkout block and not a third-party checkout that bypasses the Store API. Email Guard validates the classic checkout and the Store API. A checkout that goes around both cannot be validated by any plugin hooking WooCommerce.

It sits under WooCommerce when WooCommerce is active, and under Settings when it is not. There is also a Settings link on the plugin's own row in the Plugins screen.

Counters are written only when a block actually fires, so a quiet week writes nothing. The daily series keeps 30 days and older days fall off by design.

No measurable amount. The checks are hash lookups against an in-memory array, and the domain list is only read on requests that actually validate an address. Requests that never reach checkout never pay for it.

Yes. The Store API integration is resolved at runtime and the plugin falls back cleanly if the block checkout classes are not present, so it works on stores still using the classic checkout only.

Yes. They are separate switches on the settings screen. With typo suggestions off, a mistyped address no longer stops checkout, and only disposable domains and your own blocklist are enforced.

For a disposable address: "Disposable email addresses are not accepted. Please use a permanent email." For a likely typo: "Did you mean bob@gmail.com? Please check your email address." For a domain on your own blocklist: "This email domain is not allowed for orders." All three are translatable through the plugin's text domain.

Yes. All merchant-facing and shopper-facing strings use the stackedboost-email-guard text domain and the plugin ships with no hard-coded English in its output. Translations submitted through translate.wordpress.org are picked up automatically.

No. The local part of the address is discarded before anything is recorded. The counters hold domains only, plus how many times each was refused. See the privacy section above for the full list of what is and is not stored.

The free version stores no personal data about your customers, makes no outbound request, and sets no cookies, so it does not add a processor to your stack or give you anything new to disclose. Domain-level counters on your own server are not personal data. That is a description of what the plugin does, not legal advice. Your own obligations depend on everything else your site does.

Everything the plugin created is removed: your settings, the local counters, the review-prompt flag and the licence record. Nothing is left behind in your database.

No. The free version never contacts any server: there is no licence check, no telemetry, and no upsell nag beyond the settings screen. The plugin only makes an outbound request if you deliberately activate a Pro licence key, and then only to the Stackedboost API.

Checks that cannot be done from a bundled file: a live DNS and MX lookup to see whether the domain can actually receive mail, risk scoring on the finished order, order tagging and alerts. The disposable blocking in the free version is not limited in any way, and Pro does not make it bigger. Pro is optional and sold separately at https://stackedboost.com/woocommerce/stackedboost-email-guard/.

The site quietly returns to the free version: local blocking, typo suggestions and your custom blocklist keep working exactly as before. Nothing is disabled and no data is removed.

Not yet. The plugin exposes no public actions or filters at this time, and it would be dishonest to list any it does not have. If you need a specific hook, say to add domains programmatically or to change a message, open a thread on the support forum and describe the use case. That is the fastest way to get one added.

Use the tester on the settings screen. Paste the address and it will tell you which check refused it and why, using the same code path the checkout uses. From there it is either a domain you want to allow, in which case add it to the allow list, or a domain that is genuinely on the disposable list.

Yes. Each site keeps its own settings, lists and counters. Network activation works and every site is configured independently.

Yes, completely. That is one of the reasons the domain list is bundled rather than fetched. The free version never needs outbound access for any part of its job. Locked-down hosting, a firewalled staging environment or a server with no route to the internet all work identically.

No. Every check happens inline during the request that submits the address. There is no scheduled task, no queue and no background processing to go wrong.

It should not. It adds validation errors through WooCommerce's own validation hooks rather than replacing or short-circuiting anything, so other plugins hooking the same points continue to run. If two plugins both refuse an address, the shopper sees both messages.

Not as a passive monitoring mode, no. What you can do is use the tester to check any address you are curious about, including ones from past orders, and see exactly what checkout would have done with it. That gives you the same answer for the addresses you actually care about, without changing anything.

Open a thread on the support forum with the domain. False positives are treated as the higher priority of the two, because a wrongly refused address costs a real order.

Yes, with one habit: keep the allow list as your safety valve. Corporate domains are not on disposable lists, so in practice B2B stores see very few false positives. If one does happen, the allow list resolves it in seconds and permanently.