Protocols & Developer Infra17 min read

SMTP Ports 25, 465, 587 & 2525: The Complete Mail Server Protocol & Security Architecture Guide (2026)

FadSync Team
Security Research & Engineering
FadSync Logo Default

SMTP Ports 25, 465, 587 & 2525: The Complete Mail Server Protocol & Security Architecture Guide (2026)

In internet communications and backend infrastructure engineering, the Simple Mail Transfer Protocol (SMTP) is the fundamental protocol powering global email delivery. Yet, configuring mail servers, client submissions, and transactional delivery pipelines remains one of the most frequent sources of deployment failures, security vulnerabilities, and network blocks.

Whether you are configuring Postfix on a cloud instance, setting up transactional relays in Node.js or Python, or troubleshooting ISP delivery failures, selecting the correct SMTP port (25, 465, 587, or 2525) and encryption protocol (STARTTLS vs Implicit TLS) is critical to ensure delivery and prevent eavesdropping.

graph TD
    subgraph ClientSubmission["1. Client-to-Server Email Submission (MUA to MSA)"]
        App["Web App / Mail Client (MUA)"] -->|Port 587 + STARTTLS (RFC 6409)| MSA1["Submission Agent (MSA)"]
        App -->|Port 465 + Implicit TLS (RFC 8314)| MSA2["Encrypted Submission Agent (SMTPS)"]
        App -->|Port 2525 (Alternative Cloud Relay)| MSA3["Relay Backup (When 25/587 Blocked)"]
    end

    subgraph ServerRelay["2. Server-to-Server Email Relay (MTA to MTA)"]
        MSA1 -->|Port 25 (Standard Relay)| MTA1["Origin Mail Transfer Agent (MTA)"]
        MSA2 -->|Port 25| MTA1
        MSA3 -->|Port 25| MTA1
        MTA1 -->|Port 25 + Opportunistic STARTTLS| MTA2["Recipient Mail Exchange (MX)"]
    end

    subgraph Delivery["3. Final Mailbox Delivery"]
        MTA2 --> MDA["Mail Delivery Agent (Dovecot / Exchange)"]
        MDA --> Inbox["Recipient Inbox"]
    end

Every month, over 25,000 backend engineers, sysadmins, and DevOps professionals search for "smtp port", "port 587 vs 465", and "why is port 25 blocked".

In this comprehensive 2026 architectural guide, we break down the definitive differences between SMTP ports 25, 465, 587, and 2525, dissect the mechanics of STARTTLS vs Implicit TLS handshakes, explain cloud provider port blocking policies (AWS, GCP, Azure, DigitalOcean), and provide drop-in code implementations in Node.js, Python, Go, and OpenSSL CLI.


Table of Contents

  1. The Evolution of SMTP Port Standards (RFC 821 to RFC 8314)
  2. Port 25: The MTA-to-MTA Relay Backbone (Why Cloud Providers Block It)
  3. Port 587: Modern Client Email Submission (RFC 6409 & STARTTLS)
  4. Port 465: Implicit TLS / SMTPS (The IETF Recommended Standard)
  5. Port 2525: The Non-Standard Cloud Alternative
  6. Side-by-Side Comparison Matrix: Ports 25 vs 465 vs 587 vs 2525
  7. Cryptographic Deep-Dive: STARTTLS vs Implicit TLS
  8. The Raw SMTP Protocol Handshake: Step-by-Step Trace
  9. Cloud Provider Port 25 Restriction Policies (AWS, GCP, Azure, DigitalOcean)
  10. Production Code Implementations (Node.js, Python, Go)
  11. Command-Line Diagnostics: Testing Ports with Telnet, Netcat & OpenSSL
  12. Frequently Asked Questions (FAQ)
  13. Strategic Conclusion & Deployment Checklist

1. The Evolution of SMTP Port Standards (RFC 821 to RFC 8314)

The Simple Mail Transfer Protocol was originally specified in 1982 by Jon Postel in RFC 821, which assigned TCP Port 25 for all email routing. In the early days of the ARPANET and early internet, email transmission was unauthenticated, unencrypted, and assumed all connected nodes were trusted academic or military hosts.

As the commercial internet expanded in the 1990s, spam, spoofing, and ISP abuse forced the Internet Engineering Task Force (IETF) and the Internet Assigned Numbers Authority (IANA) to redesign email routing into two distinct phases:

  1. Email Submission (MUA $\rightarrow$ MSA): An authenticated end-user or web app sends an email to their outgoing mail server.
  2. Email Relay (MTA $\rightarrow$ MTA): One mail server transfers messages across the public internet to the recipient's mail exchange (MX) server.
timeline
    title The Chronological Evolution of SMTP Standards
    1982 : RFC 821 establishes Port 25 for all SMTP traffic (Cleartext)
    1997 : IANA assigns Port 465 for SMTPS (Implicit SSL)
    1998 : RFC 2476 establishes Port 587 for Message Submission with STARTTLS
    1998 : IANA revokes Port 465 for SMTP (Reassigned to Cisco Protocol)
    2008 : RFC 5321 updates core SMTP specifications
    2018 : RFC 8314 officially re-standardizes Port 465 for Implicit TLS Submission

2. Port 25: The MTA-to-MTA Relay Backbone (Why Cloud Providers Block It)

Port 25 is the original standard for SMTP communications. Today, it serves a single primary purpose: Server-to-Server Email Relay.

When Google's mail server transfers an email to Microsoft's mail server, the communication happens exclusively over Port 25.

flowchart LR
    MTA_Sender["Sender Mail Server (Postfix / Exim)"] -->|TCP Port 25| MTA_Receiver["Recipient Mail Server (Google / Microsoft MX)"]
    style MTA_Sender fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#fff
    style MTA_Receiver fill:#1e293b,stroke:#22c55e,stroke-width:2px,color:#fff

Why Residential ISPs and Cloud Providers Block Port 25

In the early 2000s, malware-infected residential computers (botnets) established silent SMTP servers on Port 25 to blast millions of spam messages directly to public MX records.

To eradicate this vector:

  • Residential ISPs (Comcast, AT&T, Verizon, Spectrum) block outbound traffic on Port 25 by default.
  • Major Cloud Providers (AWS EC2, Google Cloud Platform, Microsoft Azure, DigitalOcean, Linode, Hetzner) block outbound Port 25 on all new compute instances to prevent their IP subnets from landing on Spamhaus, Barracuda, and SORBS blacklists.

[!IMPORTANT] Production Rule: Never configure your web applications, mobile apps, or backend microservices to submit email via Port 25. Port 25 should only be used by dedicated Mail Transfer Agents listening for inbound internet traffic.


3. Port 587: Modern Client Email Submission (RFC 6409 & STARTTLS)

Defined in RFC 2476 and updated in RFC 6409, Port 587 is the designated standard port for Message Submission (MUA $\rightarrow$ MSA).

When your application or mail client (Outlook, Apple Mail, Thunderbird) submits an email, it connects to Port 587.

sequenceDiagram
    autonumber
    actor Client as Web Application / Email Client
    participant Server as Mail Submission Server (Port 587)
    
    Client->>Server: TCP SYN (Connect to Port 587)
    Server-->>Client: TCP SYN-ACK (220 smtp.domain.com ESMTP)
    Client->>Server: EHLO client.local
    Server-->>Client: 250-STARTTLS, 250-AUTH LOGIN PLAIN
    Client->>Server: STARTTLS
    Server-->>Client: 220 2.0.0 Ready to start TLS
    Note over Client,Server: TLS Cryptographic Handshake Negotiated
    Client->>Server: AUTH LOGIN (Encrypted Credentials)
    Server-->>Client: 235 2.7.0 Authentication successful
    Client->>Server: MAIL FROM:<sender@domain.com>
    Server-->>Client: 250 2.1.0 Sender OK
    Client->>Server: RCPT TO:<recipient@domain.com>
    Server-->>Client: 250 2.1.5 Recipient OK
    Client->>Server: DATA -> [Message Payload] -> .
    Server-->>Client: 250 2.0.0 Message queued for delivery
    Client->>Server: QUIT

Key Architectural Characteristics of Port 587:

  1. Mandatory Authentication: Port 587 requires client authentication (AUTH LOGIN, AUTH PLAIN, or OAuth2 tokens) before accepting messages, eliminating open relay abuse.
  2. Opportunistic Encryption (STARTTLS): The connection begins in plain text, issues the STARTTLS command, and upgrades the TCP socket to TLS encryption before transmitting authentication credentials or message data.
  3. Universally Unblocked: Port 587 is permitted across virtually all residential ISPs, cellular networks, and corporate firewalls.

4. Port 465: Implicit TLS / SMTPS (The IETF Recommended Standard)

Port 465 was originally introduced in 1997 by Netscape for SMTPS (SMTP over SSL). Although initially revoked when STARTTLS was standardized on Port 587, the IETF published RFC 8314 in 2018 ("Cleartext Considered Obsolete"), officially re-designating Port 465 as the preferred port for Implicit TLS Email Submission.

sequenceDiagram
    autonumber
    actor Client as Web Application / Backend Service
    participant Server as Secure Mail Server (Port 465)
    
    Client->>Server: TCP Connect + Immediate TLS Client Hello (Port 465)
    Server-->>Client: TLS Server Hello + TLS Certificate
    Note over Client,Server: Socket Encrypted BEFORE Any Protocol Commands
    Client->>Server: Encrypted EHLO client.local
    Server-->>Client: Encrypted 250-AUTH LOGIN PLAIN
    Client->>Server: Encrypted AUTH Credentials & Email Data
    Server-->>Client: 250 2.0.0 OK Message accepted

Why RFC 8314 Recommends Port 465 Over Port 587:

Under Implicit TLS (Port 465), the TLS handshake occurs immediately upon establishing the TCP connection—identical to how HTTPS (Port 443) operates. There is no initial plaintext exchange, rendering Port 465 completely immune to STARTTLS-stripping Man-in-the-Middle (MitM) attacks.


5. Port 2525: The Non-Standard Cloud Alternative

Port 2525 is not an official IETF RFC standard, but it is supported by almost all major transactional email service providers (SES, SendGrid, Mailgun, Postmark, Brevo).

flowchart TD
    App["Backend Application (Docker / Kubernetes / VPS)"] --> Try587{"Attempt Port 587 (STARTTLS)"}
    Try587 -->|Network Firewall Blocked| Fallback2525["Failover to Port 2525 (Alternative Relay)"]
    Try587 -->|Success| Connected["Connected to SMTP Relay"]
    Fallback2525 --> Connected

When to Use Port 2525:

  • When hosting applications in highly restricted cloud environments or enterprise firewalls where both Port 25 and Port 587 are throttled or blocked.
  • As an automated failover port in your application's SMTP retry logic.
  • Like Port 587, Port 2525 supports standard STARTTLS encryption and requires authenticated credentials.

6. Side-by-Side Comparison Matrix: Ports 25 vs 465 vs 587 vs 2525

Feature / Metric Port 25 Port 465 Port 587 Port 2525
Primary Purpose MTA-to-MTA Relay MUA-to-MSA Submission MUA-to-MSA Submission Cloud Relay Failover
Official IETF RFC RFC 5321 RFC 8314 RFC 6409 None (Industry Standard)
Encryption Type Opportunistic STARTTLS Implicit TLS (SSL) Explicit STARTTLS Explicit STARTTLS
Cleartext Initial Phase? Yes NO (100% Encrypted) Yes (Until STARTTLS) Yes (Until STARTTLS)
Authentication Required? No (Open to MX lookups) YES (Mandatory) YES (Mandatory) YES (Mandatory)
Blocked by Cloud/ISPs? YES (Widely Blocked) Rare Extremely Rare Almost Never
MitM Stripping Immune? No YES No (Without DANE/MTA-STS) No
Recommended Usage Inbound MX Servers only Modern Web & API Apps Legacy & Modern Apps Backup / Fallback

7. Cryptographic Deep-Dive: STARTTLS vs Implicit TLS

Understanding the difference between Explicit (STARTTLS) and Implicit (Direct TLS) encryption is essential for configuring secure email infrastructure.

flowchart TD
    subgraph Explicit_STARTTLS["Explicit Encryption: Port 587 / 2525"]
        A1["1. Connect Plaintext Socket (TCP)"] --> A2["2. Exchange Plaintext EHLO"]
        A2 --> A3["3. Client sends 'STARTTLS' command"]
        A3 --> A4{"4. MitM Attack Check"}
        A4 -->|Attacker Strips STARTTLS| A5["VULNERABILITY: Falls back to plaintext authentication"]
        A4 -->|TLS Handshake Succeeds| A6["5. Encrypt Connection & Send Auth"]
    end

    subgraph Implicit_TLS["Implicit Encryption: Port 465 (RFC 8314)"]
        B1["1. Connect TCP Socket"] --> B2["2. Immediate TLS Handshake (ClientHello)"]
        B2 --> B3["3. Socket Fully Encrypted from Byte 0"]
        B3 --> B4["4. Send Encrypted EHLO & Auth (Zero Cleartext Risk)"]
    end

The STRIPTLS Vulnerability in Port 587

Because Port 587 starts in cleartext, an active network attacker (such as a compromised router or malicious ISP) can perform a STARTTLS Stripping Attack by removing the 250-STARTTLS capability from the server's response.

If your application client is set to "Opportunistic TLS" rather than "Strict TLS (Require TLS)", it will proceed to send credentials in unencrypted plain text.


8. The Raw SMTP Protocol Handshake: Step-by-Step Trace

Below is a complete, annotated transcript of an authenticated SMTP transaction submitting an email via Port 587:

S: 220 smtp.mailserver.com ESMTP Postfix (Ubuntu)
C: EHLO app.internal.production
S: 250-smtp.mailserver.com
S: 250-PIPELINING
S: 250-SIZE 36700160
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN
S: 250-ENHANCEDSTATUSCODES
S: 250 8BITMIME
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
[--- TLS 1.3 Cryptographic Handshake Negotiated ---]
C: EHLO app.internal.production
S: 250-smtp.mailserver.com
S: 250-AUTH LOGIN PLAIN
S: 250 2.0.0 OK
C: AUTH PLAIN dGVzdHVzZXIAcGFzc3dvcmQxMjM=
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<notifications@fadsync.com>
S: 250 2.1.0 Ok
C: RCPT TO:<alex@customerdomain.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "FadSync Alerts" <notifications@fadsync.com>
C: To: "Alex Developer" <alex@customerdomain.com>
C: Subject: Production Health Check Passed
C: Date: Wed, 06 Aug 2026 12:00:00 +0000
C: Message-ID: <unique-uuid-2026@fadsync.com>
C: Content-Type: text/plain; charset=utf-8
C: 
C: All automated microservice health checks passed with 100% uptime.
C: .
S: 250 2.0.0 Ok: queued as 4YvK9s3QzZz1
C: QUIT
S: 221 2.0.0 Bye

9. Cloud Provider Port 25 Restriction Policies (AWS, GCP, Azure, DigitalOcean)

If your architecture involves sending email from cloud virtual machines, you must understand each provider's outbound port policies:

pie title "Outbound Port 25 Policy Across Major Cloud Platforms"
    "Permanently Blocked / Must Use Relay" : 55
    "Blocked by Default (Requires Support Exemption)" : 45

1. Amazon Web Services (AWS EC2)

  • Policy: Port 25 is blocked by default on all EC2 instances and VPC Elastic IPs.
  • Remediation: You can submit a "Request to Remove Email Sending Limitations" form in AWS Support Console, or route via Amazon SES on Port 587 / 465.

2. Google Cloud Platform (GCP)

  • Policy: Outbound connections on Port 25 are permanently blocked on all Compute Engine instances.
  • Remediation: Google does not grant exemptions for Port 25. You must use third-party SMTP relays on Ports 587, 465, or 2525.

3. Microsoft Azure

  • Policy: Outbound Port 25 is blocked for all Virtual Machines, with exemptions granted only to Enterprise Agreement (EA) subscription tiers with established IP reputation.
  • Remediation: Use Azure Communication Services or external relays on Port 587.

4. DigitalOcean & Linode (Akamai)

  • Policy: Port 25 is blocked for all new accounts to prevent spam abuse.
  • Remediation: Accounts with verified identity and 60+ days of billing history can request manual unblocking from customer support.

10. Production Code Implementations (Node.js, Python, Go)

Here are production-ready, secure SMTP client implementations utilizing Port 465 (Implicit TLS) and Port 587 (Explicit STARTTLS):


Implementation 1: TypeScript / Node.js (Nodemailer)

import nodemailer from 'nodemailer';

// Option A: Recommended Implicit TLS (Port 465)
export const secureTransporter = nodemailer.createTransporter({
  host: 'smtp.relayprovider.com',
  port: 465,
  secure: true, // true for 465 (Implicit TLS)
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
  tls: {
    minVersion: 'TLSv1.2',
    rejectUnauthorized: true, // Strict certificate validation
  },
});

// Option B: Standard STARTTLS Submission (Port 587)
export const starttlsTransporter = nodemailer.createTransporter({
  host: 'smtp.relayprovider.com',
  port: 587,
  secure: false, // false for 587 (Upgrades with STARTTLS)
  requireTLS: true, // Enforce strict STARTTLS encryption
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
});

export async function sendTransactionalEmail(to: string, subject: string, body: string) {
  const info = await secureTransporter.sendMail({
    from: '"MailCheck Engineering" <noreply@fadsync.com>',
    to,
    subject,
    text: body,
  });

  console.log(`[SMTP] Message delivered successfully: ${info.messageId}`);
  return info;
}

Implementation 2: Python (smtplib with Strict SSL/TLS)

import smtplib
import ssl
import os
from email.message import EmailMessage

def send_smtp_implicit_tls(recipient: str, subject: str, content: str) -> None:
    """
    Sends email via Port 465 using modern Implicit TLS (RFC 8314).
    """
    smtp_host = os.getenv("SMTP_HOST", "smtp.relayprovider.com")
    smtp_port = 465
    smtp_user = os.getenv("SMTP_USER")
    smtp_pass = os.getenv("SMTP_PASS")

    msg = EmailMessage()
    msg["Subject"] = subject
    msg["From"] = "System Alerts <alerts@fadsync.com>"
    msg["To"] = recipient
    msg.set_content(content)

    # Enforce modern TLS context
    context = ssl.create_default_context()
    context.minimum_version = ssl.TLSVersion.TLSv1_2

    with smtplib.SMTP_SSL(smtp_host, smtp_port, context=context) as server:
        server.login(smtp_user, smtp_pass)
        server.send_message(msg)
        print(f"[SMTP] Successfully dispatched email to {recipient} via Port 465")

def send_smtp_starttls(recipient: str, subject: str, content: str) -> None:
    """
    Sends email via Port 587 using Explicit STARTTLS.
    """
    smtp_host = os.getenv("SMTP_HOST", "smtp.relayprovider.com")
    smtp_port = 587
    smtp_user = os.getenv("SMTP_USER")
    smtp_pass = os.getenv("SMTP_PASS")

    msg = EmailMessage()
    msg["Subject"] = subject
    msg["From"] = "System Alerts <alerts@fadsync.com>"
    msg["To"] = recipient
    msg.set_content(content)

    context = ssl.create_default_context()
    context.minimum_version = ssl.TLSVersion.TLSv1_2

    with smtplib.SMTP(smtp_host, smtp_port, timeout=10) as server:
        server.ehlo()
        server.starttls(context=context) # Upgrade socket
        server.ehlo()
        server.login(smtp_user, smtp_pass)
        server.send_message(msg)
        print(f"[SMTP] Dispatched via Port 587 STARTTLS to {recipient}")

Implementation 3: Go (Golang)

package main

import (
	"crypto/tls"
	"fmt"
	"net/smtp"
	"os"
)

func SendEmailPort465(to, subject, body string) error {
	smtpHost := os.Getenv("SMTP_HOST")
	smtpPort := "465"
	smtpUser := os.Getenv("SMTP_USER")
	smtpPass := os.Getenv("SMTP_PASS")

	auth := smtp.PlainAuth("", smtpUser, smtpPass, smtpHost)

	tlsConfig := &tls.Config{
		ServerName: smtpHost,
		MinVersion: tls.VersionTLS12,
	}

	conn, err := tls.Dial("tcp", fmt.Sprintf("%s:%s", smtpHost, smtpPort), tlsConfig)
	if err != nil {
		return fmt.Errorf("TLS dial failed: %w", err)
	}
	defer conn.Close()

	client, err := smtp.NewClient(conn, smtpHost)
	if err != nil {
		return fmt.Errorf("SMTP client initialization failed: %w", err)
	}
	defer client.Quit()

	if err := client.Auth(auth); err != nil {
		return fmt.Errorf("authentication failed: %w", err)
	}

	if err := client.Mail(smtpUser); err != nil {
		return err
	}
	if err := client.Rcpt(to); err != nil {
		return err
	}

	w, err := client.Data()
	if err != nil {
		return err
	}

	msg := fmt.Sprintf("From: %s\r\nTo: %s\r\nSubject: %s\r\n\r\n%s", smtpUser, to, subject, body)
	if _, err := w.Write([]byte(msg)); err != nil {
		return err
	}

	return w.Close()
}

11. Command-Line Diagnostics: Testing Ports with Telnet, Netcat & OpenSSL

When debugging firewall connectivity or TLS handshake negotiations on a remote server, use these CLI commands:

1. Test Port 587 STARTTLS Connectivity (OpenSSL)

openssl s_client -starttls smtp -connect smtp.sendgrid.net:587 -crlf

Output verification: Confirms certificate chain validity, TLS version (TLSv1.3), and cipher suite.

2. Test Port 465 Implicit TLS Connectivity (OpenSSL)

openssl s_client -connect smtp.sendgrid.net:465 -crlf

3. Check Network Layer Open Ports (Netcat / Nmap)

nc -zv -w 5 smtp.relayprovider.com 587
nc -zv -w 5 smtp.relayprovider.com 465
nc -zv -w 5 smtp.relayprovider.com 2525

12. Frequently Asked Questions (FAQ)

What is the default SMTP port?

The historical default SMTP port is Port 25, defined in RFC 821. However, for modern client application submission, Port 587 (STARTTLS) and Port 465 (Implicit TLS) are the modern standards.

Which port should I use: 465 or 587?

According to RFC 8314, Port 465 (Implicit TLS) is recommended for all new web applications and backend systems because it encrypts the connection immediately without cleartext vulnerability. Port 587 (STARTTLS) is equally acceptable when strict TLS enforcement is enabled.

Why is Port 25 blocked on AWS EC2 and DigitalOcean?

Cloud providers block outbound Port 25 by default to prevent compromised servers or malicious actors from operating automated spam botnets, which damages the cloud provider's public IP reputation.

Is Port 2525 secure?

Yes. Port 2525 is a secure alternative submission port that supports standard STARTTLS encryption and mandatory password authentication. It is commonly used when local firewalls or residential ISPs block Port 587.

What is the difference between SMTPS and SMTP with STARTTLS?

SMTPS (Port 465) uses Implicit TLS, meaning the SSL/TLS tunnel is established before any protocol commands are sent. STARTTLS (Port 587) begins as a plaintext connection and upgrades to TLS upon client request.

Can I send emails over Port 25 from my local laptop?

No. Almost all residential Internet Service Providers (ISPs) actively filter outbound traffic on Port 25. You must configure your mail client or application to use Port 587 or Port 465.


13. Strategic Conclusion & Deployment Checklist

Proper SMTP port selection ensures robust email deliverability, safeguards credentials against eavesdropping, and avoids unexpected network blocks.

5-Point SMTP Production Checklist:

  • 1. Disable Port 25 for Client Submissions: Restrict Port 25 exclusively to inbound MX mail routing.
  • 2. Default to Port 465 or Port 587: Configure backend email dispatchers with modern TLS (TLS 1.2 or TLS 1.3).
  • 3. Enforce Strict TLS Validation: Set rejectUnauthorized: true / requireTLS: true to prevent STARTTLS stripping attacks.
  • 4. Configure Port 2525 as Fallback: Implement automated port failover if Port 587 is blocked by enterprise firewalls.
  • 5. Validate Email Inboxes Before Dispatch: Eliminate hard bounces before sending messages using an ultra-low latency verification API.

Ready to Supercharge Your Email Pipeline 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