How to Explain Low Email Deliverability to Clients

Low email deliverability almost always comes down to authentication, reputation, or content, and an email deliverability audit is how you separate those three before you tell a client anything. Work through the evidence in a fixed order, write down what each check returned, and the explanation to the client becomes a matter of reading the findings out loud.

Start with the receiving server's view

Your client sees a complaint. The receiving server sees a connection, a HELO name, a sender address, and a set of authentication results. Get that side of the story first. Ask the client to forward the full original message with headers, not the text body. In most desktop clients that is a "show original" or "view source" option, and you want the raw block starting at the first Received: line.

The headers you care about are Authentication-Results, Received-SPF, DKIM-Signature, and Return-Path. A receiving server that could not verify SPF usually says so plainly:

Authentication-Results: mx.example.net;
  spf=softfail (sender IP is 203.0.113.9)
  [email protected];
  dkim=none; dmarc=fail header.from=client.example

Read that as three separate verdicts. The envelope sender failed SPF, or passed only weakly. No DKIM signature survived. DMARC therefore failed, and with a failing DMARC result the receiving side is entitled to treat the message as suspicious regardless of what it says. That chain, from SPF through DKIM to DMARC, is the backbone of every audit you will run.

Check the DNS records yourself

Do not take a control panel screenshot as proof. Query the records from a machine outside the client's network, because resolvers cache and split-horizon DNS will lie to you.

dig +short TXT client.example
dig +short TXT _dmarc.client.example
dig +short TXT selector1._domainkey.client.example
dig +short MX client.example

For the SPF record, count the DNS lookups it triggers. The protocol allows a limited number, and records that chain through several include: mechanisms routinely exceed it. A permerror from SPF is a configuration fault, not a reputation problem, and it is the easiest finding to fix. Check that the record ends in a single all mechanism and that the qualifier matches intent: -all for a domain that only sends from known hosts, ~all while you are still mapping senders.

For DKIM, confirm the selector in the signature actually resolves. A common failure is a selector published on the wrong domain, or a key rotated in the mail platform but not updated in DNS. For DMARC, look at the policy and the reporting addresses. If the client has no _dmarc record at all, say so early: without one, the receiving side has no instruction and no reporting, and you are auditing blind.

Set up DMARC reporting before you diagnose

Aggregate reports are the only reliable way to learn who is sending as the client's domain. Publish a record with a reporting address and a permissive policy while you collect data. A minimal starting point looks like this:

v=DMARC1; p=none; rua=mailto:[email protected];
  adkim=r; aspf=r; pct=100

Leave it there long enough to see a full week of traffic, then read the reports. They arrive as compressed XML, and each record lists a source IP, a count, and the SPF and DKIM verdicts for that source. Anything sending legitimate mail that fails both is either a forgotten application, a third party the client never told you about, or a spoof. Anything that fails both and that the client does not recognise is the thing to block. Only after the inventory is clean should the policy move to quarantine and then reject. Explain that sequence to the client as a project with stages, because tightening the policy too early will silently break mail from systems nobody remembered.

Separate infrastructure problems from reputation problems

If authentication passes and mail still lands in spam, the question shifts to how the sending IP and domain are regarded. Check whether the sending host has forward and reverse DNS that agree, and whether the HELO name it presents resolves back to the same address. Check that the domain in the From header matches the domain in the envelope, because a mismatch is a signal on its own.

Then look at the sending pattern. A sudden volume increase from a domain with little history, a large proportion of messages to invalid recipients, or a burst of complaints will all depress delivery without any single protocol error. Ask the client what changed: a new signup form, a migration to a new sending platform, a marketing campaign. The answer is often the cause.

Blocklist lookups are worth doing but treat them as supporting evidence. A listing on a major blocklist explains a hard rejection, not a quiet trip to the spam folder, and the absence of a listing does not prove the reputation is good. Record what you checked and when, because listings change.

Write the report so the client can act

Structure the findings by layer: authentication, DNS configuration, sending infrastructure, content, and reputation. For each one, state what you ran, what it returned, and what that means in one sentence. Quote the header line or the DNS answer verbatim so the client can see you are not guessing. Where a finding is a configuration fault, give the exact change. Where it is a reputation issue, say that it will improve with consistent authenticated sending and that you will re-measure.

Avoid telling the client their mail is "going to spam" without evidence. Either you have a header showing a spam classification, or you have a DMARC failure, or you have a blocklist hit. If you have none of those, say the data does not yet support a conclusion and describe what you will collect next. That honesty is what makes the next report credible.

As a next step, pick the single finding with the clearest fix, usually a broken SPF lookup count or a missing DKIM selector, correct it, and re-run the same commands after propagation so you have a before and after. Publish DMARC reporting first if it is absent, let it run, and only then revisit policy. Keep the command output from each round in a dated directory, because the second audit is always easier when you can diff it against the first.