Logins, registrations, password resets and booking confirmations all quietly depend on one fragile piece of infrastructure — SMTP. Here is why it goes wrong more often than people expect.
Every website that lets someone register an account, reset a password, or receive a booking confirmation relies on SMTP (Simple Mail Transfer Protocol) — the standard used to hand an email off from a sending server to a receiving server. On paper it looks simple: a form is submitted, a message goes out, the user receives it.
In practice, SMTP is one of the more fragile parts of a modern website. It dates back to the early 1980s, designed for a much smaller, more trusting internet, long before spam and email fraud existed at scale. Almost everything that makes it complicated today is a layer of security bolted on top of a protocol that was never built with those problems in mind.
The core issue: sending an email successfully and having it actually reach the inbox are two different things. A message can be accepted for delivery and still be filtered into spam, delayed by hours, or silently dropped.
To combat spoofing, receiving mail servers now expect a domain to prove it is authorised to send email on its own behalf. This is done through three DNS records that must all be configured correctly.
| Record | What it does |
|---|---|
| SPF | Lists which mail servers are allowed to send email for the domain. Email from an unlisted server is treated as suspicious. |
| DKIM | Attaches a cryptographic signature so the receiving server can verify the message hasn't been tampered with. |
| DMARC | Tells receiving servers what to do if SPF or DKIM checks fail, and where to send failure reports. |
None of these are automatic. A single typo or missing record can cause a domain's email to be rejected or spam-filtered wholesale, even if everything else is fine. Many website owners only discover a missing record after users start complaining that emails never arrive.
These records live in the domain's DNS zone, usually, but not necessarily with the web host. Depending on how a domain is set up, DNS may be managed by the hosting provider, the domain registrar, or a separate DNS service entirely — so "check with your host" is not always the right place to start. Knowing where a domain's nameservers actually point is the first step before any of these records can be added or corrected.
Testing is crucial: before the production system can be ready for final publication.
Many smaller websites send email through their hosting provider's SMTP server, often shared with hundreds of other websites on the same IP address. If one of those websites sends spam or gets compromised, the shared reputation drops for everyone using it — through no fault of their own.
SMTP servers often impose hourly or daily sending limits, sometimes without clearly documenting what they are. A surge of genuine new registrations can look identical to a spam attack from the server's point of view, and trigger throttling at exactly the moment reliability matters most.
A "hard bounce" (invalid address) is usually reported back immediately. A "soft bounce" (mailbox full, server unavailable) can be retried for hours before failing silently, often with no notification that anything went wrong at all.
Why this matters for logins specifically: password reset and verification links are almost always time-sensitive. Any delay from rate limiting, spam filtering or server congestion directly undermines a flow that depends on the user acting on the email quickly.
Because of all of the above, most professional websites do not send transactional email directly through their own hosting's SMTP server. Instead, they use a dedicated third-party email provider — a service that specialises in exactly this problem, maintaining sending infrastructure with an established reputation and offering proper delivery and bounce reporting.
This doesn't eliminate the complexity of SMTP, it moves it. The SPF, DKIM and DMARC records still need to be added correctly, just pointing at the provider's infrastructure instead of the host's, and the initial setup can still take time to get right. It's a shift of who carries the burden of deliverability, not a removal of the burden itself.
It's also worth knowing that the reputation benefit varies by provider and by plan. Budget tiers of some services still pool customers onto shared sending IPs, which can carry the same reputation risk as shared hosting. Choosing a provider with a genuine track record for deliverability matters more than the label "dedicated email service" on its own.
There are some very good, reliable providers out there offering excellent services with free and paid options that work well — it's simply a case of choosing a proven solution carefully rather than assuming any option will do.
SMTP looks like a solved problem because it has existed for decades and "just works" most of the time. The complexity is almost entirely invisible until something goes wrong, at which point it becomes clear how many separate systems — DNS configuration, sender reputation, spam filtering, rate limits, bounce handling — all have to work correctly at the same time for a single email to reliably reach an inbox.
For any website where login, registration or account recovery depends on email actually arriving, treating email delivery as a solved, set-and-forget part of the build is one of the more common and costly assumptions a business can make.
Get in touch and we'll take a look at your configuration.