SMTP (Simple Mail Transfer Protocol) on port 25 is how email moves between mail servers on the internet. When you send mail, your client submits to your provider (usually port 587 with authentication), and your provider relays via port 25 to the recipient's mail server. Port 25 is the server-to-server email transit port.
Port 25 has historically been the source of major email security problems: open relays (mail servers accepting and forwarding mail from anyone, abused for spam), SMTP authentication brute force (attempting credentials against authenticated SMTP submission), email spoofing (forging sender addresses since basic SMTP has no built-in sender authentication), and SMTP service vulnerabilities in various server implementations.
Modern email security on top of SMTP includes: SPF (Sender Policy Framework — DNS records specifying which servers can send mail for your domain), DKIM (DomainKeys Identified Mail — cryptographic signing of outbound mail), DMARC (policy framework combining SPF and DKIM with reporting), STARTTLS (opportunistic TLS encryption between mail servers), and MTA-STS (Mail Transfer Agent Strict Transport Security — enforces TLS for mail delivery).
Standard external assessment includes checking SPF, DKIM, DMARC for client domains. Common findings: SPF too permissive (~all instead of -all), DMARC in monitoring mode (p=none) instead of enforcement, DKIM not configured at all, primary marketing domain protected but parked secondary domains wide open. Each is a valid finding leading to phishing-resistance recommendations.
When investigating suspicious emails, check the headers for SPF/DKIM/DMARC results. Failed authentication on mail purportedly from your domain confirms spoofing. The Email Header Analyzer tool processes this automatically. Useful for determining whether an incident is real spoofing of your domain vs internal account compromise.
Brand protection — monitoring for spoofing attempts
DMARC reports (sent to the address in your DMARC record) show attempted spoofing of your domain — which IPs are sending mail claiming to be from you, what fraction passes vs fails authentication. Aggregate reports paint a picture of who is trying to abuse your domain. Tools like dmarcian, EasyDMARC process these reports into actionable dashboards.
Open-relay testing on internal mail servers
Internal pentest reconnaissance includes testing mail servers for open-relay misconfigurations. Old mail servers accepting unauthenticated relay can be abused for spam from inside the network. Tools: telnet to port 25, attempt to send mail to external address from external sender. Modern mail servers reject this by default; legacy or misconfigured servers may not.
Compliance — email authentication for security frameworks
Most security frameworks expect SPF/DKIM/DMARC deployment. Some specifically require DMARC enforcement (p=quarantine or p=reject) rather than monitoring (p=none). Document your email authentication configuration in compliance evidence; verify regularly with automated checks.
Common mistakes & edge cases
Running open relays in 2026
Open relays (mail servers accepting unauthenticated mail for delivery to any address) were a 1990s spam vector. Modern mail servers default to closed; legacy or misconfigured servers occasionally still allow it. Test your mail servers periodically; close any open relay immediately.
SPF "softfail" (~all) instead of "hardfail" (-all)
~all tells receivers "if the sender does not match my SPF, soft-fail it" — most receivers will still deliver. -all tells them "reject it". Use -all once you are confident your SPF record correctly lists all sending sources.
DMARC stuck in monitoring mode (p=none) forever
p=none collects reports without taking action. Many organisations deploy DMARC at p=none "to monitor first" and never advance. The protection only kicks in at p=quarantine or p=reject. Treat p=none as a temporary deployment phase (60-90 days), then advance to enforcement.
Forgetting parked / secondary domains
Attackers spoof from your less-protected domains. Every domain you own — not just the primary — needs SPF "v=spf1 -all" (no senders) and DMARC "v=DMARC1; p=reject;" published to prevent abuse. Audit DNS for all owned domains; add restrictive policies to non-sending ones.
Not enabling MTA-STS and TLS-RPT
MTA-STS requires receiving mail servers to use TLS. TLS-RPT provides reporting on TLS failures during mail delivery. Both are DNS-based; deploy via TXT records and a small policy file. Modern email providers support both; configuration takes minutes.
Treating email security as IT-only concern
Email security failures damage brand reputation and enable customer-facing phishing. Get marketing, communications, and legal teams aware of DMARC reports — they often see customer reports of phishing claiming to be from you. Cross-functional ownership beats IT-only ownership for sustained email security improvement.
Frequently Asked Questions about port 25
Simple Mail Transfer Protocol — how email moves between mail servers on the internet. Default port 25 for server-to-server transit, port 587 for authenticated client submission, port 465 for legacy implicit-TLS submission. Originally a 1980s cleartext protocol; modern usage adds STARTTLS encryption opportunistically.
Port 25: server-to-server transit (your provider relays to recipient's server). Port 587: authenticated client submission (your mail client to your provider) — modern standard with STARTTLS. Port 465: legacy authenticated submission with implicit TLS — deprecated but still seen.
Sender Policy Framework — a DNS TXT record listing IP addresses authorised to send mail for your domain. Receiving mail servers check the sending IP against your SPF record; mismatch indicates likely spoofing. Format: v=spf1 ip4:1.2.3.4 include:_spf.google.com -all. Use -all (hard fail) once confident in the record.
DomainKeys Identified Mail — cryptographic signing of outbound emails. Your mail server signs each outbound message with a private key; the receiving server verifies the signature using your public key published in DNS. Confirms the message was actually sent by your domain and was not modified in transit.
Domain-based Message Authentication, Reporting & Conformance — a policy framework on top of SPF and DKIM. Tells receivers what to do when SPF or DKIM fails (none = nothing, quarantine = spam folder, reject = bounce). Provides reporting (rua= for aggregate reports, ruf= for forensic reports) so you can see who is attempting to spoof your domain.
A protocol command that upgrades a cleartext SMTP connection to TLS-encrypted. Opportunistic — used if both servers support it, falls back to cleartext if not. Used between mail servers (port 25) and for client submission (port 587). Modern mail servers all support STARTTLS.
Mail Transfer Agent Strict Transport Security — DNS + HTTPS-based mechanism for requiring TLS on inbound mail. Receiving servers publish a policy specifying TLS is required; sending servers refuse to deliver in cleartext. Prevents downgrade attacks where an active attacker forces fallback to cleartext.
Web tools: MXToolbox, dmarcian, EasyDMARC. Command line: dig TXT example.com shows SPF; dig TXT _dmarc.example.com shows DMARC; DKIM verification requires the selector name (varies per email provider).
A mail server that accepts mail from anyone and forwards it anywhere — without authentication. Historically the standard SMTP behaviour; modern servers default to closed (reject relay attempts from unauthenticated senders). Open relays are abused for spam at scale; closing them is basic mail server hygiene.
Trivially. The SMTP protocol allows the sender to claim any From address. Without SPF/DKIM/DMARC, recipient servers have no way to verify whether the claim is legitimate. Attackers send mail claiming to be from your domain — bank fraud, internal-looking phishing, business email compromise. The receiving server delivers it because nothing tells the server to question the From address. SPF/DKIM/DMARC fix this; without them, your domain is unprotected.