Email Deliverability: SPF DKIM DMARC

My client called me with a frustration I had heard before but rarely this severe. "Our invoices land in spam. All of them. Customers are missing payments, blaming us, and our finance team is drowning in manual follow-ups."

They were on InMotion Hosting, a shared hosting plan. The client had already done the homework. SPF record was set. DKIM was enabled. DMARC was publishing a p=quarantine policy. On paper, everything looked textbook. But every email sent to Gmail, Outlook, or Yahoo landed squarely in the spam folder.

I asked the client to send a test email and forward me the full headers. This is where the story starts. Not at the DNS zone editor. Not at the hosting control panel. At the raw email headers.

The moment I saw the headers

The email headers told a story that no DNS checker could reveal.

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of billing@clientdomain.com designates 198.186.128.0/24 as permitted sender) smtp.mailfrom=clientdomain.com;
       dkim=pass header.i=@clientdomain.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=clientdomain.com

All three checks passed. SPF pass. DKIM pass. DMARC pass. Yet Google still slapped a quarantine disposition. That should not happen. When all three pass, delivery is supposed to follow.

Unless something deeper is at play.

I compared the headers with known good email headers from a properly configured mail server. Four differences stood out. One of them was the smoking gun. But finding it required understanding three things most sysadmins never look at: shared IP reputation, SPF alignment vs header alignment, and Forward-Confirmed Reverse DNS.

The three hidden culprits

After hours of digging through headers, DNS records, and bounce logs, I traced the root cause to three distinct issues. No single one would have caused the problem alone. Together, they created a perfect storm against inbox delivery.

Shared IP reputation poisoning

InMotion Hosting uses shared IP addresses for outgoing mail on standard shared plans. This means the same IP that sends my client's invoices also sends emails from hundreds of other tenants.

Somewhere in that pool, one tenant runs a newsletter campaign with poor list hygiene. Another forwards spam. Another gets compromised and starts blasting phishing emails. This is the same class of problem I see in internal network attacks, where one compromised machine poisons the reputation of everything behind it. I covered a similar scenario in the Proxmox VM attack case study, where a single compromised VM threatened the entire hypervisor.

When enough abuse reports accumulate against that IP, Google and Microsoft add it to their reputation databases. My client's perfectly crafted emails then inherit that reputation by association. It does not matter how clean their domain is when the sending IP is flagged.

# Check IP reputation with DNSBL
dig +short 2.0.0.127.b.barracudacentral.org

# Check against Spamhaus
dig +short 2.0.0.127.zen.spamhaus.org

The response for our IP came back positive. The shared IP was listed on two DNS blocklists.

SPF alignment versus header from alignment

This one catches most people. SPF uses the smtp.mailfrom address, also called the envelope sender or return-path. This is often a different address than the From: header your recipient sees in their email client.

When a hosting provider sends email, the envelope sender might be something like bounce@inmotionhosting.com while the visible From: header shows billing@clientdomain.com. SPF checks the envelope sender. It does not check the visible from.

Even with SPF=pass, the alignment can fail because smtp.mailfrom domain and header.from domain do not match. This mismatch means SPF alignment fails. Google and Outlook use alignment as a signal, not just the raw pass or fail.

# Example of misaligned headers
smtp.mailfrom: bounce@inmotionhosting.com     ← SPF checks this
header.from: billing@clientdomain.com          ← User sees this

These domains must match for full alignment. When they do not, the email loses credibility in the eyes of the receiving MTA.

Missing Forward-Confirmed Reverse DNS

Forward-Confirmed Reverse DNS is a PTR record that maps the sending IP back to a hostname, and that hostname must resolve forward to the same IP.

This is the most overlooked DNS record for email deliverability. Gmail and Outlook both check it. If a PTR record is missing or does not match, the receiving server flags the email as potentially forged. You can verify all of these records (SPF, DKIM, DMARC, PTR, and MX) for any domain with the DNS health check tool.

My client's sending IP had no PTR record at all.

# Check PTR record for sending IP
dig +short -x 198.186.128.xxx

# Response: empty. No PTR record configured.

Without a valid PTR that matches the HELO/EHLO hostname, deliverability drops significantly.

The remediation roadmap

Fixing this required changes at three layers: DNS, hosting plan, and email configuration. Each step had to be sequenced carefully to avoid downtime or bounced emails.

Step one: dedicated IP and PTR record

The first call was to InMotion Hosting support. I requested a dedicated IP address for outgoing mail. This immediately isolated my client from the shared IP reputation pool.

Request: Dedicated IP for SMTP outbound
Provider: InMotion Hosting
Timeline: Activated within 4 hours
IP: 198.186.128.xxx (dedicated, not shared)

Once the dedicated IP was assigned, I submitted a reverse DNS request. The PTR record needed to match the hostname used in the HELO/EHLO handshake.

# PTR record requested
198.186.128.xxx → mail.clientdomain.com

# Verification after propagation
dig +short -x 198.186.128.xxx
# mail.clientdomain.com

dig +short mail.clientdomain.com
# 198.186.128.xxx

Forward and reverse matched. The first check passed.

Step two: IP warmup strategy

A brand new dedicated IP has no reputation at all. A cold IP sending legitimate email volume is suspicious. A sudden flood triggers rate limiting and spam placement.

"An IP with no history is treated the same as an IP with bad history. The receiving server does not know which one you are yet."

I planned a two-week warmup schedule.

Week 1: Send only transactional emails (invoices, receipts), 50-100 per day
         Delay non-urgent marketing emails
Week 2: Gradually increase volume, 300-500 per day
         Monitor delivery in postmaster tools
Week 3+: Resume full volume, monitor reputation

I used Google Postmaster Tools and Microsoft SNDS to track reputation daily. The first week showed neutral reputation. By the end of week two, the dedicated IP reached green status on both platforms.

Step three: header alignment fix

SPF alignment required that smtp.mailfrom and header.from share the same domain. I updated the mail server configuration to use the client's own domain in the envelope sender.

// Example PHP mailer configuration for alignment
$mail->setFrom('billing@clientdomain.com', 'Client Billing');
$mail->addReplyTo('support@clientdomain.com', 'Client Support');
// Ensure return-path matches the domain
$mail->Sender = 'bounce@clientdomain.com';

And added a dedicated SPF record for the new sending IP:

# Updated SPF record
clientdomain.com TXT "v=spf1 include:mx.inmotionhosting.com ip4:198.186.128.xxx -all"

The -all hard fail at the end is critical. Many hosting providers default to ~all (soft fail), which tells receiving servers to treat unauthenticated email as suspicious but not reject it outright. Hard fail forces strict enforcement.

Step four: DMARC reporting and monitoring

DMARC was already set to p=quarantine, which was part of the problem. With misalignment and low IP reputation, DMARC was dutifully enforcing quarantine. I switched it to p=none temporarily during the warmup period, then moved to p=quarantine once alignment was confirmed.

# Temporary monitoring mode
_dmarc.clientdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@clientdomain.com"

# After verification
_dmarc.clientdomain.com TXT "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@clientdomain.com"

DMARC aggregate reports came weekly. They confirmed SPF and DKIM pass rates above 99%, with alignment at 100% after the envelope sender fix.

The results

We measured deliverability before and after the changes. The improvement was immediate and sustained.

The client's finance team stopped getting calls about missing invoices within three days of the dedicated IP activation. By day five, all major providers delivered to inbox.

Lessons for sysadmins

This case reinforced three principles I now apply to every email deliverability engagement.

SPF, DKIM, and DMARC are table stakes, not guarantees. They are necessary but not sufficient. A shared IP with bad reputation bypasses all three. Always check the sending IP reputation before touching DNS records.

Headers do not lie. DNS checkers do. Online SPF and DKIM checkers only verify record syntax. They do not check alignment, PTR, or SMTP handshake configuration. The true story is in the email headers. Learn to read them.

A dedicated IP is not optional for transactional email. Shared hosting IPs are a gamble. If you send invoices, receipts, or any customer-facing email with authentication requirements, a dedicated IP is not a premium feature. It is the baseline.

"The authentication passed. The email still failed. That is the moment you stop trusting the checkboxes and start reading the headers. The same principle applies to server security. You can configure a firewall, disable root login, and set up fail2ban. But if you never check the logs, you are trusting checkboxes. I wrote about this in the Linux server hardening guide. A configuration you never verify is a configuration that might not work."

If you run into a similar issue, start with three commands: dig for PTR, dig for DNSBL, and a raw email header view. The answers are always in the protocol. You just have to look past the control panel.

Six months later, the client's deliverability is still above 97%. They moved to a dedicated IP permanently. The invoices land in inboxes. The finance team stopped calling me. That is the quietest outcome and the best one.

The hardest lesson in email deliverability is that doing everything right at the DNS level is only half the work. The other half is reputation, alignment, and infrastructure choices you cannot configure in a text record.

Every sysadmin should have a mental checklist for email deliverability that goes beyond SPF, DKIM, and DMARC. Shared IP, PTR record, alignment, warmup schedule. Check them all before you call a configuration complete.