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.
Your client calls. Their transactional emails — password resets, order confirmations, booking notifications — have stopped arriving in inboxes. Users are complaining. The client is panicking. You log in, check the email sending code, and everything looks fine. The emails are being sent. The content is straightforward. There's no obvious reason they should be flagged.
Then you check Gmail on a test account and find them in the spam folder, with a small grey note underneath: "This message seems dangerous." Or worse, they're not even making it to spam — they're being silently dropped at the receiving MTA.
This is not a content problem. This is an infrastructure problem. And it's far more common than it should be, because most hosting setups treat email as an afterthought.
Receiving mail servers — Gmail, Outlook, Yahoo, corporate mail gateways — make a decision about every incoming message within milliseconds of accepting the connection. That decision is based on a combination of signals, most of which have nothing to do with what's in the email body.
The two primary signals are IP reputation and domain reputation. They are related but distinct, and conflating them is one of the most common mistakes made when diagnosing deliverability problems.
IP reputation is the standing of the specific server IP address that initiated the SMTP connection. Every major inbox provider maintains reputation data on sending IPs, either through their own telemetry, third-party blacklists like Spamhaus or SORBS, or both. If your sending IP has been used to deliver spam — even by someone entirely unrelated to you, months ago — its reputation reflects that.
Domain reputation is the standing of your sending domain. Google, in particular, tracks this extensively. If your domain has historically had high spam complaint rates, low engagement, or a pattern of sending to non-existent addresses, your domain's reputation degrades — and that follows you even if you switch IP addresses.
Authentication headers sit on top of both of these. SPF, DKIM, and DMARC tell the receiving server whether this email is genuinely from who it claims to be from. A lack of correct authentication is treated as a significant negative signal, regardless of how reputable your IP and domain are.
The receiving server combines all of this — IP reputation, domain reputation, authentication results, content signals — into a disposition decision. Deliver to inbox. Deliver to spam. Reject. The weighting varies between providers, but infrastructure signals consistently outweigh content signals for legitimate senders.
Every IP address can have a reverse DNS record — a PTR record that says "this IP belongs to this hostname." For mail servers, this matters. When your mail server connects to a receiving MTA, the receiving server looks up the PTR record for your sending IP. It then checks whether that hostname resolves forward to the same IP. If those don't match, or if there's no PTR record at all, that's a red flag.
It's not an automatic rejection — most providers won't hard-fail on a missing PTR — but it contributes to a negative assessment. More importantly, some corporate mail gateways and certain ISP-level spam filters will reject on a missing or mismatched PTR. You may never know, because the rejection happens at the SMTP level before a bounce is generated back to you.
The fix is straightforward but requires access to your server's IP. You need your hosting provider to set a PTR record for the IP that resolves to your mail server's hostname, and that hostname must have an A record pointing back to the same IP. If you're on shared hosting and your provider controls the IP, you often can't set this yourself — you have to ask, and many budget hosts either can't or won't.
This is worth checking right now for any client with email deliverability concerns. Run dig -x <your-sending-ip> and see what comes back. Then forward-confirm the result. If they don't match, you've found a problem.
DMARC is a policy record that tells receiving servers what to do when an email fails authentication. It has three enforcement levels: none, quarantine, and reject. The none policy is meant to be a monitoring mode — you use it to collect aggregate reports and understand your email flows before you move to enforcement.
The problem is that most domains — once set up by an agency following a tutorial — have DMARC set to p=none and stay there indefinitely. This means you're publishing an authentication policy that takes no action.
Here's what none actually means in practice: it provides no protection against spoofing. Anyone can send email that claims to be from your client's domain, and your DMARC record explicitly states that you don't want the receiving server to do anything about it. Some providers — notably Gmail — have started treating p=none as a weaker signal than p=quarantine or p=reject, meaning domains with only a monitoring policy may be treated with slightly more suspicion.
The path forward is to actually move through DMARC policy levels. Start with p=none and an rua reporting address so you can see what's sending mail under your domain. Once you understand and control all legitimate sending sources, move to p=quarantine. Then, when you're confident, move to p=reject. This takes a few weeks of careful work, but it's the only correct outcome.
This is the one that causes the most confusion and the most frustration. Your client is on shared hosting. They have a perfectly configured mail setup, clean sending practices, good content. But someone else on the same server — someone on the same shared IP — is running a spam campaign, or they were three months ago, and the IP is now listed on Spamhaus SBL, UCEProtect, or one of dozens of other blocklists.
When your client's email goes out through that IP, receiving servers check the IP against blocklists. If it appears on a list that the receiving server consults, the email is rejected or spam-foldered. Your client's reputation and practices are completely irrelevant.
You can check any IP against major blocklists at MXToolbox or directly with the blocklist operators. If you find a listing, the short-term fix is to request delisting — but delisting is typically temporary if the root cause (another user on the IP) isn't addressed. The real fix is to move to a dedicated sending IP, or to a mail infrastructure that gives you IP isolation from other senders.
This is a structural problem with shared hosting for anything beyond personal email. Once a client's email is business-critical — transactional systems, e-commerce confirmations, client invoices — the risk profile of sharing an IP with unknown senders becomes unacceptable.
SPF (Sender Policy Framework) is a DNS record that lists which IP addresses are allowed to send email for your domain. A receiving server, when it gets an email claiming to be from yourclients-domain.com, looks up the SPF record and checks whether the sending IP is listed.
The most common misconfiguration is using +all at the end of the SPF record. The +all mechanism means "allow all senders" — it's a wildcard that passes every IP address. If your client's SPF record ends in +all, it is effectively worthless as an authentication mechanism.
Common real-world SPF mistakes:
Multiple SPF records for the same domain. SPF requires exactly one TXT record. If there are two, both are invalid. This often happens when a developer adds a new SPF record without removing the old one.
Too many DNS lookups. The SPF specification allows a maximum of 10 DNS lookups during evaluation. Each include: mechanism triggers a lookup. If you've got multiple mail providers and CDNs included, you can hit the limit. Evaluation stops at 10 lookups, and remaining mechanisms aren't checked.
Forgetting about sending sources. Your client sends email from their own server. They also use a CRM, a support ticket system, a transactional email provider, and a newsletter platform. If any of those aren't in the SPF record, their email may fail SPF validation.
Using ~all and thinking it means rejection. The ~all (softfail) mechanism is not a rejection. It advises the receiving server that unlisted senders are "not authorised but not definitely spam." This is the correct choice during setup — but you should understand what it means.
Start with a diagnostic pass. For any client with deliverability problems, check all of the following before touching the email content:
Check the PTR record for every IP address that sends mail for the domain. Forward-confirm it. If there's a mismatch, escalate to whoever controls the server IP.
Look up the SPF record. Make sure it's a single record, that it ends in -all or ~all, and that every system sending email for the domain is included. Run it through an SPF validation tool to check lookup count.
Check the DMARC record. If it's p=none, it needs to eventually become p=quarantine or p=reject. Add an rua address so you're collecting reports. Review what's in those reports.
Check the sending IP against major blocklists. If it's listed, investigate the listing, request delisting if appropriate, and evaluate whether shared sending infrastructure is appropriate for this client's use case.
Check DKIM is configured and that the signature is valid. A missing or invalid DKIM signature is a separate problem but compounds the others.
A well-tuned dedicated sending IP with correct PTR, a properly configured SPF record ending in -all, DKIM signing with a 2048-bit key, and a DMARC policy at p=reject will consistently outperform a misconfigured shared infrastructure regardless of email content quality.
Most agencies have client email running on shared hosting stacks where none of these things are fully under your control. That's worth reconsidering for clients where email is business-critical.
FXRM's email hosting runs on dedicated infrastructure with proper PTR configuration, isolated sending IPs, and DKIM and DMARC configured correctly from day one. If your client's email deliverability is causing problems and the root cause is infrastructure, take a look at our email hosting options.
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.
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.
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.