Reduce Spam Signups in Ortto: 6 Checks Before Sending

By mailfloss

A sudden rise in Ortto contacts is a reason to investigate, not a reason to delete everyone who arrived yesterday. A form submission, permission to receive marketing, an audience match, and a usable email address answer different questions. Your workflow needs a decision at each point.

This guide is for the marketer responsible for Ortto capture widgets and welcome journeys, with a developer involved where custom intake needs verification. It follows six checks from signup source to recurring audience cleaning. The acceptance worksheet at the end joins those checks into one reviewable workflow.

Start my free trial »

Which control should you use for each Ortto signup problem?

Choose the control closest to the failure you observe. Our decision rule is to investigate the source first, establish permission second, and decide what to send only after checking audience membership and address quality. Record the evidence for each decision rather than treating every suspicious contact as a bot.

This is a workflow comparison, not a performance ranking. CAPTCHA, subscription rules, journey controls, and email verification solve different parts of the problem. Using one does not justify skipping the others.

For your first review, choose one affected widget, one intended audience, and one welcome journey. That gives you a tractable path to inspect. Widen the scope after you can explain where a contact came from, why it qualified, and what happened before the first marketing message.

Check 1: Where did the suspicious Ortto contacts come from?

Start with Ortto's Initial source field. Ortto documents it as a read-only record of how a profile was originally added. Use that origin to separate widget investigations from imports and other intake routes. It is an initial-source record, so do not treat it as a complete history of subsequent interactions. Ortto system person fields

Review a small set of affected people and write down the source, creation context, current permission, intended audience, and relevant journey. Add a second set of contacts you recognize as legitimate. Comparing the two helps you avoid making a broad rule from an unfamiliar name or domain alone.

Your working question is concrete: which intake route needs attention? If the suspect group came from a spreadsheet, changing a website widget cannot repair that import. If it came through a specific widget, investigate that widget before changing an unrelated campaign.

Keep your observations separate from your conclusions. A source field is evidence of origin. A cluster of similar addresses is a reason to inspect more closely. Neither is, by itself, a verdict that everyone in the group should be removed.

Create a short incident record with the affected route and the next check you intend to make. Leave outcome fields blank until you have observed them. This keeps the investigation useful when several people share responsibility for the website, Ortto, and sending rules.

Check 2: Is reCAPTCHA configured on the Ortto widget itself?

Ortto's capture protection has two configuration points: the account connection and the form content. Connecting Google reCAPTCHA at account level is not the final widget step.

1. Register your site with Google reCAPTCHA using v2 and the checkbox option.
2. Enter the site and secret keys in Ortto under Settings > Privacy, security and GDPR > Google reCAPTCHA.
3. Open the affected capture widget and add the Google reCAPTCHA field to its form content block.
4. Check the actual website form with a contact you control.

Ortto documents the v2 checkbox option and does not support hidden CAPTCHA. Its capture-widget guide says reCAPTCHA starts disabled and that the field can be added after the account connection. Ortto reCAPTCHA configuration and capture-widget setup

For the website check, record which page and widget you used, whether the challenge appeared, and whether a legitimate submission reached the expected Ortto record. Do not record secret keys in that worksheet.

Repeat the review for each affected widget. The result you want is a visible, working protection step on the intake route under investigation. Avoid calling the incident resolved merely because the account settings contain keys.

Keep the next decision separate: what address was submitted? A visitor can complete a challenge and still mistype an address. That is why the later email-verification check belongs in the same workflow.

Check 3: Does the Ortto record have the intended subscription permission?

Review permission at the source and again at the campaign boundary. Ortto documents that people are subscribed by default unless the data source or API creates them as unsubscribed. A CSV import without permission mapping can therefore add subscribed contacts. Ortto subscription preferences

For an affected import, inspect the original permission data and the mapping used. For a connected source, inspect how that source supplied permission. Do not infer an opt-in from the fact that a record exists or appears in a filtered audience.

Make the desired outcome explicit before adjusting anything. A person with an unusable address and a person who did not request marketing require different decisions. Combining both groups into a single cleanup bucket hides the reason for the change.

Use a controlled contact to review the path from submission to the intended subscription state. Note which audience and journey should be eligible. If the result differs from your expectation, resolve that discrepancy before using the same route for a larger batch.

Verification should support your address-quality decision. It should not silently become your permission decision. Keep both observations in the acceptance worksheet, especially when someone else owns the import or connected source.

Check 4: Are Ortto audience timing rules affecting your test?

An Ortto audience with a time-based condition is not necessarily an immediate signal. Ortto says those audiences are recalculated every 24 hours, so a person can miss the current build and enter later. This limitation applies to time-based audiences; it is not a claim that every Ortto audience waits a day. Ortto journey troubleshooting

Record whether your test audience contains a time-based condition before judging the result. If you expect an immediate event, an age-based filter may be the wrong observation point for that test.

Keep three observations in your worksheet: when the source submission occurred, when you observed the person in the relevant audience, and when you observed a verification result. These are proposed measurement points, not a mailfloss or Ortto delivery-time promise.

The distinction matters when you later enable Instafloss. A check triggered by audience entry depends on the person entering that audience. Do not label an upstream membership delay as a verifier failure without checking where the person actually is.

If your first email must wait for a verification decision, define and test that dependency in the campaign design. Do not assume that configuring a separate check automatically changes the journey's sending order.

Check 5: What happens to people already inside the Ortto journey?

Review existing journey participants separately from new entrants. Ortto explicitly states that editing entry criteria does not remove people already in an active journey. Switching the journey off and on also does not remove them. Ortto journey entry criteria

That creates two jobs during a spam-signup incident. First, correct the rule that allows future entrants. Second, inspect the people already participating and decide how to handle their remaining steps.

For future entry, Ortto documents permission conditions such as Email permission is true or audience subscription conditions. Use the condition appropriate to the messages you intend to send. Ortto campaign subscription guidance

For existing participants, review the journey's current exit handling and pending messages. Do not use a stricter entry filter as evidence that the current population has been cleared.

Before resuming your normal workflow, check one legitimate new entrant and one controlled record representing the excluded group. Separately inspect the existing participants you intended to address. These are different acceptance checks because the entry-rule change has a different scope.

Write the observed outcome beside each check. If the evidence only shows a changed setting, your test is unfinished: the setting and the contact's actual path are not the same observation.

Check 6: How do you connect mailfloss to the Ortto audience workflow?

Connect the audience-cleaning workflow after you have identified the intake route and permission rules. mailfloss provides recurring cleaning for Ortto audiences, alongside a first-class real-time API for developers and AI agents building custom intake.

Connect with an Ortto private key and choose the cleanup scope

Use a private key from an Ortto Custom API data source in the mailfloss Ortto tile, then choose the audiences to verify. An existing Autopilot key does not carry over to this connection. The concrete setup is covered on the Ortto email verification integration.

Begin with report only or ask me first while you review how results relate to your audience. Other cleanup choices include updating a field, unsubscribing, or deleting. Decide which action your team intends before enabling automated changes.

If you use field updates, reserve eight free Ortto custom-field slots for the integration's mf_ fields. Treat that capacity check as part of setup. Do not build a campaign dependency around field results without checking that the expected update is present.

Typo Fixer can repair supported address typos, but your review must still account for multiple Ortto people sharing an address. Inspect the person records involved in a correction. Keep concurrent corrections toward the same address in your acceptance checks; do not treat typo repair as a general deduplication or uniqueness guarantee.

For ongoing maintenance, Autofloss and Decay Protection provide recurring cleaning beyond the initial review. That is the reason to connect the audience workflow instead of making a one-time export your entire hygiene process. See Decay Protection for the ongoing-cleaning role.

Configure Instafloss as a separate audience-entry workflow

Instafloss for Ortto requires the Business plan or the add-on. It also requires setup in Ortto: connecting a private key does not create a one-click webhook arrangement.

Use the Instafloss URL shown for the connection and configure the Ortto webhook path using a Webhook data source and the Entered audience activity. Follow the linked integration setup instructions for the exact configuration; do not substitute a website form event just because it has a similar name.

Check the audience named in the event against the audience you intended to verify. Then use a controlled person to observe audience entry and the resulting verification. This is an acceptance test you perform, not a claim that a test has already passed.

Keep the boundary clear: audience-entry verification happens after the person enters the relevant Ortto audience. It does not establish that every route into your account is covered, and it does not by itself establish that a welcome message waits for the result.

For custom intake that your developers control, the email verification API offers real-time verification with structured results for applications and AI agents. Your application must decide how to use the result before forwarding a signup. Keep that application decision distinct from the native audience-cleaning configuration.

Use this acceptance worksheet before expanding the workflow

The worksheet below is our editorial test framework. It combines Ortto's widget, audience, and journey behavior with mailfloss setup requirements. It contains no measured results or promised completion times.

Choose a modest first scope and inspect the results before expanding. If a row fails, fix that handoff and repeat the affected check. Buying another tool or increasing the audience size will not explain a missing event or an incorrect permission mapping.