Email deliverability survey results should tell you more than whether a campaign was technically accepted by a receiving server. A useful survey reveals whether your mail is authenticated, wanted, consistently sent, easy to leave, and actually reaching the inboxes that matter.

Many teams discover a deliverability problem only after opens or conversions fall. That is too late—and open rate alone is not a reliable alarm, because Apple Mail Privacy Protection can preload tracking pixels and make messages appear opened even when the recipient did not actively read them. A better approach is to run a structured survey of your DNS, sending infrastructure, recipients, message headers, engagement signals, and mailbox-provider feedback. (mailchimp.com)

What an email deliverability survey is—and is not

An email deliverability survey is a repeatable diagnostic questionnaire and evidence-gathering process. It assesses the conditions that influence whether a mailbox provider places a message in the inbox, spam folder, another tab, defers it, or rejects it.

It is not a single “deliverability score” from a generic checker. Nor is it an email marketing satisfaction survey sent to subscribers. Those can be useful research exercises, but they cannot validate DNS alignment, identify a broken unsubscribe endpoint, or explain a wave of provider-specific deferrals.

Delivery versus deliverability

Keep these terms separate:

Delivery means the receiving mail system accepted the message during SMTP delivery. A 250 response is usually evidence of acceptance, not evidence that the recipient saw it in the inbox.
Deliverability is the broader outcome: whether legitimate mail reaches a visible, appropriate location and earns enough positive recipient and provider signals to keep doing so.
Inbox placement is the narrowest outcome: the portion of tested or observed messages that arrive in the primary inbox rather than spam, promotions, or another filtered location.

A campaign can show a high delivery rate while performing poorly in the inbox. For example, messages accepted by Gmail may still be categorized or filtered based on authentication, user reports, sender reputation, and other signals. Google’s Postmaster Tools exposes dashboards for spam rate, reputation, authentication, and delivery errors precisely because SMTP acceptance does not tell the whole story. (support.google.com)

When to run the survey

Run the full survey before a large launch, after changing an email service provider, when adding a new sending domain, or whenever complaint rates, bounces, engagement, or conversion from email shifts unexpectedly. For an established program, repeat the core checks every month and the full audit every quarter.

Do not wait for a major failure. Authentication errors, list decay, and a gradual rise in recipient complaints usually begin as small operational changes: a new CRM integration, an abandoned form, a new transactional sender, or a team exporting leads and uploading them without consent metadata.

Use this survey at three levels:

Domain level: Is example.com authorized and protected wherever it sends email?
Stream level: Are marketing, product, lifecycle, support, and transactional messages separated and governed appropriately?
Campaign level: Does one specific message have the expected headers, recipient selection, consent basis, cadence, and unsubscribe behavior?

Who should answer it

Deliverability is cross-functional. The survey owner may be in lifecycle marketing or engineering, but the answers often sit with several people:

Engineering or IT owns DNS, APIs, SMTP settings, and event logging.
Marketing owns acquisition sources, segmentation, frequency, copy, and suppression rules.
Legal or privacy teams own consent language, records, and regional compliance decisions.
Support owns complaint themes and “I never signed up” evidence.
Finance or operations may own the contract and configuration of the email platform.

Assign one accountable owner for each answer. “The vendor handles that” is not an answer until someone can show the exact configuration and the sending identity it applies to.

The 30-question email deliverability survey

Score each question as 2 = verified and healthy, 1 = partly true or not recently verified, or 0 = missing, broken, or unknown. Record evidence beside every answer: a DNS lookup, message header, provider dashboard screenshot, export, test result, or written process.

A perfect score is 60. The number is only a prioritization device; a single zero in authentication or unsubscribe handling can matter more than several weak points elsewhere.

Section 1: Sending identity and authentication

Do we maintain an inventory of every domain and subdomain used in the visible From address?
Do we know every platform that sends as each domain—marketing platform, application, help desk, CRM, billing tool, and employee mailbox service?
Does every active sending domain publish SPF, and is there only one SPF TXT record per domain?
Does every sending platform sign messages with DKIM?
Does the visible From domain align with either an authenticated SPF domain or DKIM domain for DMARC?
Does the organizational domain publish DMARC with an address that receives aggregate reports?
Are forward and reverse DNS records valid for sending IPs we control?
Are messages sent over TLS where the sending system supports it?

Gmail requires all senders to use SPF or DKIM, valid forward and reverse DNS for sending domains or IPs, and TLS. Gmail’s bulk-sender requirements apply when a sender sends more than 5,000 messages per day to personal Gmail accounts; those senders need SPF, DKIM, and DMARC. Yahoo likewise requires SPF or DKIM for all senders and SPF, DKIM, and DMARC for bulk senders, with DMARC alignment. (support.google.com)

Section 2: List acquisition and recipient quality

Can we name the source, timestamp, and consent language for every marketing subscriber?
Are purchased, scraped, rented, appended, or unverifiable lists prohibited in policy and in practice?
Does each signup flow use a clear description of what will be sent and how often?
Is double opt-in used where it suits the risk profile, or do we have another reliable verification method?
Do we validate addresses at signup and handle typos without blocking legitimate users unnecessarily?
Do hard bounces immediately suppress an address from future promotional mail?
Do we suppress repeated soft bounces or delivery deferrals according to a documented policy?
Do we identify long-inactive subscribers and run a re-permission, sunset, or suppression process?

The aim is not to make the list as large as possible. It is to make the list defensible and responsive. A smaller list of people who asked for the mail creates fewer bounces, complaints, and ignored messages than a large list accumulated through vague consent or imports.

If you need a quick pre-send check for a single address, an email address verification tool can help catch obvious format and domain problems. It does not prove consent, prove that a mailbox belongs to a particular person, or replace bounce processing after you send.

Section 3: Message construction and unsubscribe handling

Is the From name recognizable to a subscriber who joined the list?
Does the visible From address use the same branded domain customers expect?
Are Reply-To addresses monitored, or deliberately routed to an appropriate support process?
Are subject lines accurate and consistent with the message body?
Is a physical postal address included when required by the jurisdictions in which you operate?
Does each marketing email have a conspicuous body unsubscribe link?
Does it also include a functional List-Unsubscribe header?
For subscribed marketing traffic, does it implement one-click unsubscribe using List-Unsubscribe-Post?
Are unsubscribe requests applied across the relevant marketing stream without requiring login, payment, or unnecessary steps?

The U.S. CAN-SPAM Act prohibits false or misleading header information and deceptive subject lines, and requires a method to opt out of future commercial email. The law gives senders up to 10 business days to honor an opt-out request; Yahoo’s sender guidance is stricter for its own ecosystem and says bulk senders should honor unsubscribes within two days. Design for the stricter operational standard when it applies rather than treating the legal maximum as a target. (ftc.gov)

Section 4: Reputation, cadence, and monitoring

Do we separate transactional and promotional mail by stream, tags, or subdomains so reporting and suppression rules are clear?
Do we increase volume gradually when introducing a new domain, IP, stream, or large segment?
Do we measure complaints, hard bounces, deferrals, unsubscribes, and conversions by mailbox-provider domain?
Have we verified access to Google Postmaster Tools for sending domains with enough Gmail volume to produce data?
Do we investigate provider-specific failures using SMTP logs and full message headers—not only campaign dashboards?

Yahoo tells senders to keep spam complaint rates below 0.3%, and Gmail’s guidelines similarly tell senders to keep the spam rate below 0.3%. Treat that figure as a ceiling, not a performance goal: a lower complaint rate is safer, and each provider’s measurement may not match the percentage shown in your own platform. (support.google.com)

How to score the survey and choose fixes

Add your points, but do not let an average conceal a critical failure.

51–60: Controlled. Maintain evidence, monitor trends, and test major changes before rollout.
41–50: At risk. Fix all zeroes and build a defined remediation plan for one-point answers.
31–40: Fragile. Pause aggressive list growth and high-volume experiments until authentication, list governance, and unsubscribe functions are verified.
0–30: High risk. Treat email operations as an incident. Stop sending to unverified or imported marketing audiences, fix foundational controls, and restart gradually with proven subscribers.

Override rules: zeroes that demand immediate attention

Regardless of total score, prioritize these findings first:

No DKIM signature on mail from a branded domain.
DMARC missing, invalid, or not aligned for a bulk stream.
An unsubscribe link or one-click endpoint fails.
Hard bounces continue receiving promotional mail.
A new or purchased list cannot show consent evidence.
Recipient complaints spike at one mailbox provider.
SMTP logs show recurring 4xx deferrals or 5xx permanent rejections.

A 4xx SMTP response is temporary and can be retried according to a bounded retry policy; a 5xx response is permanent and should not be blindly retried. Yahoo explicitly advises not retrying 5xx errors and removing addresses that generate those bounces. (senders.yahooinc.com)

Verify the technical foundation with real records and headers

Survey answers are useful only when you inspect the artifacts. Start with DNS, then send a live test email and read its original headers.

SPF: authorize the systems that send mail

An SPF policy is a DNS TXT record at the sending domain. Its exact value depends on your providers, so never copy an include: mechanism from an example unless your provider documents it for your account.

A simplified example looks like this:

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

Important checks:

Publish one SPF record, then combine authorized senders into that policy.
Confirm every sender is represented: office mail, marketing, application notifications, support platforms, and any CRM.
Use -all only once you are sure the inventory is complete; it signals a hard fail for senders not covered by the policy.
Check the return-path or envelope-from domain in a real message. SPF authenticates that identity, not automatically the visible From identity.

Google describes SPF as a way to help prevent outgoing mail from being marked as spam and recommends identifying all email senders before building the record. (support.google.com)

DKIM: verify that each platform signs

DKIM adds a cryptographic signature to the message. A provider normally gives you a selector and a public key record such as:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

The actual key is long and provider-specific. Do not invent it, truncate it, or reuse a key copied from another vendor. In a received message header, look for an Authentication-Results line that says dkim=pass and a DKIM-Signature whose d= domain is yours or is aligned with yours.

Be careful with systems that modify messages after signing. Adding a disclaimer, rewriting links, or altering the body in an outbound gateway can break a DKIM signature. Google specifically warns that outbound gateways which modify outgoing mail can interfere with DKIM. (support.google.com)

DMARC: connect visible identity to authentication

DMARC tells receiving servers what to do when authentication does not pass. Begin with monitoring, make sure every legitimate sender is accounted for in reports, then move toward enforcement when appropriate.

A practical starting record is:

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

This example uses p=none to request reporting without asking receivers to quarantine or reject mail. rua is where aggregate reports are sent. The relaxed adkim=r and aspf=r settings are common starting choices, but your security team may choose strict alignment later. After validating every sender, a policy might move to p=quarantine or p=reject; make that change deliberately because it affects unauthorized mail that claims to be from the domain.

Google explains that DMARC policies can be reject, quarantine, or normal delivery, and recommends reviewing reports to ensure legitimate sources authenticate before tightening enforcement. (support.google.com)

One-click unsubscribe: inspect the actual headers

For marketing mail, a visible footer link is necessary but not the same thing as a one-click header. A typical implementation includes both headers below:

List-Unsubscribe: <https://email.example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The URL must accept the one-click POST request and unsubscribe the recipient without asking them to sign in or fill out a form. Use an opaque, recipient-specific token rather than exposing an email address in the URL. RFC 8058 defines this signaling method in part to avoid accidental unsubscribes caused by clients fetching ordinary unsubscribe URLs. Yahoo publishes the same header pattern and requires a clearly visible body unsubscribe link as well. (datatracker.ietf.org)

Run a controlled inbox-placement test

An inbox-placement test should complement—not replace—provider feedback and real subscriber data. Create seed accounts at the mailbox providers that represent your audience, such as Gmail, Yahoo Mail, Outlook.com, and any business mailbox service heavily used by your customers.

Test protocol

Create a small seed list that is not included in ordinary campaigns.
Add the seed addresses to a normal, consented segment with the same message and configuration your audience receives.
Send a representative campaign or a controlled test at your ordinary cadence.
Record for each seed: accepted, inbox, tab/category, spam, missing, deferred, or rejected.
Save the full headers from at least one message at each provider.
Repeat after the fix, using comparable content and volume.

Do not treat a handful of personal seed inboxes as a universal result. Placement can differ by recipient history, provider, message type, and sending stream. The test is most useful for spotting obvious breakage—such as a DMARC failure, a spam-folder result across multiple seeds, or a broken unsubscribe request—and for comparing before-and-after results under similar conditions.

What to capture from the headers

Look for:

Authentication-Results: SPF, DKIM, and DMARC pass/fail results.
From: the visible identity recipients see.
Return-Path: the envelope identity relevant to SPF.
DKIM-Signature: especially the d= domain and s= selector.
List-Unsubscribe and List-Unsubscribe-Post.
Received lines: the path and timestamps through mail servers.
Provider-specific filtering headers, if present.

This evidence lets you distinguish “the email platform said it sent” from “the destination evaluated it correctly.”

Worked example: auditing a SaaS product-update newsletter

Imagine Acme Analytics sends a weekly product-update newsletter from updates@acmeanalytics.com. It has 18,000 subscribers, uses one provider for marketing campaigns and a separate application service for password resets. The marketing manager notices stable reported delivery but falling trial activations from newsletters.

Step 1: complete the survey

The team scores 38/60. The results uncover four high-impact issues:

The marketing provider signs DKIM as provider-mail.example, not acmeanalytics.com.
The domain has an SPF record, but it only authorizes the employee mailbox service, not the marketing provider.
The newsletter footer has a preference-center link, but the message lacks one-click unsubscribe headers.
A CSV import from an event includes addresses with no recorded marketing consent.

The reported delivery rate did not expose these gaps. The survey did because it asked for the exact sending source, authentication result, and evidence of permission.

Step 2: repair authentication

Acme adds the provider’s documented DKIM DNS record for a selector such as mktg1._domainkey.acmeanalytics.com. It updates the single SPF record to include both the employee mail service and the marketing provider, following each vendor’s documentation.

It then adds DMARC monitoring:

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

After DNS propagation, the team sends a test campaign to its seed accounts and checks headers. The target state is spf=pass, dkim=pass, and dmarc=pass, with the visible From domain aligned to a passing SPF or DKIM identity.

Step 3: fix subscription controls

The engineering team configures its provider’s one-click unsubscribe feature or adds the headers through its sending API. It verifies that the endpoint accepts an RFC 8058-style POST, suppresses the recipient from the newsletter stream, and returns an appropriate success response.

The event-import addresses are not mailed as a marketing audience until the team obtains a clear opt-in. Existing subscribers receive the normal newsletter; stale recipients are segmented for a re-engagement message and suppressed if they do not respond according to the company’s documented policy.

Step 4: measure whether it worked

For four comparable weekly sends, Acme tracks:

SPF/DKIM/DMARC pass rates in sampled headers.
Gmail Postmaster Tools reputation, spam-rate, authentication, and error dashboards where data is available.
Hard bounces, deferrals, complaints, unsubscribes, and clicks by mailbox-provider domain.
Seed placement at Gmail, Yahoo, and Outlook.com.
Trial activations attributable to newsletter clicks, not only opens.

Google says Postmaster Tools provides data and diagnostics including delivery errors, spam reports, feedback loops, and compliance status. This makes it a better health check than a blended campaign dashboard, though it should be interpreted alongside your own event logs. (support.google.com)

The audit is successful when the technical controls pass consistently, unsubscribe requests work, invalid or unconsented recipients are excluded, provider errors decline, and downstream engagement improves without an increase in complaints. It is not successful merely because one test message reaches one employee’s inbox.

Common survey mistakes that hide the real problem

Using open rate as the primary deliverability metric

Open rate can still be directionally useful inside the same program, but it is not a clean proxy for inbox placement. Apple Mail Privacy Protection can inflate opens, and security tools can generate bot opens or clicks. Prioritize provider feedback, authentication status, complaints, bounce categories, click quality, conversion, and controlled seed evidence. (mailchimp.com)

Counting all bounces as one number

Separate permanent failures, temporary deferrals, and vendor-side suppression. A hard bounce may mean an invalid mailbox; a temporary failure may reflect throttling or a transient receiving-system issue. Combining them hides the action required.

Fixing the content before verifying the identity

Copy matters, but authentication and permission come first. A polished subject line cannot compensate for missing DKIM, an unaligned DMARC identity, repeated unwanted mail, or a malfunctioning opt-out flow.

Testing with a different stream than production

If the test sender uses a different domain, IP pool, From address, or provider configuration, it does not validate the campaign that has the problem. Test the real stream—or document exactly why it differs.

Changing ten variables at once

Do not simultaneously change provider, domain, list source, frequency, copy, template, and authentication policy. Make a small set of traceable changes, log the date and affected stream, then compare results over enough comparable sends to see a pattern.

Build the survey into an operating system

A survey has value only if it becomes a routine. Put these controls in place:

Maintain a sender inventory with domain, subdomain, vendor, purpose, From address, return-path, DKIM selector, volume, and owner.
Require a deliverability review for new forms, imports, providers, and sending domains.
Route DMARC aggregate reports to a monitored mailbox or reporting tool.
Review provider-domain metrics after every major campaign and at least monthly for ongoing programs.
Keep an incident log with symptoms, headers, error codes, changes made, and before/after outcomes.
Train marketers to distinguish transactional messages from promotional mail and to use consent metadata when building segments.

If you send application email through an API, make DNS checks, suppression handling, and unsubscribe behavior part of the deployment checklist—not a manual cleanup after launch. Your email API setup documentation should be treated as an implementation baseline, while mailbox-provider requirements and your own sending patterns determine the operational controls around it.

Conclusion: turn deliverability into evidence, not guesswork

The best email deliverability survey does not promise an instant inbox-placement score. It forces the questions that reveal controllable risk: Who is sending? Is the visible identity authenticated and aligned? Did recipients ask for the message? Can they leave easily? Are mailbox providers reporting problems? Are performance changes visible beyond unreliable opens?

Run the audit before scale, preserve the evidence, and treat its zero-score answers as a prioritized engineering and marketing backlog. That discipline is more durable than chasing subject-line myths or relying on a platform’s “delivered” metric.

FAQ

What is a good score for an email deliverability survey?

A score above 50 out of 60 suggests that core controls are documented and verified. More important than the total is the absence of critical failures: missing authentication, unverified list sources, broken unsubscribe handling, or repeated unresolved provider errors should be fixed immediately.

Does SPF alone guarantee inbox placement?

No. SPF is only one authentication method, and it authenticates the envelope sender rather than automatically proving alignment with the visible From domain. Gmail and Yahoo expect stronger controls for bulk sending, including SPF, DKIM, and DMARC. (support.google.com)

How often should I run an email deliverability survey?

Run a lightweight review monthly, a full survey quarterly, and an additional review before major volume increases, new providers, new domains, or large list imports. Also run it immediately when complaints, deferrals, spam-folder reports, or conversion performance change materially.

Is a visible unsubscribe link enough?

Not for bulk marketing messages at providers that require one-click unsubscribe. Yahoo states that a body link alone is insufficient; senders should implement the List-Unsubscribe header, preferably with the RFC 8058 one-click method, while retaining a clear body link. (senders.yahooinc.com)

Why did my delivery rate stay high while results declined?

A high delivery rate normally shows that messages were accepted, not that they reached the inbox or were welcomed. Check provider-level spam and error data, authentication results, complaints, deferrals, seed placement, click quality, and conversions before concluding that content is the problem. (support.google.com)

Email Deliverability Survey: A Practical Audit for Better Inbox Placement