Transcom Group MxGuard Help — eFa Refugee queue (admin)

eFa Refugee queue (admin)

How to process applications for the eFa Refugee plan.

The flow

  1. Customer submits the form at mxguard.uk/efa.html.
  2. The system runs two automatic checks:
    • MX lookup — dig MX their-domain to see if it points at a SaaS provider (likely not eFa) or self-hosted (could be eFa)
    • SMTP banner sniff — connect to their MX on port 25 and read the greeting; an unmodified eFa banner mentions "eFa-v4" or "eFa-v5"
  3. A verdict is recorded (likely_efa, needs_review, or likely_not_efa) and the application lands in /admin/efa-queue.
  4. You eyeball the verdict and evidence, then click Approve or Reject.
  5. If Approved, click Send welcome — this provisions the customer, creates their user account, adds the domain in pending_verification status, and emails them a welcome with a 7-day password reset link plus MX migration crib-sheet.

Reading the verdict

  • likely_efa — SMTP banner explicitly mentions eFa. Safe to auto-approve unless the email/domain looks suspicious for other reasons.
  • needs_review — the MX is self-hosted (often Postfix) but the banner doesn't say eFa. Could be eFa with a customised banner, could be raw Postfix, could be Mailcow. Use your judgement. If the email address looks legit and the company sounds real, approve.
  • likely_not_efa — the MX points at a known SaaS provider (Google, Microsoft, Proofpoint, Mimecast etc). Almost certainly not an eFa user. Reject unless you have other context.

When to reject

  • Verdict is likely_not_efa and the application gives no plausible reason (e.g. "I'm migrating away from M365")
  • Email address looks throwaway (e.g. @protonmail, @gmx, @10minutemail) for a business-domain application
  • Same IP submitted multiple applications recently (rate-limit catches most, but check)
  • Domain doesn't actually exist or isn't yours to claim

Rejected applicants get a polite email and can subscribe to the standard paid plan if they want. No bridges burned.

Lifecycle after approval

A daily cron at 08:00 UTC walks all efa_free subscriptions and:

  • Sends 30-day, 14-day, and 7-day warnings before the free year ends
  • On expiry: flips status to awaiting_payment, automatically applies the lifetime 50% renewal discount (sets the sub to £9.50/mo, £11.40 inc VAT), gives them 14 days grace
  • 14 days after that with no payment: flips to cancelled and suspends the customer + domains
  • Admin gets notified by email when each auto-suspension happens

The 50% renewal discount is permanent for eFa refugees — no end date. If they later upgrade to multiple domains, the discount stays applied to the original eFa-free subscription; additional domains are charged at standard pricing on a separate subscription.

Manual overrides

If a customer needs an exception:

-- Extend a customer's free year by 6 months
UPDATE subscriptions
   SET free_until = free_until + INTERVAL '6 months'
 WHERE reference = 'MXG-XXXXX';

-- Revert from awaiting_payment back to active (e.g. you've agreed manual billing)
UPDATE subscriptions
   SET status = 'active'
 WHERE reference = 'MXG-XXXXX' AND payment_method = 'efa_free';

Anti-abuse posture

The IP-based rate limit (5 signups per hour per IP) catches casual flooding. The MX/banner verdict catches the obvious "I'm just trying to get something free" applications. Anything that gets past both is genuinely indistinguishable from a real eFa user, and the cost of a wrong call is one free domain — small change. Don't agonise.

Related