Contabo VPS is up, but WordPress/n8n mail never arrives

Find where the message stops

Treat “never arrives” as three different failures. First, WordPress or n8n may not submit the message at all: the plugin, node, credentials, local sendmail-compatible service, or application log may show the break. Second, the VPS may submit it, but a relay, destination network, or receiving provider may reject or filter it. Third, the application may be trying a local mail path or network destination that is unavailable from this server. These failures need different evidence; changing a DNS record cannot fix an application that never submits a message.

For one representative message, write down the trigger, the component that sends it, the configured transport, the destination host and port if applicable, and the response or error at the handoff. Keep WordPress password notices separate from contact forms, and n8n alerts separate from bulk or subscribed mail. A successful send action or queued message is evidence of a handoff only; it is not evidence of inbox delivery.

The key fork is whether the app uses a local path or submits to an external provider. WordPress’s default wp_mail() path depends on server-side mail configuration; an installation can instead use a plugin that submits to an external SMTP service. An n8n email node can likewise submit to an external SMTP host. These are different routes: a local MTA may attempt direct delivery to recipient servers, while authenticated SMTP submission sends to the chosen provider first. Do not assume installing WordPress or n8n configured either route.

Why an open firewall rule may not explain it

Contabo’s port-access help says: “By default, Contabo does not restrict any port access.” It also says server network settings and firewall configuration are the customer’s responsibility. Contabo Firewall is documented as inbound-only, with outbound marked unrestricted; it is inactive until enabled, and once assigned it blocks all inbound traffic under its default behavior. The firewall documentation likewise describes a default rule that drops inbound traffic while leaving outbound traffic unrestricted. These descriptions concern Contabo’s firewall product. They do not describe the state of an operating-system firewall such as UFW, or prove the route from this specific VPS to a specific destination.

An inbound rule for port 25 does not create a process listening on port 25, and it does not establish that an outbound connection to a remote mail server works. If an application uses external SMTP submission, inspect the configured destination and the server’s own outbound rules. If it uses local mail, find out whether a local mail transfer agent is installed, running, and reporting a useful error. Check the app’s actual configuration before changing firewall rules.

Community reports belong in the investigation, but they are not provider policy. A 2021 LowEndTalk report described IPv4 connections to an external host’s destination port 25 as blocked and later said the issue was fixed after contacting Contabo. A separate 2025 Reddit post quoted an SMTP-traffic warning. These are individual experiences, not evidence that Contabo officially blocks ports 25, 465, or 587 by default. If the observed connection failure conflicts with the published default, preserve the destination, address family, time, and error and ask support about that path.

For firewall and SSH context, see the Contabo setup guide. It is an operations companion, not a substitute for mail policy or evidence from the application.

Why PTR matters after a message leaves

If the server itself sends mail, inspect its reverse DNS before treating the issue as a plugin problem. Contabo manages PTR records through Reverse DNS Management in the Customer Panel. Its DNS and rDNS help describes PTR as mapping an IP address back to a hostname and says it is commonly required for mail servers and can improve deliverability. Contabo says many receiving providers check for a valid PTR, and missing or generic rDNS can increase the chance of rejection or spam placement. Its DNS documentation says to set a valid PTR for servers that send email; IPv4 and IPv6 addresses are supported and managed in the Control Panel.

Use a hostname that belongs to the mail identity you operate, and confirm the relevant sending IP and address family before setting a record. PTR is a reverse mapping for an IP; it does not configure forward DNS, authorize a sending domain, create a mailbox, or set WordPress/n8n credentials. Those are separate parts of the mail path. The panel setting can remove one mismatch, but cannot compel a receiving service to accept a message or place it in the inbox.

If an external SMTP provider does delivery, establish which IP it uses and who controls that IP’s reverse DNS. A PTR setting on the Contabo VPS may not describe the relay’s sending IP at all. Trace the transport before changing records.

Why the sending limit is not a port policy

Contabo’s email sending help states that the limit is about 25 emails per minute. It says regularly exceeding it may cause the server to be throttled, and that spamming is against the Terms & Conditions. This is a sending-rate statement; it does not mean port 25 is closed. Contabo’s outgoing-traffic help says outgoing traffic is not blocked by default and reserves throttling under its fair-use policy for unusually high or disruptive usage.

The Terms & Conditions, effective as of December 2025, prohibit spamming mails or webpages associated with spamming and allow Contabo to restrict or block service for violations. A low-volume transactional workload and a bulk campaign are not interchangeable operational choices. Identify what the app sends and how often before diagnosing a limit warning. Do not turn a community-posted warning into a claim about a universal port block or a fixed bandwidth allowance.

When this VPS should not send the mail

Do not make this VPS your bulk marketing sender, or the sole path for messages that need predictable inbox placement, just because its default port policy is permissive. A cold sending IP, a campaign stream, and transactional notices have different operational demands. If a missed password reset or order notice has a meaningful cost, use a transactional mail service or established SMTP relay with the controls and reporting your workload needs. Keep the application on Contabo if it fits; let a dedicated mail provider handle sending where that is the better operating model.

This is the turn in the diagnosis: a successful site deployment and a permissive default network are not proof that direct-to-recipient mail is the right architecture. More RAM, a reinstall, or an unverified plugin switch does not solve sender identity, PTR ownership, receiving-provider decisions, or relay reputation. Setting PTR does not guarantee inbox delivery.

The generic WordPress mail map covers broader submission, DNS, and cost questions. It is a general map, not a Contabo policy page. This article’s Contabo-specific pieces are the Customer Panel PTR workflow, documented sending limit, default port/outbound wording, and distinction between local mail and external SMTP submission.

Check the path in this order

1. Capture the failed event. Record which WordPress action or n8n workflow ran, its time, recipient class, and exact application or plugin error. Do not paste mail passwords or tokens into logs or support requests.
2. Identify the transport. Determine whether WordPress or n8n hands off to local sendmail/MTA or a named external SMTP provider. Record the actual host, port, TLS mode, and account owner from app settings; do not infer them from a tutorial.
3. Follow handoff evidence. Check application logs and, if local MTA is in use, its queue and logs. For external SMTP, use the provider’s submission response and account logs. A local process listening on port 25 says nothing by itself about an outbound route; an inbound firewall scan says nothing about a remote submission path.
4. Check the network layer. Compare the actual destination and address family with OS firewall rules and Contabo Firewall configuration. Contabo documents its firewall as inbound-only and outbound-unrestricted; identify the OS firewall and particular path separately.
5. Check PTR ownership if this VPS sends. In Customer Panel Reverse DNS Management, inspect the PTR for the sending IP, including IPv4/IPv6 as applicable. If an external relay sends, check the relay’s sending identity and ownership instead.
6. Compare sending behavior with policy. Estimate actual rate and message purpose against Contabo’s approximate limit and anti-spam terms. If an individual destination port appears unreachable despite the published default, document the destination and ask Contabo about that case.
7. Decide who should send. For bulk mail or a workload needing predictable operations, choose a suitable dedicated service and monitor rejections, bounces, and complaints. Keep a clear owner for credentials, DNS, retries, and failure alerts.

These steps narrow the fault; they do not certify a sender or promise an inbox result. Keep the evidence with the actual message stream so a later plugin, relay, DNS, or firewall change does not erase the distinction between submission and delivery.

Sources

• Contabo help: Managing port access and OS-level firewall — default port access and firewall scope.
• Contabo docs: Firewall — firewall default behavior.
• Contabo help: Email sending limit — sending rate and spam policy.
• Contabo help: How to reduce outgoing traffic — default outbound wording and fair-use throttling.
• Contabo help: DNS and rDNS management and Contabo docs: DNS management — PTR and panel management.
• Contabo Terms & Conditions — spam-related prohibited use and enforcement terms.
• Reddit: Contabo mail server troubleshooting — individual port 25 report.
• LowEndTalk: Contabo SMTP block — individual IPv4 destination-port report and follow-up.