Disposable email detection policy: block, review, or allow by workflow

Key takeaways

• Use a different action for account recovery, trial signup, receipts, newsletters, and low-risk downloads.
• Disposable is a domain classification. A mailbox server can still accept mail while that inbox exists.
• Unknown, greylist, an unreachable mail server, a blocked check, and a system error are not disposable, and they are not invalid.
• Blocking can cut wasted onboarding mail and some support time. The same block can turn away a real evaluator. Keep those effects in separate columns.
• The risky summary mixes disposable with catch-all, role accounts, and mailbox full. Do not run this policy on that whole group.
• A check does not prove inbox control, consent, or inbox placement.

What a disposable result actually says

A mailbox is normally local-part@domain. RFC 5321 section 2.3.11 calls an address a string for a user or a place where mail is deposited, and it says the local-part is interpreted by the host in the domain, not by an intermediary. RFC 5322 section 3.4.1 defines an addr-spec the same way: a local string, an at-sign, and a domain. A disposable address can pass both tests. Syntax is not the problem. The question is whether you can still reach that domain later.

Acceptance is a different fact. RFC 5321 says an accepted RCPT returns 250 OK, and a recipient known not to be deliverable draws a reply such as 550. A 250 covers that transaction only. It does not say the inbox will exist next month, who owns it, or that you may keep writing. Temporary services often accept mail while the mailbox is alive, then disappear without a bounce. DNS does not sort this out either. RFC 1035 section 3.3.9 defines an MX as a preference plus an exchange host, and a disposable domain can publish ordinary MX records. RFC 7505 is the other statement: a null MX means the domain accepts no mail. "No mail service" and "short-lived inbox" are different findings.

MailCheckup checks in that order. Broken syntax is invalid, and a typo suggestion does not rewrite the submitted address. Disposable domain and role address (info@, support@) come next. They are classifications, not bad syntax. No mail server, or one you cannot reach, is inconclusive, not a confident invalid person. Then recipient acceptance: accept is deliverable, reject is undeliverable, accept-everything is catch-all, a full mailbox is mailbox full, and greylist, block, timeout, or no clear answer is unknown. Unknown is not invalid.

Deliverable means the server accepted the recipient during the check. It is not inbox placement, consent, or a person you should contact. A disposable flag neither creates nor cancels consent.

One credit, and the summary that causes bad blocks

A finished disposable result costs one credit. The same one-credit rule covers valid, deliverable, undeliverable, dead, invalid, catch-all, role account, and mailbox full. Unknown, retry later, greylisted, mail server unreachable, provider blocked, and system error are free. A hold on a check that never finished is released. Risky is only the group name for disposable, catch-all, role account, and mailbox full. It is not a second charge.

If you suppress every risky row, you also suppress catch-all domains, shared role addresses, and mailboxes that were full that day. A billing alias can be a role account. A company domain can be catch-all and still belong to a paying customer. Mailbox full can clear. None of those are this decision. Read the separate codes in the result codes and what they mean. Act on disposable when the question is a temporary inbox.

The disposable email detection page is the short definition. The flag is context. It does not prove abuse. Domain lists change. False positives are possible. No update frequency is published. This page does not stop at that definition. It assigns block, review, or allow to each workflow, and it shows a cost sketch you can redo with your own inputs.

Why one block fails

Recovery fails closed: the person cannot get back in. A trial wastes a workspace and a sequence. A refused receipt creates the support ticket. A newsletter may be mail they wanted on a side inbox. A download fails only if you then sequence the lead. One reject treats those as the same event. People use temporary inboxes for privacy and for tests. Fraud is the wrong default. When you truly need a lasting inbox, say so on the form. Do not call the flag a broken address.

Account recovery

Reset mail and new-login notices assume the mailbox opens when the event happens. A disposable inbox ends on a timer you do not control. The failure is a locked-out customer, or a secret sitting in a mailbox someone else may still hold.

Block it as the only recovery channel. If a durable address is already on file, send recovery there. If disposable is the only address, require a lasting one while they are signed in, before you store a payment method. No false-positive rate is published, so a person approves exceptions and records who did. The exception is that account, not a skip for every future signup. Blocking stops self-serve reset for someone who only has a temporary inbox. Offer a support path that does not email a secret to that address. Allowing it means the reset dies with the inbox.

Form copy: "Password reset needs an inbox you can open later. This address is classified as temporary. Add a lasting address while you are signed in."

The result is not proof of fraud. Pair it with a failed payment, a mismatch, or a report if you are making that call.

Trial signup

A dead inbox here costs a workspace and a sequence, which is why teams reach for a global block and then argue about conversion.

If the address is disposable, do not open the ongoing workspace until they give a lasting address or an approved exception. A tour can still run. Privacy-minded evaluators will hit this, including people whose real alias sits on a domain you have not separated from throwaway mail. Classifications change, and no false-positive rate is published. Blocking turns away people who might have paid. The sketch keeps that loss in its own column. Allowing it fills the CRM with rows nobody can reach.

Form copy: "Trial access needs an inbox you can still open next month. This domain is classified as temporary. Use a lasting address, or contact support if this is your real mailbox."

A quality check is not an ownership check. Where the trial becomes a billable account, confirm control with a link or another challenge you run. Email verification for SaaS applications makes that split: do not trap people on an uncertain result, and do not treat the check as proof they control the inbox.

If the check returns unknown, do not apply this block. Unknown is inconclusive. Turning a timeout into a rejection loses the signup. Let them continue, or retry, and keep that row out of the disposable action.

Receipts

A receipt or tax invoice is a record of a charge you already took. Send it to the address they gave you, including a disposable one. Refusing the send does not undo the payment.

Allow the message. Keep a copy in the product so a signed-in user can download it if the inbox disappears. A later lasting address can receive a duplicate. Do not hold the first copy. Review is the wrong tool for the send itself. It belongs on whether this inbox may be the only login. Blocking leaves the buyer without proof and makes disputes worse, to save a fraction of a cent. People also split receipt mail from newsletter mail on purpose. Store those as different roles. If you want a lasting address for renewals, ask in a second field. Do not fail the payment confirmation because that field is empty.

Newsletter and other lifecycle mail

A digest or a nurture sequence assumes the mailbox will last and that the person wants the stream. Disposable weakens the first point and does not settle the second. They may have opted in. They may have picked a temporary inbox so the opt-in would expire.

Do not add the address to the ongoing list. One confirmation is enough, then stop. If they can show a real opt-in and insist the domain is durable, use the same recorded exception as the trial. That exception is not a license for a cold sequence. Blocking costs you readers who wanted the letter off a primary inbox. Keep a web archive if the writing matters. Allowing it decays the list and raises the chance of unwanted-mail signals.

Google's email sender guidelines tell senders to authenticate, keep Postmaster Tools spam rates below 0.3%, and give marketing mail one-click unsubscribe plus a visible unsubscribe link. Above 5,000 messages a day to Gmail, that page adds further authentication rules. None of this defines a disposable class as a complaint, and blocking is not a substitute for unsubscribe. A flag on a second field does not revoke opt-in on a durable address. Verification is not consent.

Low-risk download

A checklist or a public PDF does little harm if the inbox dies. The file is the value. Allow the download, store the class on the lead, and do not start a long program. Show the class to anyone working leads by hand. Review only if the file is really a trial, a license, or customer data. Then use those policies and stop calling it low-risk. Blocking teaches you less and produces "you rejected a working address" tickets. Allowing it creates a lead that looks like pipeline. Fix that in the CRM. The waste is the sequence, not the file.

Quiet note, not an error: "We will send this file, and we will not add a temporary inbox to the ongoing list."

The five actions together

The same address can sit on more than one row. It can receive the receipt, fail as the only recovery address, and stay off the newsletter. Write three decisions. Do not store one blocked bit that follows the person forever.

Apply the code you received, not a wider one

1. Unknown, retry later, greylisted, mail server unreachable, provider blocked, or system error: stop. Do not map those onto disposable. On MailCheckup they cost nothing. Do not deny a receipt or a download because of them. For a trial, continue or retry.
2. Disposable: use the row for the workflow in front of you.
3. Role account, catch-all, or mailbox full: leave this policy. A role address can be the right receipt target. A catch-all domain can be a real company. A full mailbox can clear.
4. Deliverable: you still have not proved ownership or consent. Do not start a cold sequence on that basis.
5. Invalid syntax: correct it with the person. Do not replace the address with a suggestion they have not confirmed.

Store the code, the time, the workflow, and the action. Providers add and retire domains, so a result from six months ago is evidence about that day. A newer check is a new finished check. On MailCheckup it can spend another credit when the new result is chargeable. Rows you do not recheck stay. This page does not claim the new check erases the stored row. Keep both until a person changes the exception.

Do not automate from the risky summary, or you will block catch-all domains, role addresses, and full mailboxes with a recovery-grade rule. Use the disposable code. A finished list reports that count separately from catch-all, role account, and mailbox full. An email event exists per disposable address, and that finished result costs one credit. The count is not a fraud score. MailCheckup does not score leads.

An illustrative cost sketch

Every volume, share, hour, wage, message cost, and margin below is illustrative. Published MailCheckup plan and pack prices are the only dollar inputs taken from a price list. This is not a customer result.

• V is addresses you verify. c is cost per chargeable result. Do not invent a marginal c when the real purchase is a plan or a pack.
• r is the fraction removed because they classify as disposable. q is the fraction of those that would actually fail the workflow's purpose. s is the marginal cost of one message attempt.
• H is operating hours you treat as avoided. w is the loaded hourly cost.
• L and M stay outside the direct net. L is your assumed share of removed addresses that were legitimate users who would have continued. M is assumed gross margin for one of them, for one period, not a lifetime value.

Avoided send-attempt cost = V × r × m × s, with m equal to the number of messages. That is V × r × s if you fold the messages into s. Estimated avoided failures = V × r × q, a count, not a seat price. A seat price would double-count H. Operating savings = H × w. Direct net = send savings + operating savings − the verification invoice you actually believe.

q is not an SMTP failure rate. A temporary inbox can return 250 OK today. Here q means the purpose would have failed, for example onboarding mail never read. Setting q to 1 hides every legitimate user inside the removed set.

Base assumptions, next to the arithmetic

Workflow: trial signup plus four onboarding messages, one month. Assumptions:

• V = 8,000 addresses checked.
• 0.90 finish as a chargeable result. Chargeable count = 8,000 × 0.90 = 7,200. The other 800 are treated as unknown-class and add $0.
• r = 0.06. Removed = 8,000 × 0.06 = 480.
• q = 0.70. Avoided failures = 8,000 × 0.06 × 0.70 = 336.
• m = 4 and s = $0.001. Send savings = 480 × 4 × $0.001 = $1.92.
• H = 4 hours, only for tickets caused by mail to an inbox that died. Not fraud work, disputes, or engineering.
• w = $45. Operating savings = 4 × $45 = $180.
• L = 0.08. Legitimate blocks = 480 × 0.08 = 38.4.
• M = $20. Speculative lost margin = 38.4 × $20 = $768.

None of those rates were measured on a MailCheckup account. Replace them before finance sees a total.

Which invoice belongs in the net

You pay one credit for a finished disposable result, and one credit for every other chargeable result in the run. Unknown stays free. The check is not "480 disposable credits." Under the assumption above it is 7,200 credits.

Published prices, as inputs:

• Starter is $19 for 5,000 credits. It does not cover 7,200.
• Growth is $39 for 25,000 credits in the paid period. Monthly credits expire at the end of that period and do not roll over.
• A 10,000 credit pack is $25 and does not expire. It covers 7,200 and leaves 2,800.

Use one counterfactual:

1. The credits were already paid and would have gone unused. Invoice = $0. You still consume 7,200 credits. Direct net = $1.92 + $180 − $0 = $181.92.
2. This workload is why you buy a monthly plan. The smallest published plan that covers 7,200 credits is Growth at $39. Direct net = $1.92 + $180 − $39 = $142.92. Do not also subtract a per-credit rate.
3. This workload is why you buy a pack. The 10,000 pack is $25. Direct net = $1.92 + $180 − $25 = $156.92.

An allocated unit is not the invoice. Growth's list price per included credit is $39 / 25,000 = $0.00156. Across 7,200 credits that allocation is $0.00156 × 7,200 = $11.232. The pack unit is $25 / 10,000 = $0.0025, and $0.0025 × 7,200 = $18. Neither $11.23 nor $18 is the bill if you had to buy the plan or the pack for this work. Use the invoice. The published credit prices are the source. If a plan and a pack are both available, this sketch does not assume which credits are consumed first.

Do not add the three nets. Do not subtract the $768 from any of them. That margin was not observed. Folding it in would dress a guess as the same kind of figure as $1.92 of mail.

Low and high, still illustrative

Same V, same 7,200 credits, same $0.001 message cost, same $45 hour, same $20 margin. Only the shares and the hours change.

You still spend the same credits if you check every signup. The low column's modeled waste is $45.64 against $480 of guessed margin. The high column's modeled savings are $453.84 against $576 of guessed margin. Raising q while cutting L assumes the extra disposable addresses are mostly worthless. Defend those separately or do not quote the high column. If you must buy Growth, subtract $39: $6.64, $142.92, $414.84. If you must buy the pack, subtract $25: $20.64, $156.92, $428.84.

Download and recovery do not share the trial net

Same base V and r on a low-risk download, with m = 0 and H = 0.5. Operating savings = 0.5 × $45 = $22.50. Send savings = $0. If L = 0.25, you block 480 × 0.25 = 120 people to save that half hour. There is no M. A free file is not revenue. Allow the download.

Recovery is not four cheap messages. Illustrative only: one locked-out incident at 1.5 × $45 = $67.50, before the relationship. That is why recovery can be stricter than a download. Do not add the $67.50 to the trial net. Receipts fail the model the other way. Skipping one message at the base s saves a tenth of a cent and costs the buyer their proof. Leave receipts out of r.

Put the base trial nets ($181.92, $142.92, or $156.92) beside the $768 guessed margin, and do not subtract. The direct column can look positive while the loss of legitimate users, if your L and M hold, is larger. Overrides and support tags tell you which column is real. The code does not. If the four assumed hours are still there after you ship the rule, the $180 was not a saving.

Who the block hits when they are legitimate

The class describes the domain, not the motive. A blunt rule catches at least four groups: someone protecting a primary inbox while they evaluate you, someone on a shared machine with no other mailbox handy, a teammate testing signup, and someone whose durable alias sits on a domain classified as disposable. Assume that last case happens. Do not assume you know which providers. No public list and no false-positive rate are published.

The review path is part of the policy. Minimum version: a form that records the address, the workflow, the code, and the time. The reviewer allows the account, asks for a second address, or refuses. A refusal should state the requirement, not say "invalid email."

Watch the complaints. "You rejected my real address" is a false-block signal. "The reset never arrived" on an account you allowed is the opposite. Neither is a fraud rate. Use the account, the payment, and the behavior for that call.

Run it without a score

Log workflow, result code, check time, decision, and the actor on an override. Pick the period before you look. Track completion by workflow, overrides that later pay, support tagged "reset never arrived" versus "address rejected," and credits split between chargeable results and free unknown-class results. Do not report the disposable share as fraud, or deliverable as inbox placement. If completion falls and the overrides are real customers, loosen trial before you loosen recovery.

A fresh check on a dispute can cost another credit if the new result is chargeable. Unknown on the retry does not erase the earlier disposable result. Hold the old decision until a person changes it. Duplicates inside one uploaded file are stored once and are not billed twice. That still does not merge a receipt with a newsletter exclusion.

Where a check helps

Classify before trial access, before newsletter enrollment, and when someone sets a recovery address. You do not need a fresh check to send a receipt you already accepted at checkout. You can classify a download and still allow it. MailCheckup returns disposable as its own result and charges one credit when that result finishes. The marketing site explains the product. The sample checker there does not contact mail servers. A list you already have is checked in the app. Nothing here finds addresses, scores leads, or promises the inbox.

The detection page defines the signal. The results guide lists every code, including the free ones. The SaaS page separates a signup check from proof of ownership.

Questions to settle before you ship

Should every disposable address be blocked?

No. Block it as the only recovery address. Step up a trial before ongoing access. Send receipts. Keep it off the recurring newsletter. Allow a low-risk download and skip the long sequence.

Is disposable the same as invalid?

No. Invalid syntax is a broken address. Disposable is a classification on an address that can be well formed, and the server can still accept RCPT. Unknown is a third state: no clear answer, not a chargeable result, and not a reason to apply this block.

Does the flag prove fraud?

No. It describes the inbox service tied to the domain at check time. People use those services for privacy and one-off tasks. Fraud needs other evidence. False positives are possible. No accuracy rate and no list-update frequency are published.

What does the classification cost?

One credit when the disposable result finishes. Other chargeable results in the run cost one credit each. Unknown-class outcomes cost nothing. Risky is not an extra credit. A chargeable recheck can cost another credit. The sketch is not an invoice and not a measured saving.

Will the policy improve inbox placement?

The check does not measure placement. Deliverable is not the inbox. Gmail's spam-rate rule is a separate sending duty. Taking a temporary inbox off a recurring list can cut mail to a destination that will not last, and it can also remove someone who wanted the mail. That is a list decision, not a placement promise.

What to do next

Write the recovery and trial actions in sentences the form can show. Leave receipts and low-risk downloads on allow. Replace every illustrative input with a figure you can point to: your signup count, the disposable share in a sample, your support tags, and your own sending price.

Classify a sample in the MailCheckup app and read disposable apart from unknown and from the risky summary. The sample will not name fraud. It will show you the code you are about to automate.