Email on a VPS depends on more than just a mailbox and an SMTP server. For messages to reach the inbox, the domain, DNS records, IP address, and server configuration must look trustworthy to the receiving server.
A simplified email delivery flow looks like this: website or email client → SMTP → DNS records → receiving server → SPF/DKIM/DMARC/PTR check → inbox or spam
If a website sends an email from [email protected], the receiving server checks more than the message itself. It verifies whether that server is authorized to send mail on behalf of the domain, whether the message is signed with DKIM, whether a DMARC policy exists, and whether the IP matches the reverse DNS record.
The minimum setup for domain email typically includes:
- MX record — where incoming email should be delivered (required);
- A record — which IP address the mail host points to (recommended);
- SPF — which servers are allowed to send email on behalf of the domain (strongly recommended);
- DKIM — a cryptographic signature for outgoing email (recommended);
- DMARC — a policy for handling messages that fail SPF or DKIM checks (recommended);
- PTR — a reverse DNS record for the VPS IP address (recommended).
The main challenge with email on a VPS is not “starting SMTP.” An SMTP server can be brought up quickly, but that does not guarantee delivery to the inbox. A new IP may have no reputation, port 25 may be blocked by the provider, PTR may be missing, and SPF, DKIM, and DMARC may be misconfigured.
For standard websites, online stores, request forms, notifications, password recovery, and transactional emails, it is often simpler to use an external SMTP service. It handles deliverability, IP reputation, sending logs, bounce processing, and some anti-spam tasks.
Running your own mail server on a VPS makes sense if you need full control over domain email, have administration experience, and know who will manage DNS, IP warm-up, the mail queue, logs, blacklists, security, and updates.
The most common mistakes are failing to configure PTR (it is not mandatory, but recommended), authorizing the wrong server in SPF, enabling an overly strict DMARC policy without testing, not signing messages with DKIM when DMARC is configured, ignoring blacklists, and not checking whether the outbound SMTP port is open.
First, decide whether you need your own mail server at all. Then configure the domain and DNS records, test sending, confirm that DKIM signing works, test DMARC in a non-enforcing mode, and only then consider the mail setup ready to use.
How email delivery from a VPS works
Email on a VPS seems simple only at the first step: a website or email client sends a message via SMTP, and the recipient receives it. In practice, several checks take place between sending the message and its arrival in the inbox.
The receiving server evaluates more than just the message content. It checks the domain, IP address, DNS records, DKIM signature, SPF, DMARC, PTR, and the sender’s reputation.
To understand why emails sent from a VPS are sometimes sent but never reach customers’ inboxes, you first need to understand the delivery path itself.
Flow: website or email client → SMTP → DNS → receiving server
A simplified email delivery flow looks like this: website or mail client → SMTP → DNS records → receiving server → SPF/DKIM/DMARC/PTR check → inbox or spam
For example, a website hosted on a VPS sends an email from [email protected]
First, the website passes the email to an SMTP server. This can be a self-hosted SMTP server on the VPS or an external SMTP service.
The email is then routed to the recipient’s server based on the MX record for the recipient’s domain: Gmail, Outlook, a corporate mail system, or any other mail server. At this stage, the receiving server checks which domain the email came from, which IP address it was sent from, and which DNS records are configured for the domain.
If everything looks correct, the email may be delivered to the inbox. If there are issues with DNS, the signature, IP reputation, or the email content, it may end up in spam or even be rejected.
In other words, SMTP is responsible only for transmitting the email. The decision about whether to trust it is made by the receiving side. That is why the next important question is what exactly it checks.
What the receiving side checks
When an email reaches the receiving server, the server tries to determine whether the sending server is actually authorized to send mail on behalf of the domain.
Several checks are used for this.
SPF indicates which servers are authorized to send email on behalf of the domain. If an email comes from an IP address that is not listed in the SPF record, the receiving server may consider it suspicious.
DKIM adds a cryptographic signature to the email. The recipient verifies it using the public key in DNS. If the signature is present and valid, it confirms that the email is associated with the domain and was not modified in transit.
DMARC defines a policy for emails that fail SPF or DKIM. For example, a domain can ask receiving servers to only monitor failures, send such emails to spam, or reject them.
PTR is a reverse DNS record for an IP address. It shows which domain name is associated with the sender’s IP address. PTR is especially important for mail servers: the absence of a reverse record often reduces trust in the sending server. A PTR record is not strictly required, but it is recommended; many legacy anti-spam systems actively use this check. It should also match what the sender’s mail server provides in the sending request (HELO/EHLO).
In addition to technical records, the receiving server evaluates the IP reputation, whether the server is on a blacklist, the sending frequency, the email content, links, attachments, and user complaints.
This creates an important nuance: an email may be sent successfully from a VPS but still not reach the inbox. A working SMTP server does not necessarily mean good deliverability.
Why an email may end up in spam even with working SMTP
Working SMTP only means that the server can accept an email for sending and attempt to pass it on. It does not guarantee delivery to the inbox.
An email may end up in spam if the domain or server is not trusted enough.
Common reasons:
- No PTR record for the IP;
- SPF does not authorize sending from the current server;
- DKIM does not sign outgoing emails;
- DMARC is configured incorrectly or too strictly;
- The VPS IP address has already been blacklisted;
- The mail server is new and has no reputation;
- The outgoing port is blocked, or emails are being sent unreliably;
- The email content looks like spam;
- The email contains many links, suspicious attachments, or URL shorteners.
For example, a website may successfully send a password reset email. Everything will look normal in the SMTP logs. However, Gmail or Outlook may still send the email to spam if the sender does not sign emails with DKIM or if SPF points to the wrong server.
That is why, after configuring mail, you need to check more than just whether the email was sent. It is important to see where the email was delivered, whether SPF, DKIM, and DMARC passed, which IP address the recipient sees, and whether the server is on a blacklist.
If email is needed for important notifications, orders, inquiries, and password resets, it is sometimes more reliable to use an external SMTP service. Running your own server on a VPS gives you control, but it requires constant attention to DNS, reputation, logs, and security. Next, it is worth looking separately at exactly what needs to be prepared for domain email on a VPS.
What You Need for Domain Email on a VPS
Domain and MX Record
Domain-based email first requires a domain that will be used to send and receive messages. For example, if the email address should look like [email protected], all key records are configured in the DNS zone for example.com.
An MX record is used for incoming mail. It specifies which mail server messages for the domain should be delivered to.
Example:
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.10
In this setup, messages for @example.com should be delivered to mail.example.com, and mail.example.com itself points to the VPS IP address.
It is important not to confuse MX with SMTP for sending mail. MX handles incoming mail: where other servers will deliver messages. Sending mail requires an SMTP server and the correct DNS records that confirm authorization to send messages on behalf of the domain.
Some anti-spam systems check for the presence of an MX record, but they are fairly rare, so if you do not plan to receive mail, you can skip creating an MX record.
Once the domain and MX record are ready, the next question is what exactly to use for sending mail: your own SMTP server on a VPS or an external SMTP service.
SMTP Server for Sending Email
An SMTP server is responsible for sending email. It can send messages from a website, a CRM system, an email client, or an application running on a VPS.
There are two options.
The first is to set up your own mail server on a VPS. In this case, the administrator configures SMTP, mail queues, TLS, DKIM signing, users, logs, spam protection, and sending limits.
The second is to use an external SMTP service. In this case, the website or application sends email through a third-party provider, which then handles delivery, IP reputation, bounce processing, and some anti-spam tasks.
Running your own SMTP server gives you more control but requires more maintenance. You need to monitor the mail queue, logs, updates, open ports, IP reputation, and whether the IP has been blacklisted.
An external SMTP service is simpler for transactional email: requests, receipts, notifications, password resets, and registration emails. This is especially true if you do not need to handle full-fledged incoming mail on the VPS.
Whichever option you choose, the domain must tell receiving servers who is authorized to send email on its behalf. This requires SPF, DKIM, and DMARC.
SPF, DKIM, and DMARC
SPF, DKIM, and DMARC are three basic checks that help receiving servers determine whether an email can be trusted.
SPF specifies which servers are allowed to send mail on behalf of a domain. If mail is sent from a VPS, the SPF record must allow the IP address or hostname of that VPS. If an external SMTP service is used, its hostnames and addresses, or an include entry, must be added to SPF.
DKIM signs an email with a cryptographic signature. The private key is stored on the sending server, and the public key is published in DNS. The recipient verifies the signature and can determine that the email was not modified in transit.
DMARC ties SPF and DKIM together into a single policy. It tells the receiving server what to do if an email fails authentication: do nothing, send it to spam, or reject it.
At first, DMARC is usually not put into a strict mode right away. It is better to start with monitoring, review the reports, and make sure legitimate emails pass SPF and DKIM.
Example of a soft policy: v=DMARC1; p=none; rua=mailto:[email protected]
This approach helps avoid breaking email delivery from the website, CRM, external SMTP service, or other services that also send email on behalf of the domain.
Once SPF, DKIM, and DMARC are configured, one more important check remains that is often overlooked: the reverse DNS record for the IP address.
PTR Record for an IP Address
A PTR record is a reverse DNS record. It maps a server’s IP address to a domain name.
If a standard A record answers the question “which IP address does this domain point to,” a PTR record answers the reverse question: “which name corresponds to this IP address.”
This is important for a mail server. Receiving servers sometimes check whether the IP address has a reverse DNS record and whether the name resembles the mail host that is sending the message.
Example logic:
mail.example.com → 203.0.113.10
203.0.113.10 → mail.example.com
A key point about PTR records is that they are configured not by the domain owner, but by the owner of the IP address. For a VPS, this is usually done in the provider’s control panel or by contacting support. The domain owner typically cannot change the reverse record for the IP address directly.
If there is no PTR record, messages may be more likely to end up in spam or be rejected, especially if the server sends mail directly to major email systems.
However, even a correct PTR record will not ensure delivery if the IP address already has a poor reputation or the mail ports are blocked.
Open Ports and IP Reputation
For email, DNS records are not the only important factor; network restrictions also matter. Some VPS providers block outbound port 25 to prevent spam from new servers.
Port 25 is typically used to deliver email between SMTP servers. If it is blocked, a self-hosted mail server may not be able to send messages directly to other mail systems.
Ports 587 or 465 are more commonly used for sending mail through an external SMTP service. They are intended for authenticated submission and are generally suitable for websites, applications, and email clients.
Before configuring your own SMTP server, check the following:
- Whether the provider allows outbound port 25;
- Whether a PTR record can be configured for the IP address;
- Whether the IP address is on a blacklist;
- Whether the IP address has previously been used for spam;
- Whether there are sending limits;
- Whether the required ports are open in the firewall.
IP reputation is especially important for a new VPS. Even if SMTP, SPF, DKIM, DMARC, and PTR are configured correctly, a new or suspicious IP address may be treated as untrusted by major email providers and anti-spam systems.
For this reason, it is often better to use an external SMTP service for important emails, such as registrations, orders, inquiries, payments, and password recovery. If you still need your own mail server, start with the minimum set of DNS records and carefully test delivery.
Minimum DNS Records Required for Email
MX: where to accept mail
An MX record is responsible for incoming mail. It tells other mail servers where to deliver messages for the domain.
If mail needs to work for addresses such as [email protected], the DNS zone for example.com must contain an MX record.
Example: example.com. MX 10 mail.example.com.
In principle, a single MX record is enough, but to avoid issues during troubleshooting and when some systems behave unpredictably, it is best to configure mail.example.com so that it also points to the mail server’s IP address. An A record can be used for this: mail.example.com. A 203.0.113.10
The number 10 is the priority of the MX record. The lower the number, the higher the priority. If there are multiple mail servers, the sending side will try the server with the lower priority value first.
For a single VPS, one MX record is usually enough. However, it is important that it points to an actual mail host, not simply to the website’s primary domain without a configured mail server.
Once incoming mail knows where to go, you also need to tell receiving servers who is allowed to send mail on behalf of the domain. SPF is used for this.
SPF: Who Is Allowed to Send Email
An SPF record indicates which servers are allowed to send email on behalf of a domain. It is a TXT record in DNS.
If email is sent from a VPS, SPF must authorize the IP address of that VPS: example.com. TXT “v=spf1 ip4:203.0.113.10 -all”
With this record, the domain is saying that email from example.com may be sent from IP address 203.0.113.10, and all other sources should not be treated as authorized.
If an external SMTP service is used, the SPF record usually looks different. The service often provides a ready-made include record that needs to be added to DNS.
Example illustrative record: example.com. TXT “v=spf1 include:spf.smtp-provider.example -all”
If email is sent both from a VPS and through an external SMTP service, both sources must be included in a single SPF record: example.com. TXT “v=spf1 ip4:203.0.113.10 include:spf.smtp-provider.example -all”
In addition to IP addresses, you can use names or even just mechanisms. For example, “a” means the addresses in the domain’s A records, “mx” means its MX records, and so on. You can also use qualifiers so the recipient’s mail server knows what to do with the messages. “-” means reject, “~” means accept but mark as softfail, “?” means no policy, and “+” means pass (it can be omitted).
In other words, the record in the example above says that we allow sending from the IP address, include the sending service’s records, and reject everything else (-all).
A common mistake is creating multiple SPF records for a single domain. You should not do this. SPF must be a single TXT record that lists all authorized sources.
However, SPF only verifies that a server is allowed to send the message. It does not protect the message content from being modified in transit. That requires DKIM.
DKIM: How to Sign Outgoing Email
DKIM adds a digital signature to outgoing email. The sending server signs the message with a private key, and the recipient verifies the signature using a public key published in DNS.
A DKIM record is usually a TXT record for a special subdomain. The name depends on the selector. For example, if the selector is named default, the record might look like this: default._domainkey.example.com. TXT “v=DKIM1; k=rsa; p=PUBLIC_KEY”
Here, PUBLIC_KEY is the long public key provided by the mail server, control panel, or external SMTP service.
If DKIM is configured correctly, outgoing messages include a DKIM-Signature header. The receiving server verifies the signature and can determine that the message is genuinely associated with the domain and was not modified after it was sent.
A common mistake is adding a DKIM record to DNS but not enabling signing on the SMTP server itself. In that case, the public key exists, but messages are not signed.
The opposite can also happen: the server tries to sign messages, but DNS contains the wrong key or the wrong selector. In that case, DKIM validation fails.
SPF and DKIM help verify the sender. But the domain also needs to specify what to do with messages that fail these checks. DMARC is used for this purpose.
DMARC: what to do with messages that fail authentication
DMARC is a TXT record that defines the policy for messages that fail SPF or DKIM checks.
At first, it is best to use a monitoring-only mode: _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
The p=none policy does not instruct recipients to reject messages. It is used to review reports and understand which services are actually sending mail on behalf of the domain.
After reviewing the results, you can move to a stricter policy: _dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Only after testing should you move to rejecting suspicious messages: _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
An overly strict DMARC policy without proper preparation can break legitimate sending. For example, a website, CRM, helpdesk, or external SMTP service may send messages on behalf of the domain, but SPF or DKIM may not be configured for them. With p=reject, those messages may start being rejected.
That is why DMARC should be introduced gradually: first none, then report analysis, SPF and DKIM fixes, and only then quarantine or reject.
But even SPF, DKIM, and DMARC do not address another important issue: how the mail server’s IP address appears to the outside world.
PTR: reverse DNS record for an IP address
A PTR record maps an IP address to a domain name. For a mail server, it is an important trust signal.
If the A record works like this: mail.example.com → 203.0.113.10
Then the PTR record should return the reverse mapping: 203.0.113.10 → mail.example.com
You can check the PTR record like this: dig -x 203.0.113.10 +short
Or with host: host 203.0.113.10
PTR records are usually configured not in the domain’s DNS zone, but by the owner of the IP address. For a VPS, this usually means using the provider’s control panel or contacting support.
The PTR record should be meaningful. For a mail server, it is better to use a name such as mail.example.com rather than a random technical hostname assigned by the provider.
Consistency is also recommended:
mail.example.com → VPS IP address
VPS IP → mail.example.com
However, the match between the VPS IP address and the name is not the only important factor; what matters most is that it matches the sending server’s greeting. When a server sends an email and connects to the recipient’s SMTP server, it sends a greeting (HELO\EHLO) containing its name. The key requirement is that the IP address used for the connection matches that name.
If the PTR record is missing or points to a random name, major mail systems may trust messages from that server less. In some cases, messages will be more likely to end up in spam or be rejected.
A minimal DNS configuration for email is not a single record, but a set of records: MX for incoming mail, SPF for authorized senders, DKIM for signing, DMARC for policy, and PTR for trust in the IP address. After that, you can decide whether to host email on your own VPS or whether it is simpler to hand off sending to an external SMTP service.
When to Use an External SMTP Service
Website Transactional Emails
If a website needs email for registration, password recovery, inquiries, receipts, orders, and notifications, an external SMTP service is often more convenient than running your own mail server on a VPS.
Transactional emails need to be delivered quickly and reliably. Users are waiting for a verification code, a password reset link, or an order email, so messages ending up in spam is especially critical here.
An external SMTP service takes over some of the tasks that are difficult to maintain manually:
- The reputation of sending IP addresses;
- Delivery logs;
- Bounce handling;
- Sending limits;
- Open and error statistics;
- Protection against sudden spikes;
- Recommendations for SPF, DKIM, and DMARC.
In this setup, the website does not send email directly from the VPS. It connects to the SMTP service over an authenticated connection, typically through port 587 or 465, and hands the messages off to it.
This is especially convenient for WordPress, online stores, CRM systems, SaaS projects, and user portals. The VPS handles the website, while a dedicated SMTP service handles email delivery.
If transactional email has already been moved to an external SMTP service, the next question is what to do with bulk notifications and email campaigns. The requirements there are even stricter.
Email campaigns and notifications
For bulk email, running your own SMTP server on a VPS is usually a poor choice. Even if the server can technically send a thousand emails, that does not mean email systems will treat that activity as normal.
Bulk sending quickly affects the reputation of both the IP address and the domain. If users complain, emails are often deleted unread, or the campaign looks suspicious, mail from that domain and those IP addresses may start to be delivered less reliably, even for standard transactional emails.
For email campaigns, the following are important:
- Subscription management;
- One-click unsubscribe;
- Complaint monitoring;
- Bounce handling;
- Sending limits;
- Audience segmentation;
- Delivery statistics;
- Domain and IP warm-up;
- Compliance with anti-spam requirements.
External email campaign services and SMTP providers are better suited to these tasks. They provide tools that a self-built mail server typically lacks, and configuring them requires specialized expertise.
You also should not mix everything in a single stream. Transactional emails and marketing campaigns are better kept separate: using different subdomains, different sending streams, or different services. This way, problems with an email campaign will not immediately affect password reset emails or order emails.
Even when sending volume is low, an external SMTP service often reduces risk. This is especially true when the VPS is new and its IP address does not yet have an established email reputation.
A New VPS with No Email Reputation
A new VPS usually has no email sending history. This may be fine for a website, but to email systems, such an IP address looks unknown.
Major email services evaluate more than just SPF, DKIM, and DMARC. They look at IP and domain reputation, sending frequency, user complaints, bounce history, and signs of spam.
If a new VPS immediately starts sending a large volume of email, it may look suspicious. Even correctly configured DNS records do not guarantee inbox placement.
The problem becomes worse if the IP address was previously used by another customer of the provider and has already ended up on a blacklist. The new VPS owner may receive an address with a poor history and run into issues even before sending any legitimate email.
For this reason, it is often safer for a new project to start with an external SMTP service. It already has sending infrastructure, deliverability monitoring, and clear requirements for DNS records.
It is better to run your own mail server on a VPS when you have time for warming up, monitoring, blacklist checks, PTR configuration, and log analysis. If those resources are not available, an external SMTP service will be more practical.
Another scenario is when sending directly from the VPS is impossible because of the provider’s network restrictions.
When the Provider Blocks Outbound SMTP
Some VPS providers block outbound port 25. This is done to prevent spam: new servers are often used for bulk unsolicited email, so providers restrict direct mail delivery.
If port 25 is blocked, your own SMTP server may be able to accept messages from the website, but it will not be able to deliver them properly to external mail servers.
This should be checked before setting up a full mail system. If the provider does not allow outbound SMTP, or only enables it after a support request, running your own mail server may not make sense.
In this case, an external SMTP service solves the problem. The website or application connects to it over port 587 or 465, authenticates, and sends email through the SMTP provider’s infrastructure.
This option is especially convenient if the VPS is primarily needed for a website or application rather than a full mail server. The server remains simpler, the risk of blacklisting is lower, and you do not have to maintain the entire mail infrastructure yourself.
Ultimately, an external SMTP service is worth choosing when stable delivery, clear logs, and less manual administration matter most. Running your own mail server on a VPS only makes sense when you genuinely need control over email and are prepared to maintain DNS, PTR, DKIM, DMARC, queues, IP reputation, and handle delivery errors.
Common Mistakes When Configuring Email on a VPS
No PTR record
The PTR record is often overlooked because it is not configured in the same place as the domain’s regular DNS records. A, MX, SPF, DKIM, and DMARC are usually added to the domain’s DNS zone, while the PTR record is configured by the owner of the IP address—that is, the VPS provider.
For a mail server, this is critical. Receiving servers expect the sender’s IP address to be associated with a proper domain name, rather than looking like a random address from a hosting pool.
You can check the PTR record like this: dig -x 203.0.113.10 +short
In a normal configuration, the IP address should return a meaningful hostname, for example: mail.example.com.
Ideally, forward and reverse DNS should also be consistent:
mail.example.com → 203.0.113.10
203.0.113.10 → mail.example.com
Also, the mail server must be configured so that this same name – in our case mail.example.com – is presented in the SMTP session greeting.
If there is no PTR record or it points to the provider’s technical hostname, emails may be more likely to end up in spam or be rejected. This must be fixed through the VPS provider’s control panel or by contacting support.
Once the PTR record is configured, the next common source of errors is SPF. The issue there is usually not that the record is missing, but that it authorizes the wrong sending source.
SPF authorizes the wrong server
SPF must list all servers that are allowed to send email on behalf of the domain. If a message is sent from a VPS but SPF authorizes only an external SMTP service, the check may fail.
The reverse is also true: if the site sends email through an external SMTP service but SPF authorizes only the VPS IP address, the receiving side will see a mismatch.
Example SPF record for sending from a VPS: v=spf1 ip4:203.0.113.10 -all
Example SPF record for an external SMTP service: v=spf1 include:spf.smtp-provider.example -all
If both sources are used, they must be combined into a single SPF record: v=spf1 ip4:203.0.113.10 include:spf.smtp-provider.example -all
A common mistake is adding two different SPF records for the same domain. This is not allowed: SPF must be a single TXT record listing all authorized sources.
You can check SPF using DNS: dig TXT example.com +short
If SPF is configured incorrectly, messages may still be sent from the server, but they may be accepted with an SPF fail flag or sent to spam.
However, even a correct SPF record does not guarantee that a message will be trusted. For domain email to work properly, outgoing messages should also be signed with DKIM.
DKIM is not signing messages
DKIM is often configured only as a formality: a TXT record is added to DNS, and the task is considered complete. However, the presence of a DNS record does not mean that messages are actually being signed.
For DKIM to work, two components must be in place:
- The SMTP server signs outgoing messages with a private key;
- the public key for the corresponding selector is published in DNS.
You can check the DKIM record as follows: dig TXT default._domainkey.example.com +short
Here, default is the selector. In a real configuration, it may have a different name: mail, dkim, selector1, s1, or whatever the email service specifies.
If the record exists but messages do not get a DKIM-Signature header, signing is not enabled on the SMTP server or in the application.
If the header is present but the DKIM check fails, there may be other causes:
- The wrong key is published in DNS;
- A different selector is being used;
- The message is modified after signing;
- An external SMTP server signs with a different domain;
- The DKIM record was added incorrectly or truncated.
The easiest way to verify the result is to check the headers of the received message. In Gmail, for example, you can open “Show original” and see whether SPF, DKIM, and DMARC passed.
Once SPF and DKIM are working, you can move on to DMARC. However, it is important not to enable a strict policy too early.
DMARC is set too strictly without testing
DMARC helps protect a domain from email spoofing, but if enabled incorrectly, it can disrupt legitimate email sending.
The riskiest scenario is to apply a strict policy right away: v=DMARC1; p=reject; rua=mailto:[email protected]
If all sending sources have not been verified by that point, some legitimate emails may start being rejected. For example, emails from a website, CRM, helpdesk, external SMTP server, or email marketing service may fail SPF or DKIM checks.
At the start, it is safer to use monitoring mode: v=DMARC1; p=none; rua=mailto:[email protected]
This allows the domain to receive reports without asking receiving servers to reject emails.
After analyzing the reports and fixing SPF/DKIM, you can move to a stricter policy: v=DMARC1; p=quarantine; rua=mailto:[email protected]
Only after testing should you move to p=reject.
DMARC is best implemented gradually. Otherwise, you may end up in a situation where protection against spoofed emails also blocks your own notifications, requests, receipts, and password recovery emails.
However, even perfect DNS records will not help if the IP already has a poor reputation. Therefore, the next layer of checks is blacklist screening.
The server has been blacklisted
A blacklist is a list of IP addresses or domains suspected of spam, malicious activity, or high-volume unsolicited email.
If the VPS IP address is on such a list, email deliverability may suffer even with valid SPF, DKIM, DMARC, and PTR records.
There can be several reasons:
- The IP address was previously used for spam by another customer;
- The server was compromised and used to send email;
- The application sends too many notifications;
- No sending limits are configured;
- Users complain about the emails;
- Mailings are sent without consent and without an unsubscribe option.
It is best to check blacklists using several public IP reputation checking services. It is also useful to review the mail server logs: they may contain responses from receiving servers with error codes and links to the specific blacklist.
If the server is blacklisted, simply submitting a removal request is not enough. You must first eliminate the cause: disable open sending, review user accounts, change passwords, restrict relay, stop any suspicious mailing, and make sure the server has not been compromised.
After that, you can address delisting. However, for important emails in this situation, it is often faster to temporarily switch to an external SMTP service to avoid losing registrations, orders, and inquiries.
Sometimes the issue is not reputation at all, but the fact that email cannot leave the VPS because outbound SMTP is blocked.
Outbound Port Is Blocked
Some VPS providers block outbound port 25. This is a common anti-spam measure, especially on new servers and low-cost plans.
Port 25 is required for delivering email between mail servers. If it is blocked, your own SMTP server may be able to accept a message from the website, but it will not be able to send it on to Gmail, Outlook, or another external mail server.
The symptoms may look like this:
- Emails remain stuck in the queue;
- The logs show connection timeouts;
- Sending to external domains fails;
- Local sending works, but external sending does not;
- The mail server keeps retrying delivery.
You should check the mail server logs and network connectivity to external SMTP servers. If the provider blocks port 25, it can sometimes be opened by submitting a support request. However, not all providers allow this.
For websites and applications, it is often easier to use an external SMTP service over port 587 or 465. In this case, the VPS does not deliver email directly between mail servers; instead, it authenticates with the SMTP provider and sends messages through it.
If the outbound port is blocked, there is no point in endlessly adjusting SPF, DKIM, or DMARC. These records are important, but they will not enable network access for sending. First, determine whether the VPS can send mail externally at all, and only then work on deliverability.
Ultimately, most email issues on a VPS come down to one thing: sending must be not only technically possible, but also trusted. This requires correct DNS records, a PTR record, a working DKIM signature, a carefully configured DMARC policy, a clean IP reputation, and an open path for outbound mail.
What to Check After Configuring Email
After configuring email on a VPS, you need to check more than just whether a mailbox was created or whether a test message was sent successfully. A message may leave the server but end up in spam, fail DKIM validation, be sent from the wrong IP address, or get stuck in the queue.
First, check the domain’s DNS records:
dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +short
If DKIM is used, check the record with the required selector: dig TXT default._domainkey.example.com +short
The selector may be different. Check it in the mail server settings, the control panel, or the external SMTP service.
Next, check the PTR record for the VPS IP address: dig -x 203.0.113.10 +short
Ideally, the PTR record should return a recognizable mail server name, such as mail.example.com, and that name should resolve back to the VPS IP address.
After checking DNS, send a test message to several different email systems: Gmail, Outlook, corporate email, and another external mailbox. This makes it easier to determine whether the issue is general or occurs only for a specific recipient.
It is also a good idea to use dedicated services that let you send a test email and receive a score with comments and all checks.
Check the headers of the received message. Make sure SPF, DKIM, and DMARC pass validation. In Gmail, you can view this via “Show original.”
You should also check:
- Whether the message landed in the inbox or in spam;
- Which IP address is listed as the sender;
- Whether the sender domain aligns with SPF/DKIM/DMARC;
- Whether the message is signed with DKIM;
- Whether sending from the website, CMS, CRM, or application works correctly;
- Whether messages are getting stuck in the queue;
- Whether there are any errors in the mail server logs;
- Whether the IP address is on a blacklist;
- Whether outbound SMTP is open if you are using your own server.
If email is used for a website, separately test all important scenarios: registration, password recovery, request forms, order notifications, payments, system emails, and replies to customers.
For an external SMTP service, make sure the website or application sends messages through that service specifically, rather than through local sendmail or the built-in PHP mail() function without proper authentication and signatures.
After testing, it is useful to document the working setup: which DNS records are used, which SMTP service handles sending, where DKIM is configured, which DMARC policy is enabled, who manages the PTR record, and how to view delivery logs.
Conclusion
Email on a VPS is more than just an SMTP server and a mailbox. Reliable delivery requires a properly configured combination of domain, DNS records, IP address, PTR, SPF, DKIM, DMARC, open ports, and sender reputation.
If even one component is configured incorrectly, messages may leave the server but end up in spam, be rejected by the receiving server, or fail to be delivered at all because of network restrictions.
A minimal domain email setup includes MX records for incoming mail, SPF for authorized senders, DKIM for signing messages, DMARC for the validation policy, and PTR for the IP address’s reverse DNS record.
However, running your own mail server on a VPS is not always necessary. For transactional website emails, notifications, form submissions, receipts, password recovery, and email campaigns, it is often more practical to use an external SMTP service. It reduces the administrative burden and helps with deliverability, logs, and the reputation of sending IP addresses.
Self-hosted email on a VPS makes sense if you need full control and are prepared to maintain the server: monitor logs, the mail queue, blacklists, security, updates, DNS, and domain policies.
The right approach is to first choose the sending model: your own SMTP server or an external service. Then configure DNS, verify SPF/DKIM/DMARC/PTR, send test messages, review the headers, and make sure important emails do not just arrive “somewhere,” but specifically land in the inbox.
FAQ
Can I set up email on a VPS myself?
Yes. You can run your own mail server on a VPS and configure the domain, MX, SMTP, SPF, DKIM, DMARC, PTR, TLS, mailboxes, and outbound email.
However, email on a VPS requires ongoing maintenance. You need to monitor logs, the mail queue, updates, security, IP reputation, blacklists, and the accuracy of DNS records.
If you only need email for inquiries, notifications, orders, registration, and password recovery, it is often easier to use an external SMTP service. Running your own server makes sense when you need full control over email and have administration experience.
Which matters more for email deliverability: SPF, DKIM, DMARC, or PTR?
It is better to think of them not as competing mechanisms, but as a set that works together.
SPF indicates which servers are authorized to send email on behalf of a domain. DKIM signs the message and helps verify that it has not been modified. DMARC defines the policy for messages that fail SPF or DKIM. PTR maps the sender’s IP address to a domain name and helps the receiving side evaluate the server.
Cloudflare describes SPF, DKIM, and DMARC as three email authentication methods that work together to help protect a domain from sender spoofing.
For a VPS, PTR is also especially important because many mail systems place less trust in servers that do not have a proper reverse DNS record.
Why do emails sent from a VPS end up in spam?
There can be many reasons. The most common are a missing PTR record, an incorrectly configured SPF record, emails not being signed with DKIM, DMARC being configured incorrectly, the IP address already being on a blacklist, or a new server not yet having any email reputation.
The content of the email also matters: suspicious links, attachments, URL shorteners, sending too frequently, user complaints, and the lack of a proper unsubscribe option for newsletters.
In its sender guidelines, Gmail states that the domain must pass SPF or DKIM, and that for DMARC to pass, the email must be authenticated with SPF or DKIM with alignment to the domain in the From header.
That is why you need to check not only whether the email was sent, but also the headers of the received message: whether SPF, DKIM, and DMARC passed, which IP address was used, and where the email ended up.
Can you send email without a PTR record?
Technically, yes, but for a self-hosted mail server on a VPS, it is a bad idea. Without a PTR record, messages are more likely to be treated as suspicious by receiving servers, especially when they are sent directly from the VPS IP address. At a minimum, if there is no PTR record, SPF, DKIM, and DMARC should be configured correctly.
A PTR record is configured by the owner of the IP address, which usually means in the VPS provider’s control panel or through support. For a mail server, it is best for the IP address to resolve to a meaningful hostname such as mail.example.com, and for that hostname to point back to the IP address.
If the provider does not allow you to configure a PTR record, it is better to use an external SMTP service for important email.
How does an SMTP server differ from an external SMTP service?
An SMTP server is a server used to send email. You can deploy one on your own VPS and manage it yourself.
An external SMTP service is ready-to-use infrastructure for sending email. A website or application connects to it using a username and password or an API, submits the message, and the service handles delivery, logs, IP reputation, bounce processing, and limits.
Running your own SMTP server gives you more control, but it requires administration. An external SMTP service is usually more convenient for transactional emails, such as registrations, password resets, requests, receipts, notifications, and orders.
What DMARC policy should you start with?
Initially, it is best to use a monitoring-only policy: v=DMARC1; p=none; rua=mailto:[email protected]
This record does not instruct receiving servers to reject messages, but it allows you to collect reports and understand which services are sending mail on behalf of the domain.
Google Workspace Help also describes DMARC as a mechanism that tells receiving servers what to do with messages that fail SPF or DKIM.
After checking SPF, DKIM, the website, CRM, external SMTP, and email campaigns, you can gradually move to p=quarantine and then to p=reject.
Do I need to configure DKIM for emails sent from a website?
Yes, if the website sends emails on behalf of the domain. DKIM helps receiving servers verify that the email is associated with the domain and has not been modified after it was sent.
If the website sends emails through an external SMTP service, DKIM is usually configured according to that service’s instructions: the service provides a DNS record with a public key and signs outgoing emails itself.
If the website sends emails through its own server on a VPS, DKIM must be configured on the mail server side. Simply adding a DNS record is not enough: the emails must actually include a DKIM-Signature header.
Without DKIM, email deliverability may suffer, and it will be harder to configure DMARC securely.
Sources
1. Cloudflare — What are DMARC, DKIM, and SPF?
2. Gmail Help — Email sender guidelines
