Transactional Email and SMTP Relay: Why Your App's Emails Don't Arrive, and the Fix
The verification and invoice emails your app sends land in junk because your new server's IP reputation is zero and SPF, DKIM, and DMARC are not set. We explain transactional versus marketing email, the two fixes, and numbers that improve deliverability.
The Direct Answer: The Problem Is Sending Reputation, Not the Code
Your app's emails (signup confirmation, password reset, invoices, order notifications) are called transactional email, and when you send them from a web server you just set up, they usually end in the junk folder instead of the inbox. The reason is not a bug in the code, it is sending reputation: your server's new IP address is completely unknown to mail providers like Gmail and Microsoft, and your domain carries none of the three authentication records (SPF, DKIM, and DMARC) that prove you are a legitimate sender. Without these records, the mail provider treats your message as spoofed or suspicious, so it blocks it or pushes it to junk.
The fix is not editing the code, it is building a trustworthy sending infrastructure through one of two paths: either corporate email on a Saudi server with a clean IP and precisely configured SPF, DKIM, and DMARC records, or routing sending through a specialized SMTP relay service that already holds a ready sending reputation. The decisive criterion is that your mail passes the three authentication checks, since a message that passes SPF and DKIM and aligns with the DMARC policy reaches the inbox at a far higher rate than a message with no authentication. In this article we detail the difference between transactional and marketing email, why your new server fails specifically, how to configure the three records, and compare the two paths with numbers.
Transactional vs Marketing Email
The difference is fundamental in nature and handling:
| Aspect | Transactional email | Marketing email |
|---|---|---|
| Trigger | A user action (signup, order) | A campaign sent by a marketer |
| Audience | One specific user | A large list at once |
| Expectation | The user awaits it immediately | The recipient may not expect it |
| Delay sensitivity | Very high (seconds) | Relatively low |
| Priority | Guaranteed and fast delivery | Open and engagement rate |
Transactional email is critical because the user is waiting for it now: if a verification code is delayed two minutes or goes to junk, you lose the user at the first step. That is why it is best to isolate the transactional path from the marketing campaign path, so that even if marketing sending reputation is hurt by complaints, the critical transactional messages keep arriving.
Why Your New Server Fails Specifically
Zero IP Reputation
Mail providers build a trust score for each IP based on its history: how many messages it sent, how many were opened, how many drew complaints. Your new server has no history at all, so its trust score is zero, and the provider treats the unknown with heavy caution. Worse, the new IP may be within an address range previously abused by an old tenant, so it inherits a bad reputation it did not create.
Absent Authentication
Without an SPF record, Gmail cannot confirm your server is authorized to send in your domain's name. Without DKIM, there is no digital signature proving the message was not forged in transit. Without DMARC, there is no policy telling the provider what to do with failing messages. The result is a message with no verified identity, whose natural fate is junk.
Configuring the Three Records
SPF
A TXT record in your domain's DNS that lists which servers are authorized to send in your name. Its simplified example: v=spf1 include:_spf.yourprovider.com -a ~all. The most important part is its ending: -all (strict rejection of any unlisted sender) is better than ~all (soft rejection) for tightening protection once you confirm all your senders are configured.
DKIM
A cryptographic signature: the sending server places a digital signature in each message's header with a private key, and you publish the public key in a TXT record in your domain. The recipient verifies the signature, proving the message actually came from you and was not altered. This is the strongest trust signal.
DMARC
A policy built on top of SPF and DKIM: it tells the mail provider what to do when a message fails authentication (nothing, quarantine to junk, or reject), and sends you periodic reports. Start with a monitoring policy p=none to collect reports for two weeks without affecting delivery, then tighten gradually to p=quarantine then p=reject after confirming all your legitimate senders pass.
The Two Fixes
Option One: Corporate Email on a Saudi Server
You run your email on managed cloud hosting or a cloud server inside the Kingdom, with a clean IP dedicated to you, and you configure SPF, DKIM, and DMARC correctly. This matters especially when dealing with government entities that sometimes classify email from foreign domains and servers as suspicious, so email on a Saudi server with your official domain reaches the inbox with higher confidence and proves your organization's identity. You get full control and data sovereignty, in exchange for your responsibility to build reputation gradually with regular clean sending.
Option Two: External SMTP Relay
You route your app's sending through a service specialized in delivery, which holds high-reputation IP addresses ready and a mature authentication infrastructure. Suitable for those who want the highest delivery rate with the least admin effort and a large sending volume. You lose some sovereignty because the mail passes through a third party, and complexity rises from wiring two services. For many companies in the Kingdom the best fit is a mix: Saudi corporate email on your domain for official and government correspondence, with a relay for high-volume transactional email if it exceeds your server's capacity.
Dedicated or Shared IP?
An important decision that affects your delivery: do you send from an IP dedicated to you alone or shared with other senders?
| Aspect | Dedicated IP | Shared IP |
|---|---|---|
| Reputation | You build it entirely alone | Affected by the other participants' behavior |
| Start | Needs gradual warmup from zero | Starts with a ready inherited reputation |
| Best for | Steady, regular sending volume | Small or intermittent volume |
The practical rule: if you send a large regular volume (thousands of messages daily), a dedicated IP is worth it because you own its reputation fully and others' misbehavior does not hurt you. But if you send a small intermittent volume, a shared IP is better because you will not have enough volume to warm up a dedicated IP and build its reputation. On a cloud server with a clean IP dedicated to you, you own your sending reputation entirely inside the Kingdom, and you can add an additional dedicated IP for 400 SAR per year if you want to separate the transactional path from the marketing one.
Feedback Loops
Major mail providers offer programs that notify you when a recipient marks your message as spam, called feedback loops. Register your domain in them, so you get an immediate signal for every complaint, and you remove that person from your list right away. This keeps your complaint rate low and protects your reputation from the slow collapse you notice only after it is too late.
Numbers That Improve Deliverability
After configuring the infrastructure, these practices raise the delivery rate tangibly:
- Gradual IP warmup: do not send thousands of messages on launch day, start with tens per day and double the volume every few days over two to four weeks, to build IP trust without raising an alarm.
- Keep the complaint rate below 0.1%: mail providers watch the fraction of people who mark your messages as spam, and exceeding 0.1% harms your reputation quickly.
- Clean your list of bounced addresses: repeated sending to nonexistent addresses (bounces) lowers your reputation, so remove an address after it bounces twice.
- Watch DMARC reports: read them weekly to spot who is spoofing your domain or which legitimate sender fails, before you tighten the policy.
A Practical Conclusion
To ensure your app's email arrives:
- Understand the problem is sending reputation and authentication, not the code.
- Configure all three of SPF, DKIM, and DMARC, and start DMARC at p=none then tighten.
- Choose the path: Saudi corporate email on your domain for sovereignty and formality, a relay for high volume, or a mix of both.
- Warm up the IP gradually, clean your list, and keep complaints below 0.1%.
To run corporate email with a clean IP and correct authentication records inside the Kingdom, check the pricing and plans. The infrastructure is inside Riyadh at roughly 8ms latency, with full control over your domain and mail.
