MailCheck Logo
MailCheckAPI
by FadSync
Get API Key
Security, Fraud & Aliases20 min read

What is an Email Alias & Sub-Addressing: Plus Addressing (+tagging) vs Forwarding vs Disposable Accounts (2026 Developer Guide)

FadSync Team
Security Research & Engineering
FadSync Logo Default

What is an Email Alias & Sub-Addressing: Plus Addressing (+tagging) vs Forwarding vs Disposable Accounts (2026 Developer Guide)

In modern web development, identity management, and SaaS engineering, few concepts generate as much confusion—or create as many security and billing vulnerabilities—as email aliases and sub-addressing.

To an end-user, an email alias is a convenient tool for sorting newsletter subscriptions, organizing incoming receipts, or protecting personal privacy. But to a SaaS product team, an unmanaged email alias architecture can lead to rampant free trial fraud, duplicate accounts, distorted CRM analytics, and broken authentication pipelines.

graph TD
    A["Inbound User Signup String"] --> B{"Email Normalization & Alias Engine"}
    B -->|Plus Addressing: user+trial@gmail.com| C["Strip Sub-address Tag -> Canonical: user@gmail.com"]
    B -->|Gmail Dot Mutation: j.o.h.n.doe@gmail.com| D["Strip Dots -> Canonical: johndoe@gmail.com"]
    B -->|Masked Forwarding: user.xyz@privaterelay.appleid.com| E["Flag as Privacy Relay / Forwarding Alias"]
    B -->|Disposable Burner: user@10minutemail.com| F["Match Threat DB -> Block Registration (403)"]
    B -->|Standard Corporate Mailbox: john@company.com| G["Allow Deliverable Mailbox (200 OK)"]
    
    C --> H["Check Existing Canonical Accounts in Database"]
    D --> H
    H -->|Account Exists| I["Block Duplicate Trial / Prompt Existing Login"]
    H -->|Clean Record| J["Provision Safe Account & Dispatch Welcome Flow"]
    E --> J
    G --> J

Every month, over 90,000 developers, IT administrators, and security engineers search for "what is an email alias" and "how does email plus addressing work".

In this comprehensive 2026 architectural guide, we dissect the inner workings of email aliases, compare sub-addressing (plus addressing) vs server-level forwarding vs privacy relays, expose how malicious actors exploit alias variations for infinite free trial abuse, and provide production-ready normalization algorithms in TypeScript, Python, Go, and PHP.

Table of Contents

  1. The Anatomy of an Email Address (Local-Part vs Domain)
  2. Type 1: Sub-Addressing & Plus Addressing (RFC 5233)
  3. Type 2: The Gmail Dot Trick & Provider-Specific Quirks
  4. Type 3: Server-Level Alias Forwarding & Catch-All Routing
  5. Type 4: Masked Privacy Aliases (Apple Relay, SimpleLogin, AnonAddy)
  6. Comparative Matrix: Aliases vs Disposable Emails vs Spam Traps
  7. The SaaS Threat: How Users Abuse Aliases for Infinite Free Trials
  8. Production Normalization Algorithms (TypeScript, Python, Go, PHP)
  9. How MailCheck API Automatically Handles & Verifies Email Aliases
  10. Frequently Asked Questions (FAQ)
  11. Strategic Conclusion & Developer Checklist

1. The Anatomy of an Email Address (Local-Part vs Domain)

To understand how email aliases operate under the hood, we must first examine the formal email specification defined in RFC 5322 and RFC 5321.

An email address consists of two primary syntactic components separated by the @ symbol:

$$\text{Email Address} = \text{Local-Part} \text{ @ } \text{Domain-Part}$$

flowchart LR
    subgraph Email["alex.dev+newsletter@mailcheck.fadsync.com"]
        direction TB
        L["Local-Part: alex.dev+newsletter"]
        At["Separator: @"]
        D["Domain-Part: mailcheck.fadsync.com"]
    end

1. The Domain Part (domain.com)

The domain part is governed strictly by DNS protocols. When an email transfer agent (MTA) sends a message, it queries public DNS servers for the domain's MX (Mail Exchange) records. Domain names are case-insensitive (GMAIL.COM $\equiv$ gmail.com).

2. The Local Part (user+tag)

The local-part precedes the @ symbol. According to RFC 5321 Section 2.3.11, the local-part is strictly the domain's internal responsibility:

"The local-part MUST be interpreted only by the destination host. It has no meaning to any other host in the internet."

Because of this RFC rule:

  • While RFC standards allow mail servers to treat local-parts as case-sensitive (User@domain.com vs user@domain.com), virtually all modern mail providers (Google, Microsoft, Fastmail, Proton) treat them as case-insensitive.
  • Mail servers have complete autonomy over how they interpret special characters (such as +, -, ., and %) within the local-part.

2. Type 1: Sub-Addressing & Plus Addressing (RFC 5233)

Sub-addressing (commonly referred to as plus addressing or email tagging) is a standardized mechanism defined in RFC 5233 (Sieve Email Filtering: Subaddress Extension).

It allows a user to append a delimiter (most commonly the plus sign +) followed by an arbitrary string (a tag) to their existing username.

flowchart LR
    A["Raw Input: sarah+stripe_receipts@gmail.com"] --> B["Delimiter Detection: +"]
    B --> C["Base Username: sarah"]
    B --> D["Sub-address Tag: stripe_receipts"]
    C --> E["Destination Mailbox: sarah@gmail.com"]

Provider Support Matrix for Plus Addressing

Provider Supported Delimiter Example Raw Address Delivered Mailbox
Google Workspace / Gmail + (Plus) alex+dev2026@gmail.com alex@gmail.com
Microsoft 365 / Outlook + (Plus) john+invoicing@outlook.com john@outlook.com
Fastmail + or = (Plus or Equals) team+support@fastmail.com team@fastmail.com
Proton Mail + (Plus) security+vault@proton.me security@proton.me
iCloud Mail + (Plus) user+shopping@icloud.com user@icloud.com
Yahoo Mail - (Hyphen / Disposable) base-tag@yahoo.com base@yahoo.com

Why Users Create Plus Addresses

  1. Filtering & Automation: Users set up mail client rules to auto-archive, star, or label incoming messages based on the tag (e.g., user+finance@... goes straight to a Financial folder).
  2. Breach Tracing: If a user signs up on a questionable website using user+sitename@domain.com and later receives unsolicited spam sent to that exact address, they know which service leaked or sold their data.
  3. Single Mailbox Multi-Tenancy: Developers use plus addressing to test signup flows, invitation links, and multi-user permissions without provisioning dozens of real mailboxes.

3. Type 2: The Gmail Dot Trick & Provider-Specific Quirks

One of the most famous quirks in email local-part handling is Google's Dot Invariance rule (commonly nicknamed the Gmail Dot Trick).

How Google Handles Dots

In standard Gmail (@gmail.com) and Google Workspace accounts, periods/dots inside the local-part are completely ignored by the mail delivery router.

All of the following addresses resolve to the exact same physical inbox:

johnsmith@gmail.com
john.smith@gmail.com
j.o.h.n.s.m.i.t.h@gmail.com
j.ohnsmith@gmail.com

For a username of length $n$, there are $2^{n-1}$ unique dot permutations that all route to the identical inbox. For a 10-character username, a single user can generate 512 unique email strings that bypass naive database uniqueness constraints (UNIQUE (email)).

graph TD
    A["j.o.h.n.doe@gmail.com"] --> M["Gmail Mail Routing Engine"]
    B["john.doe@gmail.com"] --> M
    C["johndoe@gmail.com"] --> M
    D["j.ohndoe+trial@gmail.com"] --> M
    M --> Inbound["Single Physical Inbox: johndoe@gmail.com"]

Provider Behavior: Dots in Local-Part

Provider / Domain Are Dots Ignored? Example Equivalent Addresses
Gmail (@gmail.com, @googlemail.com) YES a.b.c@gmail.com $\equiv$ abc@gmail.com
Google Workspace (Custom Domains) YES (Default) dev.lead@company.com $\equiv$ devlead@company.com
Microsoft Outlook / Office 365 NO john.doe@outlook.com $\neq$ johndoe@outlook.com
Yahoo Mail NO john.doe@yahoo.com $\neq$ johndoe@yahoo.com
Proton Mail NO john.doe@proton.me $\neq$ johndoe@proton.me
Fastmail NO john.doe@fastmail.com $\neq$ johndoe@fastmail.com

4. Type 3: Server-Level Alias Forwarding & Catch-All Routing

Unlike sub-addressing (which modifies a single base username), server-level aliases are independent email addresses configured in the mail server's routing table that forward all incoming traffic to one or more primary destination mailboxes.

flowchart LR
    subgraph PublicAliases["Public Inbound Addresses"]
        A["support@fadsync.com"]
        B["help@fadsync.com"]
        C["billing@fadsync.com"]
    end
    
    subgraph MailRouting["MTA Virtual Alias Table (/etc/postfix/virtual)"]
        R["support -> alex, devops<br/>help -> alex<br/>billing -> finance@ext.com"]
    end
    
    subgraph Inboxes["Physical Destination Mailboxes"]
        D["alex@fadsync.com"]
        E["devops@fadsync.com"]
        F["finance-team@fadsync.com"]
    end
    
    A --> R
    B --> R
    C --> R
    R --> D
    R --> E
    R --> F

Common Server-Level Alias Types:

1. Role-Based Group Aliases

Addresses like sales@, security@, info@, and support@ are rarely owned by a single individual. In high-volume B2B marketing, sending to role-based aliases is risky because multiple recipients may mark unsolicited emails as spam, inflating your spam complaint rate.

2. Employee Name Variations

Organizations frequently alias common name variations to the same employee:

  • alexander.taylor@company.com $\rightarrow$ alex@company.com
  • ataylor@company.com $\rightarrow$ alex@company.com

3. Catch-All (Accept-All) Routing

A catch-all domain accepts email for any string before the @ symbol (e.g., anything@domain.com is routed to an admin inbox). When validating catch-all domains, simulated SMTP handshakes cannot verify individual mailbox existence. Learn more in our dedicated guide on Catch-All Email Verification Architecture.

5. Type 4: Masked Privacy Aliases (Apple Relay, SimpleLogin, AnonAddy)

In response to tracking and data harvesting, modern consumer ecosystems have popularized on-demand masked email aliases.

sequenceDiagram
    autonumber
    actor User as Consumer / App User
    participant Relay as Apple / SimpleLogin Relay Server
    participant SaaS as Your Web Application / SaaS
    
    User->>SaaS: Registers with Masked Alias (e.g., k39d8z@privaterelay.appleid.com)
    SaaS->>Relay: Sends Verification Email / Password Reset
    Relay->>Relay: Resolves Cryptographic Mapping -> user@realicloud.com
    Relay->>User: Forwards Email to Real iCloud Mailbox
    Note over User,SaaS: User identity remains completely anonymous to SaaS

Major Masked Email Ecosystems:

1. Apple "Hide My Email" (Sign in with Apple)

  • Generates unique random strings ending in @privaterelay.appleid.com.
  • Bidirectional relay: Outgoing replies from the user are re-routed through Apple's relay to preserve anonymization.
  • Highly deliverable and legitimate, but prevents SaaS providers from seeing corporate domain affiliations.

2. SimpleLogin (by Proton) & AnonAddy

  • Open-source privacy forwarding services that allow users to generate custom sub-domain aliases (e.g., amazon.9k3l@simplelogin.com).
  • Features pgp-encrypted forwarding and automated alias disabling if a sender abuses frequency.

3. MaskMe / IronVest

  • Browser extension-based disposable alias generators that act as intermediary proxies.

6. Comparative Matrix: Aliases vs Disposable Emails vs Spam Traps

Understanding the fundamental operational differences between alias types, disposable domains, and spam traps is vital for risk scoring:

Characteristic Plus Addressing (user+tag@) Masked Relay (Apple / SimpleLogin) Disposable Burner (TempMail) Pristine Spam Trap
Delivery Destination Real, active physical inbox Real inbox via forwarder Temporary RAM / public web inbox Monitored honeypot database
Inbox Lifespan Permanent Permanent (until toggled off) 10 to 60 minutes Indefinite
Can Receive Replies? Yes Yes Yes (during session) No (Discards or logs)
Fraud Risk Score Medium (Trial abuse vector) Low - Medium (Legitimate privacy) CRITICAL (100) CRITICAL (100)
Recommended Action Normalize & Deduplicate Allow with Verification Block Registration Quarantine & Suppress

7. The SaaS Threat: How Users Abuse Aliases for Infinite Free Trials

Why should engineering teams care about email aliases? Because without normalization, aliases allow single users to exploit free tiers, bypass rate limits, and defraud promotional programs.

graph TD
    Attacker["Malicious User: badactor@gmail.com"] -->|Registers #1| A1["badactor+1@gmail.com (Gets $10 Free Trial)"]
    Attacker -->|Registers #2| A2["badactor+2@gmail.com (Gets $10 Free Trial)"]
    Attacker -->|Registers #3| A3["b.a.d.actor@gmail.com (Gets $10 Free Trial)"]
    Attacker -->|Registers #4| A4["b.adactor+promo@gmail.com (Gets $10 Free Trial)"]
    
    A1 --> DB[("SaaS User Database (Naive UNIQUE email constraint)")]
    A2 --> DB
    A3 --> DB
    A4 --> DB
    
    DB --> Leak["Result: $40 in Free Compute Drained, 4 Fake User Records Skewing Analytics"]

The 4 Major Exploitation Vectors:

1. Free Trial & Computational Resource Churn

AI SaaS platforms offering free OpenAI/Claude compute credits, free cloud trial VMs, or monthly credits frequently suffer high compute costs from users cycling through user+1@gmail.com, user+2@gmail.com, etc.

2. Coupon & Promotional Code Stacking

E-commerce stores offering "15% off your first order" are routinely defrauded by repeat buyers creating plus-addressed variations of their personal email to claim introductory discounts indefinitely.

3. Referral Program Self-Funding

Users invite their own plus-addressed email variations (alex+ref1@, alex+ref2@) to unlock referral bonus tiers, free subscription months, and affiliate commissions.

4. Bypassing Rate Limits & Voting Polls

Web apps that gate usage or public voting polls by unique email strings are trivial to manipulate when dot mutations and plus tags are accepted as distinct entities.

8. Production Normalization Algorithms (TypeScript, Python, Go, PHP)

To solve the alias abuse problem, your registration and authentication pipelines must compute the Canonical Normalized Email before executing database queries or credit provisioning.

flowchart TD
    Raw["Raw Input: J.o.h.n.Doe+TestTrial@googlemail.com"] --> Lower["1. Lowercase: j.o.h.n.doe+testtrial@googlemail.com"]
    Lower --> DomainNorm["2. Normalize Domain: googlemail.com -> gmail.com"]
    DomainNorm --> ProviderCheck{"3. Check Provider Rules"}
    
    ProviderCheck -->|Google / Gmail| GoogleRule["Strip Dots: johndoetesttrial<br/>Strip Plus Tag: johndoe"]
    ProviderCheck -->|Microsoft / Outlook| MsftRule["Keep Dots: j.o.h.n.doe<br/>Strip Plus Tag: j.o.h.n.doe"]
    ProviderCheck -->|Fastmail / Proton / iCloud| GenericRule["Keep Dots<br/>Strip Plus Tag"]
    
    GoogleRule --> Result["Canonical Form: johndoe@gmail.com"]
    MsftRule --> Result
    GenericRule --> Result

Implementation 1: TypeScript / Node.js

export interface NormalizedEmailResult {
  raw: string;
  normalized: string;
  localPart: string;
  domainPart: string;
  hasAlias: boolean;
  aliasTag: string | null;
  provider: string;
}

export function normalizeEmail(emailInput: string): NormalizedEmailResult {
  if (!emailInput || typeof emailInput !== 'string') {
    throw new Error('Invalid email input');
  }

  const trimmed = emailInput.trim().toLowerCase();
  const atIndex = trimmed.lastIndexOf('@');
  if (atIndex <= 0 || atIndex === trimmed.length - 1) {
    throw new Error('Malformed email format');
  }

  let local = trimmed.slice(0, atIndex);
  let domain = trimmed.slice(atIndex + 1);

  // Normalize Google domain aliases
  if (domain === 'googlemail.com') {
    domain = 'gmail.com';
  }

  let hasAlias = false;
  let aliasTag: string | null = null;
  let provider = 'generic';

  // Handle Google / Gmail
  if (domain === 'gmail.com') {
    provider = 'google';
    // Remove dots
    local = local.replace(/\./g, '');
    // Handle plus sub-addressing
    const plusIdx = local.indexOf('+');
    if (plusIdx !== -1) {
      hasAlias = true;
      aliasTag = local.slice(plusIdx + 1);
      local = local.slice(0, plusIdx);
    }
  } 
  // Handle Microsoft (Outlook / Hotmail / Live)
  else if (['outlook.com', 'hotmail.com', 'live.com', 'msn.com'].includes(domain)) {
    provider = 'microsoft';
    const plusIdx = local.indexOf('+');
    if (plusIdx !== -1) {
      hasAlias = true;
      aliasTag = local.slice(plusIdx + 1);
      local = local.slice(0, plusIdx);
    }
  }
  // Handle Yahoo Mail (Hyphen delimiter for disposable aliases)
  else if (['yahoo.com', 'ymail.com', 'myyahoo.com'].includes(domain)) {
    provider = 'yahoo';
    const hyphenIdx = local.indexOf('-');
    if (hyphenIdx !== -1) {
      hasAlias = true;
      aliasTag = local.slice(hyphenIdx + 1);
      local = local.slice(0, hyphenIdx);
    }
  }
  // Standard generic plus addressing (Fastmail, Proton, iCloud)
  else {
    const plusIdx = local.indexOf('+');
    if (plusIdx !== -1) {
      hasAlias = true;
      aliasTag = local.slice(plusIdx + 1);
      local = local.slice(0, plusIdx);
    }
  }

  const normalized = `${local}@${domain}`;

  return {
    raw: emailInput,
    normalized,
    localPart: local,
    domainPart: domain,
    hasAlias,
    aliasTag,
    provider
  };
}

// Example Execution
// Input: "J.o.h.n.Doe+ai_trial2026@googlemail.com"
// Output: { normalized: "johndoe@gmail.com", hasAlias: true, aliasTag: "ai_trial2026", provider: "google" }

Implementation 2: Python (FastAPI / Django / Flask)

import re
from typing import Dict, Any, Optional

def normalize_email_address(email_input: str) -> Dict[str, Any]:
    """
    Normalizes email addresses to prevent alias abuse and duplicate trial registrations.
    Handles Gmail dot-removal, domain aliasing, and plus-address stripping.
    """
    if not email_input or not isinstance(email_input, str):
        raise ValueError("Invalid email input")

    cleaned = email_input.strip().lower()
    if "@" not in cleaned:
        raise ValueError("Malformed email address")

    local_part, domain_part = cleaned.rsplit("@", 1)

    # Domain canonicalization
    if domain_part == "googlemail.com":
        domain_part = "gmail.com"

    has_alias = False
    alias_tag: Optional[str] = None
    provider = "generic"

    if domain_part == "gmail.com":
        provider = "google"
        # Remove all dots in local-part for Gmail
        local_part = local_part.replace(".", "")
        if "+" in local_part:
            has_alias = True
            base, tag = local_part.split("+", 1)
            local_part = base
            alias_tag = tag

    elif domain_part in ["outlook.com", "hotmail.com", "live.com", "msn.com"]:
        provider = "microsoft"
        if "+" in local_part:
            has_alias = True
            base, tag = local_part.split("+", 1)
            local_part = base
            alias_tag = tag

    elif domain_part in ["yahoo.com", "ymail.com"]:
        provider = "yahoo"
        if "-" in local_part:
            has_alias = True
            base, tag = local_part.split("-", 1)
            local_part = base
            alias_tag = tag

    else:
        if "+" in local_part:
            has_alias = True
            base, tag = local_part.split("+", 1)
            local_part = base
            alias_tag = tag

    canonical_email = f"{local_part}@{domain_part}"

    return {
        "raw_email": email_input,
        "canonical_email": canonical_email,
        "local_part": local_part,
        "domain_part": domain_part,
        "has_alias": has_alias,
        "alias_tag": alias_tag,
        "provider": provider
    }

# Example Usage:
# result = normalize_email_address("Sarah.M.Connor+betaTest@gmail.com")
# Output: canonical_email -> 'sarahmconnor@gmail.com'

Implementation 3: Go (Golang)

package main

import (
	"errors"
	"fmt"
	"strings"
)

type NormalizedEmail struct {
	Raw       string
	Canonical string
	Local     string
	Domain    string
	HasAlias  bool
	AliasTag  string
	Provider  string
}

func NormalizeEmail(email string) (*NormalizedEmail, error) {
	trimmed := strings.ToLower(strings.TrimSpace(email))
	lastAt := strings.LastIndex(trimmed, "@")
	if lastAt <= 0 || lastAt == len(trimmed)-1 {
		return nil, errors.New("malformed email format")
	}

	local := trimmed[:lastAt]
	domain := trimmed[lastAt+1:]

	if domain == "googlemail.com" {
		domain = "gmail.com"
	}

	hasAlias := false
	aliasTag := ""
	provider := "generic"

	if domain == "gmail.com" {
		provider = "google"
		local = strings.ReplaceAll(local, ".", "")
		if idx := strings.Index(local, "+"); idx != -1 {
			hasAlias = true
			aliasTag = local[idx+1:]
			local = local[:idx]
		}
	} else if domain == "outlook.com" || domain == "hotmail.com" || domain == "live.com" {
		provider = "microsoft"
		if idx := strings.Index(local, "+"); idx != -1 {
			hasAlias = true
			aliasTag = local[idx+1:]
			local = local[:idx]
		}
	} else if domain == "yahoo.com" || domain == "ymail.com" {
		provider = "yahoo"
		if idx := strings.Index(local, "-"); idx != -1 {
			hasAlias = true
			aliasTag = local[idx+1:]
			local = local[:idx]
		}
	} else {
		if idx := strings.Index(local, "+"); idx != -1 {
			hasAlias = true
			aliasTag = local[idx+1:]
			local = local[:idx]
		}
	}

	return &NormalizedEmail{
		Raw:       email,
		Canonical: fmt.Sprintf("%s@%s", local, domain),
		Local:     local,
		Domain:    domain,
		HasAlias:  hasAlias,
		AliasTag:  aliasTag,
		Provider:  provider,
	}, nil
}

Implementation 4: PHP (Laravel / Symfony / WordPress)

<?php

function normalizeEmailAddress(string $email): array {
    $email = strtolower(trim($email));
    $atPos = strrpos($email, '@');
    
    if ($atPos === false || $atPos === 0 || $atPos === strlen($email) - 1) {
        throw new InvalidArgumentException("Malformed email address");
    }

    $local = substr($email, 0, $atPos);
    $domain = substr($email, $atPos + 1);

    if ($domain === 'googlemail.com') {
        $domain = 'gmail.com';
    }

    $hasAlias = false;
    $aliasTag = null;
    $provider = 'generic';

    if ($domain === 'gmail.com') {
        $provider = 'google';
        $local = str_replace('.', '', $local);
        if (($plusPos = strpos($local, '+')) !== false) {
            $hasAlias = true;
            $aliasTag = substr($local, $plusPos + 1);
            $local = substr($local, 0, $plusPos);
        }
    } elseif (in_array($domain, ['outlook.com', 'hotmail.com', 'live.com'])) {
        $provider = 'microsoft';
        if (($plusPos = strpos($local, '+')) !== false) {
            $hasAlias = true;
            $aliasTag = substr($local, $plusPos + 1);
            $local = substr($local, 0, $plusPos);
        }
    } else {
        if (($plusPos = strpos($local, '+')) !== false) {
            $hasAlias = true;
            $aliasTag = substr($local, $plusPos + 1);
            $local = substr($local, 0, $plusPos);
        }
    }

    return [
        'raw' => $email,
        'canonical' => "{$local}@{$domain}",
        'local' => $local,
        'domain' => $domain,
        'has_alias' => $hasAlias,
        'alias_tag' => $aliasTag,
        'provider' => $provider
    ];
}

9. How MailCheck API Automatically Handles & Verifies Email Aliases

Instead of manually writing, maintaining, and updating complex provider-specific regex tables, engineering teams integrate MailCheck API.

MailCheck API combines real-time syntax checking, multi-layer DNS/MX resolution, 40M+ disposable domain filtering, and automated alias canonicalization in a single edge-optimized endpoint (<45ms).

sequenceDiagram
    autonumber
    actor Client as User Signup Form
    participant Backend as SaaS Backend Service
    participant API as MailCheck Edge API
    participant DB as Postgres / Redis Database
    
    Client->>Backend: POST /api/signup { email: "alex.dev+trial@gmail.com" }
    Backend->>API: POST /v1/check { email: "alex.dev+trial@gmail.com" }
    Note over API: Normalizes to alexdev@gmail.com<br/>Executes simulated SMTP & MX ping<br/>Checks 40M+ Burner Blocklists
    API-->>Backend: 200 OK { is_deliverable: true, is_alias: true, canonical_email: "alexdev@gmail.com" }
    
    Backend->>DB: SELECT id FROM users WHERE canonical_email = 'alexdev@gmail.com'
    alt Canonical Record Exists
        DB-->>Backend: User Found (ID: 94102)
        Backend-->>Client: 409 Conflict: "An account already exists for this email mailbox."
    else Clean Record
        DB-->>Backend: No Match
        Backend->>DB: INSERT INTO users (email, canonical_email, ...)
        Backend-->>Client: 201 Created: "Account created successfully."
    end

Sample MailCheck API Response Payload

{
  "email": "Alex.Developer+Beta2026@googlemail.com",
  "canonical_email": "alexdeveloper@gmail.com",
  "status": "DELIVERABLE",
  "score": 0.96,
  "is_valid_format": true,
  "is_disposable": false,
  "is_alias": true,
  "alias_details": {
    "type": "sub_addressing",
    "provider": "google",
    "base_username": "alexdeveloper",
    "tag": "Beta2026",
    "has_dot_mutations": true
  },
  "is_role_account": false,
  "is_catch_all": false,
  "mx_records": [
    "gmail-smtp-in.l.google.com"
  ],
  "smtp_check": {
    "connection_successful": true,
    "mailbox_exists": true,
    "response_code": 250
  },
  "latency_ms": 38
}

10. Frequently Asked Questions (FAQ)

What is the exact difference between an email alias and a disposable email address?

An email alias (such as user+tag@gmail.com or an Apple Private Relay address) forwards directly to a user's permanent, monitored mailbox. The user expects to receive important transactional emails and password resets. In contrast, a disposable email address (e.g., from TempMail or Guerrilla Mail) is a temporary, ephemeral inbox hosted on a burner domain designed to be abandoned after 15 minutes. Disposable emails should be blocked; aliases should be normalized.

Does plus addressing (user+tag@gmail.com) violate RFC email standards?

No. Plus addressing is fully compliant with RFC 5322 and formally defined in RFC 5233. The plus character + is an explicitly allowed ASCII character in the local-part. Web forms that reject + characters with rigid regex validation are violating RFC specifications.

How should our SaaS database store email aliases?

Best practice is to store two separate database columns:

  1. raw_email: The exact string entered by the user (used as the To: address in outgoing transactional emails so the user's mail client filters work).
  2. canonical_email: The stripped, normalized string (local minus dots/tags @domain). A unique database constraint or index (UNIQUE INDEX idx_users_canonical_email ON users(canonical_email)) should be placed on this column to prevent duplicate registrations.

Why do some websites block plus addressing (+)?

Some legacy platforms block + due to outdated regular expressions that only permit alphanumeric characters ([a-zA-Z0-9._%+-]). Other SaaS platforms intentionally block plus addressing at signup to curb free trial abuse and duplicate promo code redemption.

Can an email verification API check if an email alias exists?

Yes. During the simulated SMTP verification handshake, the API queries the recipient mail server (RCPT TO:<user+tag@domain.com>). If the mail server accepts sub-addressing, it returns 250 2.1.5 Recipient OK. The API simultaneously resolves the canonical parent address to ensure baseline mailbox validity.

Are email addresses case-sensitive?

According to RFC 5321, the local-part is theoretically capable of being case-sensitive, while the domain part is strictly case-insensitive. However, in practice, virtually all global mail servers (Google, Microsoft, Apple, Yahoo) treat the local-part as case-insensitive. Always convert email strings to lowercase during normalization.

Does Outlook / Microsoft 365 support the Gmail dot trick?

No. In Microsoft Outlook, Hotmail, and Office 365, john.doe@outlook.com and johndoe@outlook.com are two entirely distinct, independent mailboxes. Removing dots from non-Google domains will corrupt user email addresses.

11. Strategic Conclusion & Developer Checklist

Email aliases are a double-edged sword: they offer legitimate privacy and organization for end-users, but open severe multi-account fraud vectors for SaaS platforms when ignored.

5-Point Engineering Action Checklist:

  • 1. Support RFC 5233 Characters: Ensure frontend and backend validation patterns allow + and - characters without triggering false-positive syntax errors.
  • 2. Maintain Dual Database Fields: Store both raw_email (for message delivery) and canonical_email (for deduplication and identity indexing).
  • 3. Implement Provider-Specific Dot Rules: Strip dots only for Gmail and Google Workspace domains; preserve dots for Microsoft, Yahoo, Fastmail, and Proton.
  • 4. Block Disposable Domains at the Gate: Pair alias normalization with automated zero-day disposable domain filtering to eliminate burner inboxes.
  • 5. Integrate Real-Time API Verification: Validate deliverability, catch-all status, and mailbox health using an ultra-low latency verification engine.

Ready to Protect Your Signup Flow with MailCheck API?

Live Testing Environment

Try the API Live

Don't let fake accounts and disposable emails pollute your database. Test our sub-50ms live validation engine right now.

LIVE VALIDATION ENGINE (EDGE NODE)
❯mailcheck verify
❯ Enter an email address above to test real-time validation and disposable detection.
Integrate in Your Codebase
curl -X POST "https://fadsync-email-validation.p.rapidapi.com/v1/check" \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_API_KEY" \
  -H "X-RapidAPI-Host: fadsync-email-validation.p.rapidapi.com" \
  -d '{"email": "user@example.com"}'

Related Articles

Fallback

SaaS Signup Fraud Prevention: Eliminating Multi-Account Abuse, Credit Card Testing & Bot Signups (2026 Engineering Blueprint)

The complete architectural and security blueprint for eliminating SaaS signup fraud, trial abuse, credit card testing botnets, and alias permutations across Next.js, Express, and FastAPI.

Fallback

Temporary Email Generators: Architecture, Security Risks, and SaaS Defense Blueprint (2026 Guide)

The complete engineering guide to temporary email generator architectures, the financial impact of disposable signups on SaaS, and multi-tier defense middleware.