PowerMTA Config Generator | PMTA Virtual MTA & DKIM Configuration Tool

📝 Input Data

IP Address

e.g., 3.4.5.6

DKIM Domain

e.g., example.com

HELO/EHLO domain

e.g., ptr.example.com

DKIM Selector

e.g., selector (for domain-key selector)

Auth Username

Auth Password

Virtual MTA Name Prefix

Batch Input (one per line)

Virtual MTA Name Prefix (for all entries)

Client IP|Delivery IP Input

Auth Username

Auth Password

Virtual MTA Name Prefix

PMTA Non-TLS Input (one per line)

Format: IP|Selector|DKIMDomain|HeloDomain|PMTAName (one entry per line)

Domain Macro Name

Name for the domain-macro (e.g., macroname)

TLD Domains (comma-separated)

Domains for the macro (e.g., yahoo.com,gmail.com,outlook.com)

📤 Generated Output

PMTA Configuration

# Enter data and click "Generate Config" to see output

📚 PowerMTA Configuration Guide & Technical Reference

🔌 SMTP Ports: 25 vs 465 vs 587 vs 2525

Understanding SMTP ports is crucial for successful email delivery. Each port serves a specific purpose in the email transmission ecosystem, with different security models and use cases.

Port	Purpose	Encryption Model	Authentication	Recommendation
587 STARTTLS	Message Submission	STARTTLS (Explicit TLS)	Required	✅ Recommended Default
465 SMTPS	Secure Submission	Implicit TLS	Required	⚠️ Legacy/When Required
25	Server-to-Server Relay	Optional/Variable	Not Required	❌ Not for Client Submission
2525	Alternative Submission	STARTTLS (Provider-specific)	Required	🔧 Fallback Option

RFC Standards: Port 587 is defined in RFC 6409 (Message Submission for Mail) as the standard port for authenticated message submission. Port 465 was originally deprecated but restored by RFC 8314 for implicit TLS submission.

Why Port 587 is the Industry Standard

STARTTLS Upgrade: Connection begins in plaintext, then upgrades to TLS via STARTTLS command. This provides flexibility while maintaining security.
Mandatory Authentication: RFC 6409 mandates client authentication, preventing unauthorized relay and spam abuse.
ISP Friendly: Port 587 is widely accepted by ISPs and cloud providers, with less likelihood of being blocked compared to port 25.
Deliverability: Emails sent through port 587 are less likely to be flagged as spam, improving inbox placement rates.
Modern Security: Supports TLS 1.2 and TLS 1.3, with cipher suites like HIGH:!ADH:@STRENGTH for strong encryption.

                        PowerMTA Best Practice: Always configure smtp-listener 3.4.5.6:587 with require-starttls true and require-auth true to ensure secure, authenticated submission. This prevents credential theft and unauthorized relaying while maintaining compliance with modern email security standards.
                    

🔐 DKIM Selector & Domain Keys

DKIM (DomainKeys Identified Mail) provides cryptographic proof that an email was sent by an authorized domain and wasn't modified in transit. The selector is a critical component that allows multiple keys to exist for a single domain.

How DKIM Selectors Work

Selector Purpose: The selector (e.g., "key", "k1", "2024") identifies which DKIM key to use when multiple keys exist for a domain. It appears in the DNS record name: selector._domainkey.example.com
Key Rotation: Selectors enable seamless key rotation. You can publish a new selector/key pair while retiring old ones without disrupting email flow.
Multiple Keys: Different departments or services can use different selectors (e.g., "marketing", "transactional") with separate keys and policies.
DNS Publication: The public key is published in DNS as a TXT record at [selector]._domainkey.[domain]

PowerMTA domain-key Directive

<virtual-mta example> domain-key selector, domain, /path/to/private.key <domain *> dkim-sign yes dkim-identity @example.com </domain> </virtual-mta>

The domain-key directive takes three comma-separated arguments: the selector, the domain, and the private key file path. PowerMTA uses this to sign outgoing messages with RSA-SHA256 encryption.

🌐 Hostname & Email Routing

The hostname in PowerMTA serves multiple critical functions in email routing and authentication. It's not just a label—it's integral to how other mail servers identify and trust your sending infrastructure.

Hostname Functions in PowerMTA

HELO/EHLO Identity: The hostname is sent during the SMTP handshake (HELO/EHLO command) to identify your server to receiving MTAs.
Reverse DNS (rDNS): The hostname should match the PTR record of your sending IP. Mismatches trigger spam filters.
TLS Certificate CN: The hostname must match the Common Name (CN) or Subject Alternative Name (SAN) in your SSL certificate for successful handshake.
Message Headers: PowerMTA can add the hostname to Received headers for traceability (add-received-header yes/no).
Virtual MTA Identification: Each Virtual MTA can have a unique hostname for multi-tenant or multi-domain setups.

Email Routing Mechanism

1. Client connects to PowerMTA on port 587 2. STARTTLS negotiation (TLS 1.2/1.3 handshake) 3. Client authenticates (AUTH LOGIN/PLAIN/CRAM-MD5) 4. PowerMTA selects Virtual MTA based on: - Source IP / Auth username - X-Virtual-MTA header - Pattern-list matching 5. Message queued to domain-specific queue 6. DNS MX lookup for recipient domain 7. Delivery attempt with DKIM signing 8. Bounce/feedback processing

Source Host Selection: The smtp-source-host directive binds a Virtual MTA to a specific IP and hostname, ensuring proper routing and authentication alignment.

🔄 Client|Delivery Architecture

The Client|Delivery-TLS configuration separates the client submission IP from the delivery IP, creating a relay architecture where:

Client IP: The IP address where email clients (MUAs) connect to submit messages via SMTP AUTH
Delivery IP: The IP address used for outbound delivery to recipient MX servers
Separation of Concerns: Client submission and outbound delivery use different network interfaces
Security: Client authentication is enforced on the client IP, while delivery IP handles reputation and routing

Configuration Flow

Client (3.4.5.6) → Authentication → Queue → Relay → Delivery (7.8.9.10) → Recipient MX 1. Client connects to Client IP (3.4.5.6) on port 587 2. STARTTLS handshake established 3. SMTP AUTH authentication (user@123 / password@123) 4. Message queued to Virtual MTA 5. PowerMTA routes to Delivery IP (7.8.9.10) 6. Delivery IP establishes outbound connection to recipient MX 7. DKIM signing applied using delivery IP's domain-key 8. Message delivered with proper SPF/DKIM alignment

                        Use Case: This architecture is ideal when you want to separate your submission infrastructure from your delivery infrastructure. For example, internal clients connect to a private client IP, while a different public delivery IP handles all outbound traffic, protecting your delivery reputation while maintaining flexible internal access.
                    

🔒 TLS Process in PowerMTA: From Connection to Delivery

Transport Layer Security (TLS) in PowerMTA ensures encrypted transmission and authenticated identities throughout the email delivery chain. Understanding this process is essential for maintaining security and deliverability.

Phase 1: Inbound Connection (Submission)

Client → PowerMTA: TCP SYN on port 587 PowerMTA → Client: 220 hostname ESMTP PowerMTA Client → PowerMTA: EHLO client.example.com PowerMTA → Client: 250-STARTTLS (advertises TLS support) Client → PowerMTA: STARTTLS PowerMTA → Client: 220 2.0.0 Ready to start TLS [TLS Handshake Begins] 1. Client Hello (supported cipher suites) 2. Server Hello (selected cipher: ECDHE-RSA-AES256-GCM-SHA384) 3. Certificate Exchange (server cert + chain) 4. Key Exchange (Ephemeral DH/ECDH) 5. Finished Messages (encrypted channel established) [Authenticated Session] Client → PowerMTA: AUTH LOGIN (encrypted) PowerMTA → Client: 235 2.7.0 Authentication successful

Phase 2: Message Processing & DKIM Signing

Header Normalization: PowerMTA canonicalizes headers (relaxed or simple canonicalization) before signing to handle MTA modifications in transit.
DKIM Signature Generation: Using the private key specified in domain-key, PowerMTA generates an RSA-SHA256 signature over selected headers (From, To, Subject, Date, etc.) and the message body.
Signature Injection: The DKIM-Signature header is added with tags: v=1, a=rsa-sha256, d=domain, s=selector, c=relaxed/relaxed, h=header list, bh=body hash, b=signature.
Queue Assignment: Messages are routed to domain-specific queues (e.g., gmail.com, yahoo.com) with per-domain policies.

Phase 3: Outbound Delivery (Relay)

PowerMTA → Recipient MX: TCP SYN on port 25 (or 587 for submission) Recipient MX → PowerMTA: 220 mx.recipient.com ESMTP PowerMTA → Recipient MX: EHLO pmta.example.com Recipient MX → PowerMTA: 250-STARTTLS PowerMTA → Recipient MX: STARTTLS [TLS Handshake - Cipher: TLS_AES_256_GCM_SHA384] PowerMTA → Recipient MX: MAIL FROM:<sender@example.com> Recipient MX → PowerMTA: 250 2.1.0 OK PowerMTA → Recipient MX: RCPT TO:<recipient@gmail.com> Recipient MX → PowerMTA: 250 2.1.5 OK PowerMTA → Recipient MX: DATA [DKIM-Signature header transmitted] Recipient MX → PowerMTA: 250 2.0.0 OK : queued as ABC123

TLS Cipher Configuration

PowerMTA supports configurable cipher suites for compliance with modern security standards:

# High security cipher string smtp-tls-ciphers HIGH:!ADH:@STRENGTH smtp-server-tls-ciphers HIGH:MEDIUM:!ADH:@STRENGTH # TLS Version Control smtp-tls-allow-TLSv1.2 yes smtp-tls-allow-TLSv1.3 yes smtp-tls-allow-SSLv3 no # Disabled for security

                        Security Note: Always disable SSLv3 and TLSv1.0/TLSv1.1 to prevent POODLE and BEAST attacks. Use only ECDHE or DHE key exchange for Perfect Forward Secrecy (PFS), ensuring that compromised long-term keys cannot decrypt past sessions.
                    

❓ Frequently Asked Questions (FAQ)

Q: Why does PowerMTA use port 587 instead of port 25 for message submission?

Port 25 is designated for server-to-server relay and is frequently blocked by ISPs to prevent spam abuse. Port 587, as defined in RFC 6409, is specifically reserved for authenticated message submission from email clients (MUAs) to mail servers (MSAs). It mandates authentication and supports STARTTLS, making it the secure, standard choice for submitting email. Using port 587 improves deliverability and ensures compliance with modern email security practices.

Q: What's the difference between Client|Delivery-TLS and regular Single Entry modes?

Single Entry-TLS: Uses the same IP address for both client submission (receiving mail from users) and delivery (sending mail to recipients).

Client|Delivery-TLS: Separates these functions onto two different IP addresses:

Client IP: Receives authenticated submissions from email clients on port 587
Delivery IP: Handles all outbound delivery to recipient MX servers

This separation improves security by isolating client-facing services from delivery infrastructure, and allows different network configurations for internal vs. external traffic.

Q: How does the DKIM selector work in PowerMTA's domain-key directive?

The selector in domain-key selector, domain, /path/to/key.pem identifies which DKIM key to use for signing. When PowerMTA signs a message, it publishes the selector in the DKIM-Signature header's s= tag. The receiving server looks up the public key in DNS at selector._domainkey.domain.com. This allows multiple keys to coexist for key rotation, departmental separation, or service-specific signing policies. For example, you might use "key2024" for your main domain and "marketing" for promotional emails.

Q: What is a Virtual MTA (VMTA) and why do I need multiple ones?

A Virtual MTA in PowerMTA is a logical sending entity that combines an IP address, hostname, authentication credentials, and delivery policies. Multiple VMTAs allow you to:
• Segment traffic: Separate transactional and marketing mail streams
• IP warmup: Gradually build reputation for new IPs using "cold" and "warm" VMTAs
• Multi-tenancy: Host multiple clients on the same PowerMTA instance
• Failover: Route traffic to backup IPs if primary IPs are throttled
• Domain-specific policies: Apply different retry rates, TLS settings, or DKIM selectors per domain
Each VMTA appears as a separate sending entity to receiving ISPs, allowing granular reputation management.

Q: Why is my hostname important for email deliverability?

The hostname is critical for three authentication mechanisms:
1. HELO/EHLO: The hostname identifies your server during SMTP handshake. It should match your reverse DNS (PTR) record.
2. TLS Certificate: The hostname must match the Common Name (CN) or Subject Alternative Name (SAN) in your SSL certificate for successful TLS negotiation.
3. SPF/DKIM/DMARC: While SPF validates the envelope sender domain, consistent hostnames build sending reputation.

Mismatches between hostname, PTR record, and TLS certificate trigger spam filters at Gmail, Yahoo, and Microsoft. Always ensure smtp-source-host IP hostname aligns with your DNS and certificate infrastructure.

Q: What happens if I don't use TLS in PowerMTA?

Without TLS, your emails are transmitted in plaintext, exposing sensitive content to interception by network attackers. Additionally:
• Authentication credentials (SMTP AUTH passwords) are sent unencrypted, risking account compromise
• DKIM signatures can be stripped or modified in transit, breaking authentication
• Regulatory compliance (GDPR, HIPAA) may be violated by transmitting PII unencrypted
• ISP penalties: Gmail and Yahoo downgrade non-TLS senders and may reject messages entirely
• Man-in-the-middle attacks: Attackers can modify message content or redirect traffic

Always configure require-starttls true and smtp-tls-ciphers HIGH:!ADH:@STRENGTH to enforce encryption.

Q: Can I use port 2525 if 587 is blocked by my ISP?

Yes, port 2525 is an unofficial but widely-supported alternative to port 587. Many ESPs (Email Service Providers) and hosting providers accept connections on 2525 when 587 is blocked by residential ISPs or cloud firewalls. It functions identically to 587 with STARTTLS support. However, since it's not an IETF-recognized port (not assigned by IANA), some corporate firewalls may still block it. It's best used as a fallback when 587 is unavailable. Always verify your specific provider supports port 2525 before deploying.

Q: How does PowerMTA handle email bounces and feedback loops?

PowerMTA processes bounces through several mechanisms:
• DSN (Delivery Status Notifications): For 5xx permanent failures and 4xx temporary deferrals, PowerMTA generates or receives DSNs
• VERP (Variable Envelope Return Path): Encodes the recipient address in the bounce address for automatic identification
• FBL (Feedback Loop): Processes ISP complaint reports (ARF format) from Gmail, Yahoo, Microsoft, etc.
• Webhooks: Real-time HTTP POST of delivery events (delivered, bounced, deferred, spam complaint)
• Accounting files: CSV logs of all delivery attempts for external analysis

Configure bounce-after 4d12h to set retry windows, and use backoff-reroute-to-virtual-mta to move failing traffic to "cold" VMTAs for reputation protection.

📖 RFC References & Standards

RFC 6409: Message Submission for Mail (Port 587 Standard)
RFC 8314: Cleartext Considered Obsolete (Implicit TLS)
RFC 6376: DKIM Signatures (Cryptographic Email Signing)
RFC 7208: SPF (Sender Policy Framework)
RFC 7489: DMARC (Domain-based Message Authentication)
RFC 5321: SMTP Protocol (Core Mail Transfer)

🛡️ Security Best Practices

Always require TLS for both inbound (submission) and outbound (delivery)
Use strong cipher suites: HIGH:!ADH:@STRENGTH
Disable SSLv3, TLSv1.0, and TLSv1.1
Implement DKIM signing for all outbound domains
Configure SPF and DMARC DNS records
Use separate VMTAs for different mail streams
Monitor bounce rates and spam complaints via FBL
Implement rate limiting to prevent IP blacklisting

PowerMTA Config Generator • Built for Email Infrastructure Professionals

Supports PowerMTA 4.0+ • Compatible with Port25, SparkPost, and Momentum MTAs

Copied to clipboard! ✅

⚡ PowerMTA Config Generator