The team behind FXRM has been running email infrastructure since the early 1990s — from MMDF and Sendmail to Postfix and Zimbra. Here's what actually matters for getting mail delivered.
Email is older than the web. The protocols that underpin it — SMTP, DNS MX records, the envelope and header distinction — were finalised in the early 1980s and have changed remarkably little since. What has changed is the filtering infrastructure that sits in front of receiving mail servers. Understanding how that filtering works, and how to work with it rather than against it, is what separates email that gets delivered from email that doesn't.
The team behind FXRM has been operating email infrastructure in the UK since the early 1990s — across Sendmail, MMDF, Zarafa, Postfix, Zimbra, and several others that didn't survive. These are the lessons that have stayed true across all of it.
Forward-confirmed reverse DNS — where your MX server's IP has a PTR record that resolves to a hostname, and that hostname resolves back to the same IP — is one of the oldest email hygiene requirements. It predates SPF, DKIM, and DMARC by decades.
Many shared hosts don't configure PTR records correctly, because PTR records are set at the IP level (by whoever controls the IP block) and shared hosting providers don't routinely set per-customer PTR records.
We have seen mail from well-configured Postfix servers with valid SPF and DKIM get rejected by receiving servers purely because the PTR record didn't match. The check is simple and fast: dig -x [sending IP]. If the result doesn't resolve back to your mail server hostname, fix it before anything else.
When you share an IP with other senders, you share their reputation. This is true for web hosting (shared IP pools for outbound mail) and for transactional email services that put multiple customers on shared IP ranges.
A single spam campaign from a shared IP can trigger a Spamhaus XBL listing that affects every other sender on the same IP. The listing is usually resolved within hours or days, but during that window your legitimate mail is being rejected by every receiver that checks Spamhaus.
The cost of a dedicated sending IP has dropped to the point where it's reasonable for any organisation sending more than a few thousand emails per month. For high-volume or business-critical sending, it's not optional.
DMARC has three policies: none, quarantine, and reject. Most organisations that have "set up DMARC" are running p=none, which instructs receiving mail servers to take no action on unauthenticated mail — just report it.
This is useful during the audit phase. It tells you who is sending mail as your domain. But many organisations set p=none, look at the reports for a week, and then forget about it. The domain remains unprotected. Anyone can send mail claiming to be from yourdomain.com and it will be delivered normally.
The discipline of moving from none to quarantine to reject requires confidence that you've identified every legitimate sender. That means the CRM, the transactional email service, the customer support tool, the automated invoice system, the monitoring alerts. Every system that sends email from your domain must be authenticated before you move to enforcement.
It takes time, but it's the only form of protection that actually works against domain spoofing.
The From header is what users see in their mail client. The envelope sender (the MAIL FROM address in the SMTP transaction) is what receiving servers use for bounce handling and SPF evaluation.
These can be different, and frequently are. Mailing list software and newsletter tools often set the envelope sender to their own domain (which passes SPF for them) while the From header shows your domain. This is legitimate and common, but it means SPF alone provides no protection against someone spoofing your From address — they just need to control the envelope sender.
This is why SPF alone is insufficient and why the combination of SPF + DKIM + DMARC alignment is necessary. DMARC alignment checks that either the SPF domain or the DKIM signing domain matches the From header domain — closing the gap that exists when SPF and From are evaluated independently.
Even well-configured mail infrastructure gets blacklisted occasionally. A user account gets compromised and sends spam. A misconfigured script floods an address that's being monitored. A server IP appears in an older netblock that got listed years ago.
Automated blacklist monitoring (MXToolbox, HetrixTools, and others provide this) should be standard for any mail infrastructure. You want to know about a listing within minutes, not when clients start calling.
The response to a listing depends on the list. Spamhaus PBL listings are for residential IPs and require a removal request with justification. XBL listings are for IPs seen sending spam, and require investigation before requesting removal. Barracuda listings are often resolved quickly via their lookup tool. Each has its own process, and knowing which lists matter for your receivers is part of operating mail infrastructure properly.
What works for Gmail may not work for Outlook and vice versa. Their filtering algorithms are different. Gmail weights DMARC heavily. Outlook weighs SPF alignment differently. Both have proprietary reputation signals that are not fully documented.
Testing mail delivery across major receivers is a discipline, not a one-time check. Services like Mail-Tester, Mailtrap, and GlockApps let you see what signals a message is triggering at major receivers before you send at scale.
Across three decades of changes in email infrastructure — new protocols, new filtering approaches, new providers — certain things have remained true:
Send from IPs with clean reputations. Make sure your reverse DNS matches your forward DNS. Authenticate everything that sends on your behalf. Monitor your sending reputation. Fix problems immediately rather than waiting for them to resolve themselves.
The technical details change. The underlying discipline doesn't.
The team behind FXRM has been running email infrastructure since the early days of the UK internet. If your deliverability isn't where it should be, we offer a free audit →.
Founded by Jon Morby, whose team has been running UK servers since 1992. Hosting built by engineers who care about deliverability and uptime.
Get in touch →Three records. Three different jobs. Most guides treat them as a checklist. This one explains what actually happens when each one fails — and why all three must work together.
Most email deliverability problems aren't content problems. They're infrastructure problems — a PTR mismatch, a DMARC policy set to none, a shared IP on a blacklist. Here's what's actually going wrong and what to do about it.
Shared cPanel hosting concentrates thousands of senders on the same IP pools. One bad actor affects everyone. Here's the mechanics of why it happens and how to fix it.