If you run a clinic server, a branch-office box, or a small ISP’s mail host on a residential or small-ISP connection, the question that eventually arrives is some version of: why won’t my server send mail? The answer is usually not a configuration mistake on your side. It is that the network you sit on has decided, deliberately, that hosts like yours are not expected to originate mail directly to the internet. That decision is called port 25 blocking, and it is an infrastructure policy, not a bug you can tune away.
The productive response is to stop treating outbound mail as a direct-delivery problem and start treating it as a submission-and-relay problem. Your server hands mail to an authenticated submission endpoint; that endpoint carries it onward. You sign with DKIM on your own domain so the responsibility for the message is stated in a way receivers can check. You publish SPF that names the relay. And you write down what happens when the relay is unreachable, because on a one-person team the failure mode is silent deferral, not a page at 3 a.m.
Two roles, one protocol name
SMTP does two different jobs, and conflating them is where most of the confusion starts. One job is transport: one mail server talking to another mail server to move a message toward its destination. The other is submission: a mail client or local agent handing a message to a server that will take responsibility for it.
RFC 5321, the core SMTP specification, is explicit that these are not the same thing in practice. It notes that “the separate mail submission protocol specified in RFC 4409 is now preferred to direct use of SMTP” (RFC 5321, Section 1.2). That sentence is the whole argument in miniature. Direct use of SMTP from your server to a stranger’s mail exchanger is the old model. Submission to a relay that expects you is the current one.
This matters for a constrained operator because the two roles have different requirements. Transport wants a host that receivers will accept a connection from. Submission wants authentication, a relay that knows you, and a queue that survives your link going down. On a residential-grade connection you can usually satisfy the second and almost never the first.
Why port 25 is blocked, and why that is not about you
Port 25 is the traditional SMTP port. It is also the port that infected consumer machines have used for two decades to pump spam and malware without their owners’ knowledge. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) has recommended for years that connectivity providers block it except for hosts explicitly permitted to act as SMTP relays. Their 2023 refresh of that guidance states plainly that “blocking port 25 for all but a few restricted purposes is still considered an industry best practice” (M3AAWG, 2023).
The same document lays out the recommended pattern: provide submission on ports 465 and 587 as described in RFC 6409 and RFC 8314, require authentication as described in RFC 4954, and let customer hosts connect to those submission ports on your network and elsewhere (M3AAWG, Best Common Practices for Managing Port 25 for IP Networks). That is the environment you are operating in. It is not a verdict on your legitimacy. It is a statement about which hosts the network expects to originate mail.
Consumer ISPs implement this directly. Comcast, for example, states that it “does not support port 25 for the transmission of email by our residential Internet customers” and points customers to port 587 with authentication and TLS (Xfinity support). The same page notes that all of Comcast’s dynamic IP address space is listed by Spamhaus as not to be used for sending email. That second point is the one that should shape your design: even if you found a way around the port block, the address itself is on a list that says it should not be originating mail.
Spamhaus describes its Policy Blocklist as covering “IP addresses that are legitimate, but shouldn’t be sending emails” (Spamhaus blocklists). A residential address is legitimate. It is also, by policy, not a mail-originating address. You cannot argue your way out of that with a well-configured server. You can only route around it.
The smarthost pattern, stated as a trade-off
A smarthost is a relay your server submits mail to instead of delivering it directly. On a constrained link this is not a workaround. It is the correct architecture, because it concentrates the parts that need watching — authentication, queueing, bounce handling, reputation — in one place you can reason about, rather than spreading them across a server you cannot fully observe.
The trade-off is real. You now depend on a third party for outbound mail. If the relay is down, your mail queues locally and waits. If the relay changes its authentication requirements, your mail stops. If the relay’s own reputation is poor, your mail suffers for it. You are trading independence for a path that receivers will actually accept. For a one-person team with no second site, that is usually the right trade, but it is a trade, and you should know what you gave up.
What the relay must do, as a checklist rather than a product recommendation:
- Accept authenticated submission on port 587 or 465. Authentication is the point; an open relay is not a smarthost.
- Either preserve your DKIM signature or re-sign with a domain it controls. If it rewrites headers, your signature may break, and you need to know which domain receivers will see.
- Handle bounces in a way you can observe. If bounces go to an address nobody reads, you will not know when mail is failing.
- Give you a way to see queue state or delivery failures. Without that, you are blind between the moment your server hands off and the moment a recipient complains.
If you cannot get those four things from a relay, it is not a smarthost you can operate on a one-person team. It is a black hole with a hostname.
DKIM: what the signature actually asserts
DKIM lets the owner of a signing domain “claim some responsibility for a message by associating the domain with the message” (RFC 6376, Abstract). That claim is validated by a cryptographic signature and by querying the signing domain’s DNS for the public key. It is not a statement that the message is good, or that the sender is trustworthy, or that the message will be delivered. It is a statement that a particular domain is willing to be associated with this message.
Two consequences follow for your design. First, the signature must be applied before the message leaves your administrative domain. RFC 6376 is direct about this: “a message must be signed before it leaves the administrative domain of the Signer” (RFC 6376, Section 2.1). If your relay re-signs, that is a different signature with a different meaning. If it passes your signature through unchanged, your signature is the one receivers check. Know which case you are in.
Second, DKIM depends on DNS. RFC 6376 says so explicitly: “DKIM currently depends on DNS administration and the security of the DNS system” (RFC 6376, Section 1.4). On a constrained link, that dependency is a real operational risk. If your DNS provider has an outage, or your registrar locks your account during a renewal dispute, your DKIM verification fails even though your server is fine. The signature is only as available as the DNS record it points to.
The practical implication: keep your DKIM private key on the server that signs, keep the public key in DNS at a selector you control, and write down who rotates the key and how. A key rotation that nobody performs is a key that eventually gets compromised or expires. On a one-person team, the rotation procedure is the security control.
SPF: naming the relay
SPF answers a different question from DKIM. RFC 7208 describes it as a protocol by which administrative management domains “can authorize hosts to use their domain names in the ‘MAIL FROM’ or ‘HELO’ identities” (RFC 7208, Abstract). DKIM says who takes responsibility. SPF says which hosts may use your domain. A relay design has to satisfy both, and a passing DKIM check does not substitute for an SPF policy that names the relay.
If your smarthost sends on your behalf, your SPF record must include the hosts that will appear in the MAIL FROM or HELO identity. If you publish a record ending in -all, you are telling receivers that hosts not listed are not authorized. RFC 7208 notes that if a domain wants receivers to be able to make negative authorization determinations, it needs to publish records ending in -all or redirect to records that do; otherwise “no definitive determination of authorization can be made” (RFC 7208, Section 2.1).
That is a trade-off with a price. A strict -all record is a clear statement, but it also means that any host you forgot to list — a new relay, a backup path, a vendor’s sending infrastructure — will fail SPF. On a constrained link where you may change relays under pressure, a strict record can turn a routine migration into a deliverability incident. The alternative, a softer record, is less definitive and gives receivers less to work with. Neither is free. Pick one deliberately and write down why.
What actually fails, and what to do about it
The failure modes on a one-person team are not exotic. They are the ordinary ones, and they are silent.
The relay is unreachable. Your link drops, or the relay has an outage. Your server queues mail locally and retries. If nobody is watching the queue, mail accumulates until it expires. The fix is not a clever retry policy; it is a written procedure: check the queue depth daily, know the relay’s status page or support channel, and know what to do if the outage lasts longer than your queue lifetime. RFC 5321 lists retry and timeout behavior for SMTP, but those are protocol defaults, not a monitoring plan.
The DKIM key needs rotation. Keys age. If the person who created the key is the person reading this, the rotation procedure is a document you write once and follow. Publish the new public key at a new selector, switch the signer, verify, then retire the old selector after a transition period. If you skip the transition, mail signed with the old key fails verification during the window when DNS still points at the old record.
DNS changes are staged badly. DKIM and SPF both live in DNS. A change made in a hurry, without checking propagation, can break verification for hours. On a constrained link with a single DNS provider, the safe pattern is to make changes during a window when you can watch, and to verify from an external resolver before assuming the change took effect.
Bounces go nowhere. If the relay sends bounces to an address nobody monitors, you will learn about delivery failures from recipients, not from your own systems. Make sure the bounce address is one a human reads, or that the relay exposes failures in a place you check.
A hypothetical example makes the contrast concrete. A clinic server configured to queue outbound mail locally and retry against a submission relay on port 587 will behave predictably during a link outage: mail waits, the queue is visible, and the retry path is the same one that works when the link is up. The same server configured to attempt direct port 25 delivery will accumulate deferred mail with no clear owner, because the path it is trying was never going to work. The difference is not the server. It is the architecture.
The infrastructure argument
Port 25 blocking is a deliberate anti-abuse policy, and it has real costs for small operators. It forces you onto a relay you may not control, it makes your mail path depend on a third party’s reputation, and it turns a straightforward server configuration into an infrastructure design problem. Those costs are not imaginary, and it is fair to resent them.
But the correct response is not to defeat the block. It is to build on submission relays and authentication, and to escalate to your provider only when you have a documented legitimate need to operate a relay — not when you want your single server to deliver directly. The provider’s policy exists because the alternative, an open port 25 on every residential connection, is worse for everyone including you. Your job is to design a mail path that works within the policy and to write down how you will operate it when things fail.
That is the constraint-first answer. Not a trick to open a port, but a path that names who is responsible at each hop, a signature that says your domain stands behind the message, an SPF record that names the relay, and a runbook for the day the relay is down. The price is a dependency and some paperwork. The failure mode it survives is the one you will actually face: a link that drops, a relay that hiccups, and nobody else on the team to notice.
Questions operators actually ask
Can I just ask my ISP to unblock port 25?
You can ask, but the answer is usually no for residential service, and the block is only half the problem. Even with port 25 open, a residential or dynamic address is likely to be on a policy blocklist that says it should not originate mail. Spamhaus’s Policy Blocklist covers addresses that are legitimate but should not be sending email. Opening the port does not remove the address from that list.
Does DKIM signing make my mail deliverable?
No. DKIM asserts that a domain takes responsibility for a message. It does not assert that the message is wanted, and it does not override a receiver’s decision to reject mail from an address range it does not trust. Signing is necessary for a credible mail path; it is not sufficient for delivery.
Do I need both SPF and DKIM?
They answer different questions, and a relay design should satisfy both. SPF authorizes hosts to use your domain in MAIL FROM or HELO. DKIM associates your domain with the message via a signature. A receiver may check either or both. If your relay sends on your behalf, your SPF record must name it, and your DKIM signature must survive the relay or be replaced by one you understand.
What if my relay rewrites my DKIM signature?
Then the signature receivers check is the relay’s, not yours, and the responsibility asserted is the relay’s domain. That can be acceptable if you trust the relay and understand what it signs. It is not acceptable if you assumed your own domain was standing behind the message. Ask the relay what it does before you depend on it.
How do I know mail is actually leaving?
Watch the queue on your server and the delivery reporting your relay provides. If neither is visible to you, you do not have a mail path you can operate. The first operational investment on a one-person team is visibility into the handoff, not a more elaborate retry configuration.