Acceptable Use Policy

This Acceptable Use Policy (the "AUP") sets the rules every Mumara customer follows when using Mumara ONE, Mumara Campaigns, Mumara Machine, the Mumara AI feature set, and any other Mumara product (collectively, the "Services"). It is incorporated by reference into the Terms of Service; a violation of this AUP is a material breach of those Terms and may lead to suspension or termination.

Mumara has been operating since 2012 and serves more than 21,000 businesses worldwide. Many of you share infrastructure with each other — sending IPs, mailbox-provider reputation, abuse feedback loops. Misuse by one customer can hurt the inbox placement and overall experience of every customer on shared infrastructure. The rules below exist to protect that shared good.

1. Who this AUP applies to

This AUP applies to anyone who uses the Services — whether on a paid plan, a trial, or a promotional plan, whether you are the registered Member, an authorized team member, or an end-customer of a Mumara reseller. Resellers must apply this AUP to their end-customers and are responsible to Mumara for end-customer compliance.

2. Permission to send

2.1 The standard

You must have explicit, verifiable consent from each recipient before sending email through the Services. Consent must be:

• Specific — to the type of communication you will send.
• Informed — clearly disclosing who you are and what they will receive.
• Documented — captured in a way you can show to us, to mailbox providers, and to regulators on request.
• Voluntary — not a precondition for accessing an unrelated service.

2.2 Acceptable consent sources

• Subscription forms with a clear consent statement (single opt-in).
• Double opt-in (preferred) — a confirmation message the recipient must act on.
• Existing customer relationships, where consent is implied by the transaction and permitted by the law applicable to the recipient (e.g. CAN-SPAM in the US, soft opt-in under PECR in the UK and CASL implied consent in Canada). Implied consent has narrower scope than explicit consent and may expire.
• Real, attended events where you collected sign-ups in person and disclosed at the time how you would contact them.

2.3 What is not consent

• "Pre-checked" boxes on a sign-up form (invalid in the EU/UK; risky elsewhere).
• Burying the consent statement in a terms-of-service link.
• An unrelated business relationship from years ago.
• Consent collected by a third party that did not name you as the sender.
• Web-scraped, "appended", or directory-sourced contact lists.
• Acquired customer lists where the original consent did not extend to communications from your organization.

3. List quality and acquisition

3.1 Prohibited list sources

• Purchased, rented, or shared lists.
• Web-scraped lists.
• Email-appending services (matching incomplete records to email addresses).
• Lists obtained from acquired companies without re-consenting recipients to communications from your brand.
• Distribution-list addresses (info@, sales@, etc.) where you do not have consent from a specific person.

3.2 Hygiene expectations

• Validate addresses at sign-up and reject obviously invalid ones.
• Honour bounces — Mumara automatically suppresses hard bounces; you must not re-import suppressed addresses.
• Re-engage or sunset Contacts who haven't opened or clicked for an extended period (industry standard is 6–12 months).
• Keep complaint rates below the thresholds in Section 6.
• Treat each Contact as the unit of consent — do not move a Contact between unrelated brands you operate without re-consenting them.

4. Sender identification and authentication

4.1 Identifying yourself

• The "From" name and "From" address must accurately identify the sender.
• Marketing email must include a valid postal address (CAN-SPAM, CASL).
• Subject lines must not be deceptive.
• Any commercial email must clearly indicate that it is commercial in nature.

4.2 Authentication

You must authenticate every sending domain you use:

• SPF records published and aligned.
• DKIM with a 1024-bit (or stronger) key, signed by you or by Mumara per your configuration.
• DMARC with at minimum a p=none policy, escalating to quarantine or reject when ready.
• Bounce / return-path domain aligned with the visible "From" domain.
• BIMI compliance if you publish a BIMI record (logo authentication and chain of custody).

You must not use a domain you do not own or control. You must not impersonate another brand, person, or government body in your "From", "Reply-to", or message body.

5. Unsubscribe and opt-out

5.1 Email

• Every commercial email must include a clear, working unsubscribe mechanism.
• Mumara automatically inserts a List-Unsubscribe header (RFC 2369 and RFC 8058 one-click) — your visible link must work too, and lead to a single-click or 1-click confirmation.
• Opt-outs must be processed promptly. CAN-SPAM allows up to 10 business days; we recommend processing within 1 business day.
• You must not require an account login or extra information beyond an email address to unsubscribe.

5.2 Transactional vs marketing

Transactional messages (order confirmations, password resets, security alerts) do not need an unsubscribe link; their content must be limited to the trigger that produced them. Mixed "transactional + marketing" messages are treated as marketing — include an unsubscribe and obtain consent for the marketing portion.

5.3 Suppression scope

A Contact who unsubscribes from a specific list, brand, or program must not receive other marketing from your organization unless they have separately consented to that other communication. Mumara provides global, list, and program-level suppression — choose the scope that respects the Contact's expectation.

6. Bounce and complaint handling

The following thresholds are guidance — exceed them and you will likely be throttled, paused, or asked to suspend. Mailbox providers expect senders to operate well below them.

• Hard bounce rate < 2% per send.
• Spam complaint rate < 0.1% per send (Gmail, Yahoo, and Microsoft enforcement region).
• Unsubscribe rate sustained > 1% triggers internal review.
• Spam-trap hits — even a small number can cause severe reputation damage; we may suspend on detection.

Mumara automatically suppresses hard bounces, complainers, and known spam-trap formats. You must not re-import suppressed addresses without re-collecting valid consent.

7. Prohibited content

You must not use the Services to send, host, transmit, or generate:

• Phishing — any content designed to harvest credentials or trick recipients.
• Malware — links to malware, exploit kits, or attachments that install software the recipient did not authorize.
• Fraud, scams, "advance fee" schemes, or anything resembling a 419 scam.
• Content that violates intellectual property, trademark, copyright, publicity, or privacy rights.
• Content that defames, harasses, threatens, intimidates, or incites violence.
• Hate speech and content targeting protected categories.
• Child sexual abuse material (CSAM) — reported to relevant authorities on detection.
• Non-consensual intimate imagery.
• Content that infringes on export-control or sanctions regimes.
• Anything illegal in the recipient's jurisdiction.

8. Restricted industries and use cases

The categories below are restricted because of regulatory complexity, complaint risk, or both. They require pre-approval, additional documentation, or may be refused entirely. Even when allowed, they remain subject to stricter monitoring.

• Adult content.
• Gambling, lotteries, sweepstakes (varies by jurisdiction).
• Cryptocurrency promotion, ICOs, NFT pump-and-dumps, "trading signals".
• Pharmaceuticals, supplements, nutraceuticals — especially without licensing in the recipient's country.
• Get-rich-quick, MLM, pyramid structures, "binary options".
• Aggressive lead-generation, "high-pressure" sales, autodialer follow-up.
• Debt relief, credit repair, payday loans (highly regulated in the US).
• Firearms, ammunition, explosives, weapons.
• Cannabis, CBD, hemp products (varies by jurisdiction).
• Affiliate-only senders without their own product or service.
• Single-opt-in mass acquisition campaigns.
• Real-estate "lead gen" using scraped MLS data.
• Rental list / list-broker resales of any kind.

To pre-clear a restricted use case, contact us with subject line "Use-case review" and include: your audience, the consent flow, sample content, expected volume, and the jurisdictions you send into.

10. AI safeguards

The Mumara AI features (across the Mumara AI Fast, Mumara AI, and Mumara AI Advanced tiers) are designed for legitimate marketing and operational use. You must not use Mumara AI to:

• Generate phishing content, malware, or step-by-step instructions for harmful activity.
• Impersonate a real, named person without their explicit consent.
• Generate child sexual abuse material, terrorism content, or other content prohibited by law.
• Make decisions about individuals that produce legal or similarly significant effects without appropriate human review.
• Circumvent the safety systems built into Mumara AI.
• Harvest personal information of identified individuals from training data.

AI outputs may be inaccurate, biased, or out of date. You are responsible for reviewing AI output before sending it to your Contacts. AI output is not legal, financial, medical, or other professional advice.

11. Bridges, IPs, and warm-up

• For new sending IPs and new domains, follow the warm-up schedule the Services recommend. Exceeding it can damage your reputation and cause throttling.
• Where you connect external sending nodes (Amazon SES, SendGrid, Mailgun, etc.) as Bridges, you remain bound by the AUP and the terms of those upstream providers.
• Mumara may rotate, throttle, or pause IPs to protect deliverability for the wider customer base.
• You must not use the Services to "stress test" sending capacity against third-party endpoints you do not own.

12. Security and platform integrity

You must not, and must not let any user under your account:

• Probe, scan, or attempt to penetrate the security of the Services without prior written authorization for a coordinated test.
• Reverse-engineer, decompile, or disassemble any Mumara software, except where that restriction is prohibited by law.
• Bypass or interfere with rate limits, throttling, anti-spam, anti-fraud, or other protective controls.
• Submit content designed to overload, crash, or exploit the Services or any sub-processor.
• Use the Services to scan, probe, or attack a third party.
• Attempt to access an account, data, or system that does not belong to you.
• Use stolen credit cards, stolen credentials, or stolen identity documents.
• Operate the Services in violation of export-control or sanctions law.

13. Resellers and end-customers

If you resell Mumara to your own customers, you must:

• Bind every end-customer to terms at least as protective as our Terms and this AUP.
• Maintain a process to investigate and remediate end-customer abuse on a timeline that meets our enforcement timelines.
• Identify yourself as a Mumara reseller on request.
• Not represent that you are Mumara or speak on Mumara's behalf to your end-customers.
• Not relicense or sub-license Mumara intellectual property except as permitted.

14. Reporting abuse

If you have received email sent through Mumara that violates this AUP, please report it via /contact/ with subject line "Abuse report". Include the full message headers (the parts beginning with Received:, From:, To:, Message-ID:, DKIM-Signature:, etc.). We investigate every report we can reproduce.

For security vulnerabilities, mark the subject line "Security report" — we will route to our security team and acknowledge within one business day.

15. Investigation and cooperation

If we receive a complaint about your account, or our automated systems flag your sending, we may:

• Inspect message metadata (headers, IPs, timestamps, sending speed, complaint rate).
• Review the Customer Content of campaigns at issue, where this is necessary to investigate.
• Ask you to provide proof of consent for the affected list segment, the consent text shown at sign-up, and the original opt-in source.
• Apply temporary rate limits, hold individual campaigns, or pause sending while we investigate.
• Cooperate with mailbox providers, gateways, and law enforcement where appropriate.

You agree to cooperate in good faith and respond promptly to investigation requests.

16. Enforcement actions

Depending on severity, our response may include any of the following:

• A warning and an opportunity to correct.
• Throttling or rate-limiting your sending speed.
• Pausing the affected campaign or program.
• Holding suspect content for review before delivery.
• Suspending sending capabilities pending investigation.
• Terminating addons (e.g. AI access) without terminating the Account.
• Terminating the Account, with data export per the Terms.
• Reporting to law enforcement, mailbox providers, blocklists, or sanctions authorities.
• Where applicable, debiting fees due for cleanup, blocklisting remediation, or third-party penalty pass-through.

Severe violations — phishing, malware, deliberate spam, illegal content — may result in immediate termination without warning. We reserve the right to take any action necessary to protect our infrastructure, our other customers, our sub-processors, and the public.

17. Appeals

If we suspend or terminate your Account and you believe we have it wrong, you can appeal by contacting /contact/ with subject line "Account suspension appeal". Include any new evidence (consent records, third-party authorizations, corrected content) and your proposed remediation. We will review the appeal and respond within a reasonable timeframe.

18. Updates

We update this AUP as the legal landscape, mailbox-provider rules, and our products evolve. Material changes are posted with the new "Last updated" date and, where appropriate, communicated by email or in-product notice. Continued use of the Services after the effective date constitutes acceptance.

19. Contact

Not sure if your sending is acceptable? Talk to us before you send. Contact /contact/ with details about your audience, consent flow, content, volume, and destination jurisdictions. We would rather review an unusual use case in advance than suspend an account after a complaint surge.