Validating Emails with Plus Addressing (foo+bar@x.com)

As engineers, we're constantly looking for ways to streamline workflows, test scenarios, and organize information. One clever, often underutilized trick in the email world is "plus addressing," also known as sub-addressing or detailed addressing. It allows you to append a "tag" to the local part of your email address, like yourname+tag@example.com. While incredibly useful for managing your inbox, it introduces interesting challenges when you need to validate whether such an email address is actually deliverable.

This article dives into what plus addressing is, why engineers love it, the validation hurdles it creates, and how a robust email validation service like Verifyr tackles these complexities.

What is Plus Addressing and Why Do Engineers Use It?

Plus addressing is a standard feature supported by many major email providers (Gmail, Outlook.com, iCloud Mail, Fastmail, Proton Mail, and many custom mail servers). It works by allowing you to add a + symbol followed by any string (the "tag") to the local part of your email address, before the @ symbol. For example, if your primary email is john.doe@example.com, you can use john.doe+newsletter@example.com or john.doe+jira-alerts@example.com.

When an email is sent to john.doe+tag@example.com, the mail server typically strips the +tag part and delivers the email to the john.doe@example.com mailbox. The key benefit? The original, full address (john.doe+tag@example.com) is often preserved in the email headers, allowing for powerful filtering and organization.

So, why do engineers find this feature so valuable?

• Email Filtering and Organization: This is perhaps the most common use case. You can sign up for different services or newsletters using unique plus addresses.
  • Example 1: Gmail Filtering If you sign up for a service using yourname+service@gmail.com, you can set up a Gmail filter to automatically label, archive, or move emails sent to that specific address. You might create a filter like this:
    • To: yourname+newsletters@gmail.com
    • Action: Apply label "Newsletters", Skip the Inbox (Archive it) This keeps your primary inbox clean and ensures you can easily find emails related to specific subscriptions or interactions.
• Tracking and Debugging: Plus addressing provides a simple way to track where you've used a specific email address. If you start receiving spam at yourname+shadyapp@example.com, you know precisely which service leaked your address.
• Testing and QA: Developers often use plus addresses to simulate multiple user accounts or test different signup flows without needing to create unique email mailboxes for each test. For instance, in an E2E test, you could sign up user+test1@yourdomain.com, user+test2@yourdomain.com, etc., all delivering to the same user@yourdomain.com inbox. This simplifies test setup and teardown considerably.

The Challenge of Plus Addressing for Email Validation

While plus addressing is a boon for users, it presents a unique set of challenges for email validation services. A naive validation approach might misinterpret these addresses, leading to false negatives or inaccurate results.

The core problem lies in how mail servers handle these addresses versus how a validation service needs to infer deliverability.

1. Stripping vs. Literal Interpretation: Most mail servers will strip the +tag part before routing the email to the user's actual mailbox. So, foo+bar@example.com is treated as foo@example.com for delivery purposes. A validation service, however, cannot just strip the tag and validate foo@example.com, because not all domains support plus addressing. If example.com doesn't support it, foo+bar@example.com might be a distinct, non-existent mailbox, or worse, a valid mailbox that just happens to contain a + character literally.

2. SMTP Probe Ambiguity: The most reliable way to validate an email is often an SMTP probe – attempting to initiate a conversation with the target mail server without actually sending an email. When you send an RCPT TO: <foo+bar@example.com> command, the mail server will typically respond with a 250 OK if foo@example.com exists and plus addressing is supported.

   • If the mail server doesn't support plus addressing, it might reject foo+bar@example.com with a 550 No such user here even if foo@example.com is valid.
   • Conversely, if foo@example.com is not valid, but example.com is a catch-all domain, the server might still return 250 OK, obscuring the true status.

3. Local-Part Syntax: The + character is technically valid within the local part of an email address without necessarily implying plus addressing. Some custom mail servers might interpret foo+bar as a literal mailbox name, distinct from foo. This is rare with major providers but critical for a comprehensive validation solution to consider.

These nuances mean that a simple regex to remove the +tag or a basic SMTP check isn't sufficient for accurate validation. You need intelligence to interpret the mail server's behavior correctly.

How Email Validation Should Handle Plus Addressing

A robust email validation service needs a sophisticated approach to plus addressing to provide accurate and reliable results.

1. Intelligent SMTP Probing: The validation service must perform an SMTP probe using the full plus address (foo+bar@example.com). It then needs to analyze the mail server's response.
   • Example 2: SMTP Interaction Let's consider a manual SMTP probe to smtp.gmail.com for a known valid Gmail address validuser@gmail.com: ``` $ telnet alt1.gmail-smtp-in.l.google.com 25 Trying 173.194.76.27... Connected to alt1.gmail-smtp-in.l.google.com. Escape character is '^]'. 220 mx.google.com ESMTP k7si1057790wmg.38 - gsmtp HELO verifyr.com 250 mx.google.com at your service MAIL FROM: sender@verifyr.com 250 2.1.0 OK k7si1057790wmg.38 - gsmtp RCPT TO: validuser+tag@gmail.com 2