Email Deliverability Assessment: A Practical Audit You Can Run

Email deliverability assessment is the process of finding out whether your messages are accepted, authenticated, wanted, and placed where subscribers can see them. It is not a single score or a one-time spam test: it is an operational audit of your sending domain, infrastructure, audience, message stream, and mailbox-provider signals.

The goal is simple: identify the specific reason mail is being rejected, routed to spam, delayed, or ignored—then make a controlled change and verify that the relevant signal improves. This guide gives you a repeatable assessment framework, exact records and headers to inspect, a worked example, and a way to turn the results into a durable deliverability program.

What an email deliverability assessment actually measures

People often use delivery and deliverability as though they mean the same thing. They do not.

Delivery means the receiving mail server accepted the message. Your email platform may report a high delivered rate even when a meaningful share of accepted messages goes to Spam, Promotions, or a low-visibility inbox tab.

Deliverability is the broader outcome: whether a mailbox provider trusts the sender enough to accept the mail and place it in a location where the intended recipient is likely to see it. It is influenced by technical authentication, IP and domain reputation, recipient behavior, message relevance, complaint rates, list quality, and sending consistency.

A useful assessment separates five questions:

1. Can receivers authenticate us? Check SPF, DKIM, DMARC alignment, TLS, DNS, and mail headers.
2. Are we sending to valid, consenting people? Review acquisition, confirmation, bounces, complaints, inactivity, and suppression handling.
3. Do mailbox providers see a stable, trustworthy sender? Examine domain and IP reputation, volume changes, provider-specific errors, and blocklisting.
4. Do recipients want this exact stream? Compare engagement and complaints by campaign type, audience source, cadence, and mailbox provider.
5. Can we prove placement improved? Track provider-level acceptance, spam complaints, inbox tests, and business outcomes before and after each change.

This distinction matters because a beautiful template cannot repair a broken authentication chain, and a perfect DMARC record cannot make an unwanted campaign welcome. A sound audit investigates both.

Start with a baseline, not a redesign

Do not begin an assessment by changing your domain, sender, template, ESP, cadence, and audience simultaneously. If results get better or worse, you will not know why.

First, create a 30-day baseline—or use the longest clean period of comparable data you have. Split it by mail stream rather than treating every email as identical:

• Transactional: receipts, password resets, account alerts, verification messages.
• Lifecycle: onboarding, trial reminders, activation prompts, renewal notices.
• Marketing: newsletters, product announcements, promotions, event invitations.
• Prospecting: outreach to people who have not actively subscribed.

These streams have different recipient expectations and should normally have different From addresses or subdomains. For example, notify.example.com can carry transactional messages while news.example.com carries opted-in newsletters. That separation makes it easier to protect critical mail if promotional performance deteriorates.

Build a simple table for each stream and each major mailbox-provider family—Gmail, Yahoo, Microsoft consumer mailboxes, and corporate domains if they matter to your list.

Do not mistake an open rate for an inbox-placement measurement. Privacy features and image loading make opens an imperfect proxy. Use them as trend data within the same stream, not as proof that every recipient saw a message.

Also inventory every tool that can send as your domain: your email API, marketing platform, CRM, support desk, billing system, recruiting tool, form plugin, and internal workspace provider. A forgotten tool is a common cause of SPF failure, unsigned mail, or DMARC reports full of unknown senders.

Audit email authentication and domain alignment

Authentication is the first gate in an email deliverability assessment. It proves that a message is allowed to use a domain and helps receivers distinguish legitimate mail from spoofing.

Gmail requires all senders to authenticate mail sent to Gmail accounts, use TLS, and maintain valid forward and reverse DNS. Senders that send about 5,000 or more messages to personal Gmail accounts in a 24-hour period have additional requirements, including SPF, DKIM, and DMARC. Gmail also says bulk senders must keep the Postmaster Tools spam rate below 0.3%. (support.google.com)

SPF: authorize the envelope sender

SPF is a DNS TXT record that lists the infrastructure permitted to send mail for the domain used in the SMTP MAIL FROM command, often visible to recipients as the Return-Path domain.

A simplified SPF record could look like this:

example.com. TXT "v=spf1 include:spf.your-email-provider.example -all"

That is syntax only, not a copy-and-paste provider configuration. Your ESP or email API supplies the real include: value, and some providers require additional CNAME or MX records instead. Keep one SPF TXT record for a domain; the SPF specification says multiple SPF records at the same owner name are not permitted. (rfc-editor.org)

Check these SPF failure modes:

• Two separate TXT records beginning with v=spf1.
• An old provider still included after migration.
• A tool sending from a domain that has no corresponding SPF authorization.
• The wrong domain checked because the visible From domain and Return-Path domain differ.
• Too many DNS-query-causing mechanisms, which can produce an SPF permerror.
• A permissive +all, which authorizes any sender and defeats the purpose of the record.

Use -all only after you have inventoried legitimate sources. If you are still discovering senders, ~all can reduce the risk of immediately failing unknown legitimate traffic, but it is not a substitute for completing the inventory.

DKIM: sign the actual message

DKIM adds a cryptographic signature to the message. The sending system signs selected headers and body content; receiving systems retrieve the public key from DNS to verify the signature. DKIM uses a selector, visible in the s= tag, and a signing domain, visible in the d= tag. (rfc-editor.org)

A typical public-key lookup name is:

s1._domainkey.example.com

The record value is provider-generated and commonly resembles:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Do not manually invent or truncate a DKIM public key. Generate the key and record through your sending provider or key-management process, publish it exactly, then send a live message and inspect the received headers. Your message should show dkim=pass, with a header.d= domain that aligns with the visible From domain.

DMARC: connect authentication to the visible From address

DMARC evaluates the domain recipients see in the RFC 5322 From: header. For a DMARC pass, SPF or DKIM must pass and the authenticated domain must align with the From domain under relaxed or strict alignment rules. (rfc-editor.org)

Start with a monitoring record such as:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

What each important tag means:

• p=none: request reports without asking receivers to quarantine or reject failing mail.
• rua=: aggregate-report destination. Use a mailbox or DMARC-reporting service that can process XML attachments.
• adkim=r and aspf=r: relaxed alignment. A subdomain can align with its organizational domain.
• pct=100: apply the policy to all relevant mail. It is meaningful once you move to enforcement.

After you have reviewed reports and identified every legitimate sender, consider progressing deliberately from p=none to p=quarantine, then to p=reject. The correct pace depends on the number of tools, subdomains, affiliates, and forwarding patterns involved. The purpose of enforcement is to reduce successful impersonation—not to create a badge for your DNS dashboard.

How to verify the whole chain

Send a message to a test Gmail or Microsoft mailbox. In the received message, open the original or full headers and find Authentication-Results. A healthy result may resemble:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com header.s=s1;
       dmarc=pass header.from=example.com

This is more useful than seeing DNS records exist. Records can be syntactically present while messages still fail because the wrong source signs mail, the Return-Path domain is wrong, or the DKIM d= domain does not align.

For implementation details specific to a sending platform, consult its email API setup documentation and test an actual received message—not merely a domain-verification screen.

Check transport, identity, and infrastructure reputation

Authentication is necessary, but it is not the entire trust model. Mailbox providers also evaluate the sending infrastructure and how it behaves over time.

Review these items for every sending IP or provider-managed sending pool:

• TLS: The SMTP connection should be encrypted where receivers support it. Gmail lists TLS among sender requirements. (support.google.com)
• PTR or reverse DNS: The sending IP should have a valid reverse-DNS record, and the hostname should resolve forward to the same IP. Gmail specifically calls for valid forward and reverse DNS. (support.google.com)
• HELO/EHLO name: It should identify a real, resolvable host—not localhost, an IP literal, or an unrelated name.
• IP ownership: Know whether you use a shared pool, dedicated IP, or your cloud server. A dedicated IP is not automatically better; it needs enough consistent, wanted volume to establish its own history.
• Blocklists: Check the IP and sending domain against reputable public DNS blocklists. A listing is evidence to investigate, not universal proof that every receiver will reject your mail.
• Provider errors: Preserve SMTP reply codes and enhanced status codes. A 550 permanent rejection needs a different response from a 421 temporary deferral.

Avoid reacting to a temporary deferral by retrying aggressively. Respect your provider’s retry behavior and reduce the immediate sending spike if the error indicates rate limiting or reputation trouble. Repeated bursts to a provider that is already slowing you down make recovery harder.

If you use a shared sending IP, your assessment should focus heavily on the domain: the From domain, DKIM domain, Return-Path domain, and recipient response. If you use a dedicated IP, add IP-specific monitoring and make sure your volume is predictable enough that large jumps do not resemble compromised infrastructure.

Assess list quality, consent, and suppression controls

Many deliverability incidents begin before the first message is sent. A technically perfect campaign sent to old, scraped, purchased, mistyped, or poorly consented addresses creates bounces, complaints, and weak engagement.

Document the source of every subscriber cohort. Useful categories include:

• Explicit newsletter signup.
• Product account creation with a separate marketing choice.
• Event registration.
• Customer purchase or trial.
• Partner or co-marketing collection.
• Sales-prospecting data.
• Imported historical list.

Then answer four questions for each source: what did the person expect, what proof do you keep, what stream are they eligible for, and when do they stop receiving messages? If you cannot answer those questions, do not treat the cohort as ready for a large campaign.

Test suppression before testing campaigns

Your suppression system should prevent messages to hard bounces, unsubscribes, spam complainers where feedback is available, and addresses manually marked do-not-contact. Test this with non-production addresses before any major send.

For example, add audit-test@example.net to your global unsubscribe list, queue it for a marketing campaign, and verify that the send is blocked or skipped. Then add a test address to a transactional-allowance rule if your policy permits transactional messages after marketing opt-out, and verify that only the approved transactional category can send.

An unsubscribe link that merely changes a preference-center screen is not sufficient if the address remains eligible for the same marketing stream. The result you want is an auditable suppression event with a timestamp, source, scope, and durable enforcement across all sending tools.

In the United States, commercial email is subject to CAN-SPAM requirements, including a clear opt-out mechanism and honoring opt-out requests within 10 business days. The legal deadline is not a deliverability target: operationally, process marketing unsubscribes immediately or as close to immediately as your system allows. (ftc.gov)

Validate before a risky import

Address verification can help catch obvious syntax problems, disposable domains, and some mailbox risks before a first send. It cannot prove a person consented, wants your mail, or will engage with it. Use verification as one layer beside explicit permission, confirmation workflows, and cautious rollout.

Before importing a list with uncertain quality, run a sample through an address verification workflow, remove clear failures, and send the cleanest, most recently active segment first. Do not send the entire file simply because it passed a superficial syntax check.

Review message design, content, and unsubscribe behavior

Content is not a list of forbidden words. Mailbox providers evaluate message characteristics in the context of sender history and recipient response. A deliverability assessment should therefore look for misleading, inconsistent, or unexpectedly aggressive behavior rather than trying to game a word filter.

Audit every message stream for the following:

• A stable, recognizable From name and From address.
• A subject line that accurately describes the message.
• A visible physical mailing address where required for commercial mail.
• A clear footer unsubscribe link for marketing messages.
• No deceptive display names, reply addresses, or URL domains.
• A reasonable text-to-image balance and meaningful plain-text alternative.
• Links that use domains your organization controls or has intentionally configured.
• Templates that render correctly on mobile and do not hide key content in images.

For marketing and subscribed bulk mail, add one-click unsubscribe headers in addition to the visible footer link. RFC 8058 defines the signal that tells a mail client an HTTPS List-Unsubscribe endpoint supports a one-click POST request. (rfc-editor.org)

A practical header pattern is:

List-Unsubscribe: <https://email.example.com/unsubscribe/u/abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Your HTTPS endpoint must accept the one-click POST and unsubscribe the recipient without forcing a login, survey, password, or confirmation click. The token must identify the recipient and mailing context safely; do not expose an email address in a predictable URL parameter.

Gmail states that bulk senders of marketing and subscribed messages need one-click unsubscribe, alongside a visible body link. Yahoo’s sender guidance also emphasizes authenticated, wanted mail and honoring the expectations established at signup. (support.google.com)

Use mailbox-provider signals, not only ESP dashboards

Your ESP sees what it handed to receiving servers. Mailbox providers see additional information: recipient spam reports, reputation, authentication failures, and delivery errors. Use both perspectives.

Gmail Postmaster Tools

Google Postmaster Tools provides eligible senders with dashboards for spam rate, IP reputation, domain reputation, authentication, encryption, and delivery errors for mail sent to personal Gmail accounts. (support.google.com)

Set it up for the domains you actually use to authenticate mail. Review the charts weekly during normal operation and daily during a recovery or high-volume campaign. Look for changes that line up with a concrete event: an imported list, a new template, a new sending tool, a sender-domain change, an increase in frequency, or a sudden volume increase.

A short-lived complaint spike is still important even if the monthly average looks acceptable. Segment the campaign that caused it, pause its least engaged audience, and inspect its acquisition source and promise—not just its HTML.

Microsoft and corporate recipients

Microsoft 365 evaluates SPF, DKIM, and DMARC together and exposes authentication results in the Authentication-Results header. Its guidance also notes that forwarding can cause SPF failure because the forwarding server’s IP is not in the original sender’s SPF record. (learn.microsoft.com)

For Outlook.com or Hotmail audiences, preserve rejection and junk-feedback evidence where available, but avoid assuming one dashboard tells the complete story. Corporate Microsoft 365 tenants can apply their own policies, allow lists, gateways, and security products. When a major customer reports missing mail, ask for the full SMTP response or message trace outcome rather than relying on a screenshot of an empty inbox.

Run controlled inbox-placement tests

Seed testing is useful when you treat it as a diagnostic sample rather than a universal inbox guarantee. Create test mailboxes at the provider families most represented in your real list, then send the same production message to them alongside a controlled group of opted-in recipients.

For each test, record:

1. Send timestamp and campaign ID.
2. Exact From domain, DKIM selector, Return-Path domain, and sending IP or provider.
3. Whether the message was accepted.
4. Folder placement: Inbox, Promotions, Spam, or missing.
5. Authentication results from full headers.
6. Any provider response or warning.

Repeat tests after meaningful changes. One seed that lands in the inbox does not prove broad inbox placement, but a pattern of spam placement across multiple providers is actionable evidence. Pair seed tests with real audience metrics: complaints, unsubscribes, clicks, conversions, bounces, and provider-level error rates.

Be careful with external “mail tester” scores. They can catch malformed HTML, missing authentication, and obvious configuration issues, but they cannot accurately model the private reputation and individual engagement signals of every recipient. Treat the score as a checklist, not a verdict.

Worked example: diagnosing a newsletter that goes to spam

Assume Acme Analytics sends a weekly product newsletter from hello@acme.example. Delivery reports say 98.8% of messages were delivered, but clicks fell sharply and internal Gmail test accounts increasingly see the newsletter in Spam.

Step 1: create the evidence sheet

Acme splits results by provider for the last four sends. Gmail has low clicks and a rising complaint rate; Yahoo and corporate domains are stable. The team also sees that the decline began after importing webinar leads and increasing frequency from weekly to three times per week.

That timing creates a hypothesis: the imported cohort and frequency increase hurt Gmail reputation. It is not yet proof.

Step 2: inspect a received Gmail message

The headers show:

spf=pass smtp.mailfrom=mail.acme-mail.example
dkim=pass header.d=mailer.vendor.example
dmarc=fail header.from=acme.example

SPF passes, but it authenticates mail.acme-mail.example. DKIM passes, but it signs as mailer.vendor.example. Neither domain aligns with the visible From domain acme.example, so DMARC fails.

Step 3: fix alignment before changing creative

Acme configures the email provider’s custom-domain setup so that messages are DKIM-signed with d=acme.example or an aligned subdomain such as d=news.acme.example. It publishes the provider-supplied DKIM DNS records and changes the Return-Path to an aligned custom bounce domain where supported.

It also publishes:

_dmarc.acme.example TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme.example; adkim=r; aspf=r"

After DNS propagation, Acme sends a new test. Headers now show SPF pass, DKIM pass with an aligned d= value, and DMARC pass.

Step 4: isolate the audience problem

Acme does not immediately resume sending three newsletters a week to everyone. It pauses the webinar-imported audience from promotional sends, retains the original confirmed newsletter subscribers, and returns to the established weekly cadence.

The team adds one-click unsubscribe headers, makes the footer unsubscribe link prominent, and changes the webinar follow-up sequence so it clearly states what subscribers will receive and how often.

Step 5: verify that it worked

Over the next several sends, Acme checks:

• Gmail Postmaster authentication data for sustained passing status.
• Gmail spam-rate trend against the 0.3% maximum Google publishes for senders.
• Gmail seed placement for the same production template.
• Complaint and unsubscribe rates by the old subscriber cohort versus the webinar cohort.
• Clicks and conversions per delivered message, not just total clicks.

The assessment is successful only if the technical result stays correct and recipient signals recover. If DMARC passes but complaints remain elevated, the remaining issue is audience expectation, frequency, or content—not DNS.

Common assessment mistakes and what to do instead

Mistake: treating a high delivery rate as proof of inbox placement

Do instead: Compare accepted mail with provider-specific reputation data, seed placement, complaints, and engagement trends. Acceptance is an early checkpoint, not the finish line.

Mistake: adding DMARC enforcement before knowing every sender

Do instead: Start with reporting, inventory all legitimate services, fix alignment, then move toward enforcement in stages. DMARC reports are a discovery tool as well as a security control.

Mistake: changing every variable during a deliverability incident

Do instead: Write a hypothesis, make one material change, preserve a control segment, and compare the next sends. Controlled recovery produces knowledge you can reuse.

Mistake: warming a domain by sending to unengaged contacts

Do instead: Start with people most likely to expect and value the mail. Growth should follow demonstrated positive recipient response, not a calendar-based volume target.

Mistake: using an unsubscribe process as a retention funnel

Do instead: Make the unsubscribe action immediate and straightforward. A difficult exit encourages spam complaints, which are worse for both compliance and reputation.

Mistake: assuming a new ESP automatically solves reputation

Do instead: Fix consent, segmentation, authentication, sending cadence, and stream separation first. Moving platforms without changing sending behavior often transfers the underlying problem to a new domain or IP.

Turn the assessment into an ongoing operating routine

Deliverability is not a project you close forever. It is a feedback system that needs ownership and a predictable review cadence.

Assign one person or team to own the following recurring checks:

• Weekly: complaint, unsubscribe, hard-bounce, deferral, and conversion trends by stream and mailbox provider.
• Monthly: DMARC aggregate reports, domain inventory, provider configuration changes, and suppression-system tests.
• Before a major campaign: recipient-source review, volume plan, audience exclusions, one-click unsubscribe test, rendering check, and seed test.
• After an incident: preserve headers and SMTP errors, document the timeline, identify the triggering change, and record the fix and verification criteria.

Keep a sender register with the tool name, purpose, From domain, Return-Path domain, DKIM selector, SPF authorization method, volume, owner, and last review date. That register prevents the most common authentication failure: a business team launches a new tool that sends as the company without coordinating DNS and deliverability controls.

The strongest outcome of an email deliverability assessment is not an attractive score. It is a documented sending system where every message stream has a justified audience, authenticated identity, working opt-out path, measurable provider signals, and a clear owner when something changes.

FAQ

What is included in an email deliverability assessment?

A complete assessment reviews SPF, DKIM, DMARC, TLS, reverse DNS, message headers, sending infrastructure, bounce and complaint data, list sources, suppression controls, unsubscribe behavior, content consistency, mailbox-provider reputation signals, and controlled inbox-placement tests.

How do I know whether SPF, DKIM, and DMARC are working?

Send a real message to a test mailbox and inspect its full headers. Look for spf=pass, dkim=pass, and dmarc=pass in Authentication-Results. For DMARC, confirm that the passing SPF or DKIM domain aligns with the visible From domain.

Is a 98% delivery rate good deliverability?

It shows that many receiving servers accepted your messages, but it does not show inbox placement. Review spam-folder placement, Gmail Postmaster data where available, complaints, unsubscribes, engagement, and provider-specific errors before drawing a conclusion.

How often should I run an email deliverability assessment?

Run a full audit before changing providers, domains, major list sources, or sending volume. For normal operations, monitor core metrics weekly and review authentication, DMARC reports, suppression logic, and sender inventory at least monthly.

Will changing my sending provider fix spam-folder placement?

Not necessarily. A provider can improve tooling and infrastructure, but mailbox providers still evaluate authentication, sending-domain history, list quality, recipient complaints, and engagement. Fix the evidence identified in the assessment before assuming a platform migration is the answer.