Start with the mailbox model
An address string does not explain how its inbox works. A personal mailbox, a public testing inbox, and a forwarding alias may all receive a verification message. They still represent different product decisions. Classifying them together makes a rule easier to write, but harder to justify to legitimate customers.
A relay has a useful job
SimpleLogin describes a service that forwards messages from an alias to a chosen mailbox. That extra address helps its owner keep an underlying inbox private. Receiving mail through a relay is therefore not, by itself, evidence of abuse. It also does not establish that two aliases belong to different people. Both points matter when you issue signup rewards.
Separate access from the reward
Decide which capability needs protection. Reading a product tutorial, consuming a costly free allowance, and claiming a referral reward need not use the same gate. You can verify ownership for account access and apply independent limits to rewards. Make that distinction visible in the interface: explain whether you need another address, a completed verification, or a later attempt.
Make uncertainty an explicit state
A classification service may be temporarily unable to resolve a domain. Do not convert that failure into a claim that the address is safe or disposable. Keep the result unresolved, explain the retry, and avoid issuing a reward while the required check is incomplete. A policy should define this path before the first upstream outage.
Measure the cost of your rule
Compare completed signups, verification failures, appeals, and later product use across address categories. Review mistaken rejections alongside apparent abuse. A lower signup count is not evidence of better customers. Begin with a documented policy, retain a way to correct classifications, and revise the policy when observed behavior supports it.
Source for provider behavior: SimpleLogin's explanation of aliases. Product-policy guidance is Disban's interpretation.