Most audits are glorified spam-tester runs against a few seed inboxes. Ours is a log-level forensic review of your sending stack, conducted by engineers who run KumoMTA, PowerMTA and MailerQ in production. We tell you exactly what is broken, what is at risk, and what to fix first — with a written report, evidence and a remediation roadmap. EU-based, signed DPA on request.
For the better part of a decade, "deliverability" was a soft signal. You configured SPF and maybe DKIM, set DMARC to p=none and forgot about it, watched your open rates and adjusted subject lines if numbers dipped. Mailbox providers enforced rules sporadically. Spam complaints under one percent were considered fine. A 90% inbox placement rate was respectable. Most of the work was content optimization.
That world ended on February 1st, 2024. Google and Yahoo introduced bulk sender requirements with hard enforcement: any domain sending 5,000 or more messages a day to their users must have valid SPF, valid DKIM, a published DMARC record at minimum p=none, and must keep spam complaint rates under 0.3% (with the practical safe ceiling at 0.1%) under threat of message throttling, junk-folder placement, or outright rejection. The grace period ended quietly. Senders who had passed audits in 2023 woke up in 2024 to deliverability collapses they did not understand.
Microsoft followed on May 5th, 2025, with effectively the same requirements for Outlook.com, Hotmail.com and Live.com (same 5,000-messages-a-day threshold, same SPF/DKIM/DMARC mandate)s, same enforcement actions. As of 2026, between Gmail, Yahoo and Microsoft, more than 90% of consumer mailbox capacity in Europe and North America operates under these rules. Enterprise inboxes (Microsoft 365, Google Workspace) inherit the same baseline.
The catch is that "valid SPF and DKIM" is not the same as "passing SPF and DKIM checks." Authentication can pass while still failing alignment, which is what DMARC actually measures. A surprising number of legitimate senders are publishing records that look correct, pass spot-checks in MxToolbox or mail-tester.com, and still drift toward spam folder placement because alignment is broken in places that only show up in raw mailbox provider logs. We see this every week with new clients.
This is what a deliverability audit is for in 2026. Not "are my records there." But: are they aligned, do they survive forwarding chains, do they hold up under your specific sending volume profile, and what do mailbox providers actually see when they receive your traffic? Those are evidence-based questions. They require log access, header analysis, sender-reputation telemetry from Google Postmaster Tools, Microsoft SNDS and Sender Score, and the technical context to interpret the data correctly. Anything less is theater.
Most senders looking for a "spam fix" are convinced the issue is content. In our experience auditing more than 240 domains in the last three years, content is the cause in roughly 8% of cases. The rest are infrastructure, authentication, reputation, list hygiene or volume-pattern issues. Here are the six signals where an audit is almost always the right investment instead of more A/B tests.
Stable senders rarely lose 20 points of open rate from content drift. When the drop is sudden and you have not changed lists, copy or subject patterns, the cause is almost always reputation decay or an authentication change you did not notice (a vendor that quietly added a new sending IP, a DNS provider that consolidated records, an ESP that rotated its DKIM selector. An audit pinpoints which one.
If your spam complaint rate is anywhere near 0.3% on Postmaster Tools or you have not personally verified that every sending source aligns under DMARC, you are at risk. Mailbox providers do not warn you before throttling. The first sign is usually a 30–60% drop in open rates over two weeks, by which point recovery takes months. An audit gives you the proof of compliance, and finds the gaps before they cost you revenue.
A migration is the single most common moment for deliverability collapse. Records get half-applied, DKIM selectors stop being signed, IP warming gets compressed because of business pressure. A pre-migration audit gives you the baseline to migrate against, the warming plan that respects your volume, and the rollback signals to watch in the first 30 days post-migration. We have seen six-figure quarterly revenue impacts from skipped migration audits.
Almost every B2B organization with 50+ employees sends from at least 4 distinct platforms, usually more. Marketing automation, support helpdesk, billing system, sales CRM, and one or two SaaS tools nobody remembers signing up for. Each has its own SPF and DKIM requirements. Each can break alignment quietly. An audit produces a documented sender map (what we call a sender inventory) that maps every system, every selector, every IP and every authentication chain.
A blocklist appearance is a symptom. Removing the listing without diagnosing the cause is like taking aspirin for chest pain. If you do not know what behavior triggered the listing (a complaint spike, a spamtrap hit, a compromised account, a content-filter trigger, or volume too aggressive for current reputation), you will be relisted within weeks. An audit identifies the underlying behavior and stops the recurrence.
If your only deliverability KPI is "open rate," you are flying with no instruments. Open rate conflates inbox placement with engagement, and tracking pixels are increasingly blocked or pre-fetched. A real deliverability program tracks inbox-vs-tabs-vs-spam ratios per mailbox provider, sender reputation curves over time, and authentication pass rates from DMARC reports. An audit establishes that telemetry as a baseline so you can manage it forward.
Our audit methodology is structured around the model mailbox providers themselves use to evaluate senders. We do not run a checklist of public DNS lookups and call it a day. That takes 15 minutes and tells you almost nothing useful. We work through your sending stack the way an SRE works through a production incident: hypothesis, evidence, root cause, prioritized fix. Below is the exact sequence, what we collect at each step, and what you receive in writing.
We start with mapping what is actually sending mail on your behalf. Most organizations underestimate this list by 50% or more. We work with you to identify every platform that puts your domain in the From, Return-Path or DKIM signing position: marketing automation, transactional ESP, CRM email module, helpdesk autoresponders, calendar invites, billing systems, internal applications, monitoring tools, contractor tools that nobody documented. Each platform contributes a row to a sender inventory document with: vendor, business owner, technical owner, sending domain or subdomain, SPF inclusion, DKIM selector, authentication state, and last-verified date. This document alone is worth the audit fee for many clients. It is the missing artifact that explains why deliverability projects keep failing.
We pull the raw DNS records for every domain and subdomain in the sender inventory: SPF, DKIM (all known selectors), DMARC, MTA-STS, TLS-RPT, BIMI if applicable. We check syntax against current RFCs and current mailbox provider implementations (which sometimes diverge). We measure SPF DNS lookup count against the RFC 7208 limit of 10 (the number-one cause of silent SPF PermError failures we see) is exceeding this limit, which most senders do not realize until traffic starts disappearing. We verify DKIM key strength (1024-bit minimum, 2048-bit recommended) and selector rotation hygiene. We confirm DMARC alignment configuration (relaxed vs strict, both for SPF and DKIM, set independently via aspf and adkim tags). And we test whether the visible From domain actually aligns with at least one of SPF or DKIM under the conditions your senders are using, which is the only thing DMARC enforcement actually evaluates.
We connect to your Google Postmaster Tools, Microsoft SNDS and Sender Score (where available) and pull 90 days of historical telemetry. We chart the curves of: domain reputation (High / Medium / Low / Bad on Google), IP reputation per sending IP, spam rate trajectory, DMARC compliance percentage, encryption rate, and feedback loop activity. We identify the inflection points (the days reputation changed direction) and correlate them against your business calendar: campaign sends, list imports, vendor changes, code deploys. This is where the actual story of your deliverability decline (or rise) becomes visible. We have seen reputation drops perfectly aligned with a Friday afternoon ESP migration, with a single recurring system email that was triggering complaint loops, with a CRM that started Bcc-ing entire deal records to support@, all sorts of patterns invisible without the data.
You send us 8 to 12 message samples representing your typical sending profile across providers (Gmail, Outlook 365, Yahoo, ProtonMail, regional providers), across send types (transactional, promotional, transactional-with-marketing-content, internal, automated), and ideally one or two that landed in spam. We extract the full SMTP headers from each (the long version, not the short summary most clients send us at first), and we walk the Received chain server by server. This is forensic work. We confirm: the actual SPF result the receiver computed and against which IP, the DKIM signature verification result and which selector, the DMARC alignment outcome and which mechanism passed, the receiver-side filter scores when available (X-Microsoft-Antispam, X-Spam-Status), the routing path and any unexpected hops or relays, the TLS state of each leg, and any mailbox-provider-specific clues like Gmail TID hashes or Microsoft IP reputation tokens. This phase routinely surfaces issues nobody had noticed: a forwarding rule breaking SPF, a third-party signature service stripping DKIM, an MTA-STS misconfiguration causing TLS downgrades.
For clients running their own MTA or hybrid infrastructure, we conduct an operational review. This is the phase where being the operator and not just an external consultant pays off. We have run KumoMTA, PowerMTA and MailerQ in production at scale. We know what their queue behavior looks like under retry storms, what their reputation isolation features actually deliver, where the configuration footguns are. For your stack we review: queue policy and per-tenant isolation, retry strategy and backoff curves, throttling rules per receiver domain (Gmail accepts traffic patterns Yahoo does not, etc.), bounce and complaint handling chains, IP rotation strategy if any, and the integration between your MTA logs and any reputation monitoring you have. Where you use a hosted ESP, we audit the ESP configuration: dedicated vs shared IP allocation, sub-account isolation, suppression list health, and which of the ESP-side knobs you have actually turned on vs left at defaults.
We finish the technical side and look at the human side: who you send to, what you send, and how recipients respond. This is where most "audits" start, and this is why most audits fail. Without the technical baseline from phases 1–5, you cannot tell whether engagement issues are causing the technical signals or being caused by them. With the technical foundation established, we now examine: list source documentation (where each segment came from, consent type, age), bounce profile per segment and per provider, complaint rate per segment, engagement decay curves, suppression list completeness and accuracy, content-pattern signals (link-to-text ratio, image-to-text ratio, URL shorteners, redirect chains, blacklisted hosts in HTML), and unsubscribe mechanism health (one-click List-Unsubscribe-Post, URL-based fallback, processing latency).
Everything from phases 1 through 6 gets synthesized into a single document: the audit report itself. The structure is the same every time: executive summary, severity-ranked findings, evidence appendix, remediation roadmap with effort estimates, and a 90-day monitoring plan to verify the fixes worked. We rank findings on two axes: severity (impact on deliverability if unfixed) and effort (how long the fix takes). The roadmap groups them into Quick Wins (under one day of work, immediate impact), Critical Fixes (under one week, meaningful impact), Strategic Changes (one to four weeks, major impact), and Watch List (monitor but do not fix yet). Every finding has explicit evidence in the appendix (header excerpts, DNS lookups, screenshots of telemetry, log lines). No assertions without proof. This is the document you give your CTO, your CMO, your DPO, your auditor.
We publish our checklist because (a) the value is in execution and interpretation, not in the list itself, and (b) most prospective clients want to verify there is no theater. The categories below are condensed from our internal audit playbook. The full version is 217 individual checks across DNS, headers, infrastructure, content, lists and engagement. The summary below covers the ones that account for ~85% of findings in real audits.
Multiple SPF records on the same domain make the entire record invalid under RFC 7208. Exceeding the 10 DNS lookup limit returns a PermError, which most receivers treat the same as no SPF at all. We check both, and we check every subdomain that signs DKIM or appears in Return-Path, not just the root.
1024-bit keys are still everywhere. Google generates them by default for Workspace. They are considered computationally weak and we recommend rotating to 2048-bit. We check key length per selector, last rotation date, and whether the public key in DNS matches what your MTA is currently signing with.
A DMARC record at p=none is mandatory under Gmail/Yahoo bulk sender rules. p=quarantine and p=reject are the maturity goal. We verify the record exists, parses cleanly, has rua= and ruf= reporting addresses that you can actually access, and has alignment mode appropriate to your sending pattern (relaxed for most senders, strict for high-security domains).
MTA-STS instructs receivers to require TLS for inbound connections to your MX servers, mitigating downgrade attacks. TLS-RPT lets you receive reports when STS is enforced or violated. Neither is mandatory under bulk sender rules but both are increasingly expected in EU enterprise compliance reviews.
BIMI displays your verified logo next to your messages in supporting clients (Gmail, Apple Mail, Yahoo). It requires DMARC at p=quarantine or p=reject minimum and an SVG Tiny logo, plus a Verified Mark Certificate from Entrust or DigiCert for Gmail brand display. We confirm eligibility and the steps to activation.
Microsoft in particular relies on FCrDNS as a reputation signal. Every IP you send from must have a PTR record that resolves back to a hostname which itself resolves back to that same IP. Generic provider-default PTRs (like ec2-x-x-x-x.compute-1.amazonaws.com) are filtered aggressively. We check every IP in your sending fleet.
Slow or unreliable DNS providers delay receiver-side authentication checks, which can cause timeouts that get treated as fail. Excessive CNAME chains can break DKIM lookups. We test resolution latency from multiple geographies and verify TTL values are consistent across record types.
Postmaster Tools is the only direct view into how Gmail evaluates your sending. Many clients have it set up and never look at it. We pull 90 days of data, identify reputation curve inflection points, and correlate them with your sending behavior.
SNDS provides per-IP reputation data for Microsoft consumer mailboxes (Outlook.com, Hotmail, Live). JMR is the Microsoft feedback loop. Both are essential for any sender with significant Microsoft volume and both are routinely missing from sender stacks we audit.
Sender Score is a 0–100 reputation metric used by some receivers and most reputation tools as a proxy. We pull your score history and benchmark against your industry vertical so you know what "good" looks like for your sending profile.
A current clean check is necessary but not sufficient. We check current listing status against 50+ RBLs and we check historical listings. Recurring listings on the same RBL indicate a behavioral pattern that needs identification, not just removal.
Gmail, Yahoo, AOL, Microsoft, and major regional providers offer feedback loops that report user complaints back to the sender. Most senders register one or two and forget the rest. We verify registration, complaint receipt rate, suppression mechanism, and trajectory.
Spamtraps are the third rail of deliverability. Hitting a single Spamhaus pristine trap can blacklist an entire IP range for weeks. We analyze your list source documentation, your bounce patterns and your complaint patterns to estimate spamtrap exposure risk and recommend list hygiene actions.
For clients running their own MTA, we review the actual configuration files, not just the public-facing behavior. We have operated each of the major MTAs and know where the footguns are: per-tenant isolation, retry storm protection, throttling per receiver, queue prioritization, suppression integration.
Gmail, Microsoft, Yahoo, Apple iCloud, regional providers like ProtonMail, GMX, Free.fr. Each has different throughput tolerances and different warming expectations. A throttling profile that works for Gmail will get you blocked at Yahoo. We review your per-receiver configuration and align it with current published and observed limits.
If you have multiple sending IPs, how traffic is distributed across them is itself a reputation strategy. Rotating evenly is rarely correct; concentrating volume on the strongest reputation IPs and rotating problem traffic to a quarantine sub-pool is. We assess your strategy.
Hard bounces that are not suppressed within minutes accumulate into reputation damage. Soft bounces that are treated as hard bounces remove valid recipients. We verify bounce taxonomy mapping and processing latency from receipt to suppression.
Forwarded mail breaks SPF by default unless ARC is in play. Some of your most engaged recipients forward your mail to assistants or distribution lists, and that forwarding silently fails authentication. We trace the common forwarding paths in your sending profile and recommend mitigation (typically ARC adoption or DMARC alignment via DKIM).
TLS is now table stakes for inbound to major mailbox providers. We confirm your outbound TLS posture, your inbound MX TLS posture, and that your minimum version is TLS 1.2 with modern cipher suites. TLS 1.0 and 1.1 are deprecated everywhere except a handful of legacy gateways.
GDPR Article 7 requires demonstrable consent. We do not advise on legal compliance (that is for your DPO), but we do verify that you can answer "where did this segment come from" for every segment you send to. Segments that fail that test are the ones generating spam complaints.
Aggregate metrics hide everything. We slice your engagement data by segment and by acquisition cohort to identify which sources are producing the most spam complaints, the highest unsubscribe rates, the steepest engagement decay. The answer is rarely the segment your team would have guessed.
Gmail, Yahoo and Microsoft now require a working one-click List-Unsubscribe-Post header for bulk senders, in addition to the legacy mailto and URL forms. We verify all three are present and that the URL form actually completes the unsubscribe within the time the user expects.
No content audit can predict every classifier outcome. But there are patterns: all-caps, excessive punctuation, financial trigger words in transactional content, mismatched promotional and transactional sending profiles. These patterns consistently elevate spam risk. We review a sample of your last 60 days of subject lines and flag patterns.
A single broken link can push a message to spam at Gmail. A URL pointing to a host with a poor reputation can blackhole the whole campaign. Long redirect chains look like phishing to filters. We sample your recent HTML and run automated and manual checks.
Mailbox providers expect sending volume to be predictable. Sudden 10x spikes (even on legitimate Black Friday sends) can trigger filtering if your warming history did not establish that ceiling. We chart your cadence against your reputation curve and recommend pacing adjustments.
A common complaint about deliverability audits is that the deliverable is a vague verbal summary, a few screenshots, and a calendar invite for a follow-up call. Ours is structured for due-diligence review. Every audit produces five artifacts:
CSV + signed-off PDF
A row-per-sender map of every system that sends mail on your domain. Vendor, business owner, technical owner, sending domain, SPF inclusion, DKIM selector, current authentication state, last verification date. This becomes a permanent operational artifact for your team — most clients add it to their internal wiki and update it quarterly thereafter.
PDF, 30 to 50 pages depending on tier
The main written deliverable. Executive summary (one page), scope and methodology (one page), severity-ranked findings (typically 15 to 40 findings depending on the size of your stack), evidence appendix (header excerpts, DNS records, telemetry charts, log lines — every assertion in the report has corresponding evidence in the appendix), remediation roadmap with effort estimates, and a 90-day monitoring plan.
PDF, single page
A board-distributable summary of the audit. Risk level (red, yellow, green) on each of: authentication, reputation, infrastructure, list health, content, engagement. Top three findings. Top three recommended fixes with business impact estimates. The version you forward to your CFO when she asks why we are spending money on email infrastructure.
CSV ready for Jira/Linear/Asana import
Every finding broken into rows with: ID, title, severity, effort, owner suggestion, evidence reference, recommended fix, dependencies. Imports cleanly into any project tracker. Most teams convert these directly into a sprint of remediation work.
PDF + Markdown source
A 30/60/90 day plan grouping findings into Quick Wins (under one day each), Critical Fixes (under one week each), Strategic Changes (one to four weeks), and Watch List (monitor without fixing). Each item has a recommended sequence — fixes that should not happen before others, fixes that unblock subsequent fixes, fixes that need to be staged with sending volume to avoid disruption.
Pricing is fixed by tier — no hourly billing, no scope creep. The tier you need depends on the size of your stack (number of sending sources, volume, complexity) and the level of formality you require in the deliverable.
For senders with a single domain and a single primary sending source who want a clean technical baseline.
Delivery: 5 to 7 business days
Ideal for
Small B2B SaaS sending under 100k emails/month, one ESP, one domain. Or a pre-launch deliverability check before a major campaign.
What's included
For senders with multiple domains, multiple sending platforms and an active deliverability concern.
Delivery: 7 to 10 business days
Ideal for
Mid-market B2B with marketing automation + transactional ESP + CRM email + helpdesk, sending 100k–2M emails/month. Or any organization investigating a recent reputation drop.
What's included
For complex stacks, regulated industries, or pre-migration baselines.
Delivery: 10 to 15 business days
Ideal for
Large B2B or B2C senders with 5+ sending platforms, 5M+ emails/month, GDPR/HIPAA/SOC 2 obligations, or planning a major migration in the next 90 days. Includes signed DPA on request and explicit compliance evidence.
What's included
All tiers are paid in advance, fully refundable within 7 days of kickoff if you decide the engagement is not the right fit. Refunds after delivery require explicit demonstration that the report does not contain the deliverables described — we have not had to issue one yet.
The timeline depends on tier and on how quickly your team can grant the access we need. Most of the calendar time in an audit is access provisioning, not analysis — DNS read access, Postmaster Tools delegation, header sample collection. Once we have access, the analysis itself runs fast.
We meet with the technical and business owners on your side. We confirm scope, confirm sending platforms in inventory, and walk through what access we need. You receive a written access request packet with exact instructions for each system. No NDA needed for Starter and Pro — we operate under our standard MSA. Enterprise tier includes a mutual NDA and DPA at this stage.
You grant the requested access — typically read-only DNS, read-only Postmaster Tools, header samples, MTA log excerpts where applicable. We confirm receipt of each item and begin parallel analysis as soon as anything is ready. If access is delayed by your DNS provider, your IT team or your ESP, we wait — we cannot audit what we cannot see. Most teams complete provisioning in 24 to 72 hours.
We work through the seven phases of the methodology in parallel where possible. You can reach the lead auditor by email throughout — not for status updates but for clarifications. We will sometimes circle back with a question that materially changes the audit direction (a sending source you forgot to mention, a dispute about a record, a vendor change in flight). Mid-engagement we send a one-paragraph status note when there is something material to report.
The lead auditor drafts the report. A second senior auditor reviews it for completeness, factual accuracy and clarity. Findings get re-checked. The executive summary is written last, after the body of the report is final, so it summarizes what was actually found rather than what was expected to be found.
You receive the full deliverable bundle by encrypted email. We schedule the remediation Q&A call(s) included in your tier. Each call is structured: walk through findings, answer questions, agree on remediation sequence. After the call you have everything you need to either remediate internally or to engage us (or another vendor) for the remediation work itself. We never auto-renew or auto-upsell — if you want ongoing monitoring, that is a separate engagement we discuss only if you raise it.
Real audit findings are confidential by NDA. The three composite cases below are constructed from common patterns we have seen repeatedly across audits. Names and specifics are fictional; the patterns are not.
Scope
Two sending domains, three sending sources (HubSpot, Postmark, custom transactional service)
Top finding
A custom transactional microservice deployed six months earlier was using a DKIM selector that pointed at a key removed from DNS during a registrar migration. SPF passed, DKIM failed silently, DMARC alignment failed, Gmail reputation dropped from High to Medium over 60 days. Fix: republish the DKIM public key, rotate the selector, monitor reputation recovery. Open rates recovered 22 points in 5 weeks.
Outcome
Audit fee €990. Estimated revenue impact of the fix in the first quarter post-audit: €180k attributed open-to-reply funnel.
Scope
Five sending domains, eleven sending sources, mix of Marketo, Salesforce Marketing Cloud, internal SMTP relay and helpdesk
Top finding
No DMARC reporting addresses were configured on any of the five domains, leaving the security team with zero visibility into impersonation attempts. SPF on three of five domains exceeded the 10 DNS lookup limit due to accumulated vendor includes. DPA documentation existed for two of eleven sending sources. Fix: full DMARC reporting setup, SPF flattening with subdomain delegation, sender inventory documentation as part of the DPA evidence pack.
Outcome
Audit fee €1,490. Output served as input to compliance team. GDPR review passed at next assessment cycle. Authentication posture upgraded from non-compliant to fully aligned.
Scope
One sending domain, two sending sources (Klaviyo, transactional gateway)
Top finding
Black Friday volume spike of 8x normal triggered Microsoft soft-throttling that compounded into Yahoo and AOL filtering over the following four weeks because complaint rate crossed 0.18% on Microsoft properties — under the 0.3% hard limit but visibly higher than the prior 90 days, which was enough for receivers to elevate filtering. Fix: complaint-source segmentation analysis identified two acquisition sources contributing 60% of complaints. Suppress, segment-level send-pause on Microsoft for 14 days, gradual ramp back. Reputation recovered in 35 days.
Outcome
Audit fee €990. Revenue recovery measured at €310k in the quarter post-fix versus the run-rate trough during the placement drop.
Free tools test the public-facing surface — DNS records, blacklist appearance, basic content scoring. They are useful and we use them ourselves as one input. They do not see your headers, your reputation telemetry from Postmaster Tools and SNDS, your MTA logs, your sender inventory, or your engagement patterns. They cannot tell you why your placement is dropping, only that it might be. The audit is the work of synthesizing the public signals with the private telemetry into a diagnosis. The free tools are a thermometer; the audit is the medical exam.
Postmastery is a strong audit shop and a fair comparison — they are operators too, and we respect their work. The structural difference is that we operate the MTA layer ourselves at production scale (KumoMTA, PowerMTA, MailerQ in seven datacenters), so we audit MTA configurations from the position of someone who runs them every day, not someone who has read the documentation. EmailTooltester runs a lighter-touch product priced at $350 — useful for small senders but less suited to multi-platform B2B stacks. InboxArmy bundles auditing into a managed service offering and starts at $2,500 because of that bundle. We are explicitly priced to be the entry point: a real audit at €490 to €1,490, with no obligation to buy any further service. If after the audit you want us to remediate, we will quote that separately. If you want another vendor to remediate, you walk away with a documented roadmap they can execute against.
No. The audit is a standalone professional service. About 60% of audit clients in the last 18 months have not been hosting customers at the time of audit, and roughly half of those subsequently chose to migrate some or all of their sending to us. We sell the audit on its own merits — if our recommendations end with "your current setup is fine, here is the maintenance plan," we say that, and we have done so with audits where the operational hygiene was already strong.
OS Domains GmbH is a Austrian entity, headquartered in Vienna, with EU-only sub-processors for the audit work itself (the MTA infrastructure has datacenter PoPs outside the EU, but the audit data (your DNS records, your headers, your telemetry) stays on EU infrastructure during the engagement). We sign a Data Processing Agreement on request, which Enterprise tier includes by default. If you have a DPO who needs to review specific Article 28 GDPR clauses, that review is included. We are not a US entity, we are not a subsidiary of a US entity, and we are not subject to US disclosure obligations under the CLOUD Act. For regulated EU industries (financial services, healthcare, public sector), this often matters more than the technical details.
Then the audit will say so, in writing, with evidence. We have run audits where the executive summary read something close to "your authentication is correct, your reputation is fine, your problem is that 30% of your list has not engaged in 18 months and you keep mailing them." That is a legitimate finding. The remediation roadmap in those cases focuses on list hygiene, segmentation, suppression policy, and re-engagement strategy. The audit is diagnostic; it tells you what is wrong, not what we wish were wrong so we could sell you infrastructure.
Yes, for Pro and Enterprise tiers. We have a mutual NDA template ready to sign, or we can review yours. The mutual NDA covers both sides — you protect your sending data and infrastructure details from us; we protect our methodology and any IP we share with you in the report. NDAs typically take 24 to 72 hours to negotiate; for time-sensitive engagements we can sign a one-page mutual NDA same-day.
We ask for sample messages from your own test accounts or from team-internal addresses, not from customer mail. Where business reality requires sampling customer-bound traffic, we ask you to redact the To header before sending us the sample (we do not need the recipient identity to read the Received chain) and we destroy the headers from our analysis storage 30 days after audit completion unless you specifically request retention.
Production. Staging environments lie. The point of the audit is to see how mailbox providers actually evaluate your real outbound traffic. We work from message samples and log excerpts — we do not need administrative access to your MTA, only read access to its configuration files and recent logs. For Enterprise tier we may request a brief screen-share session with an SRE or platform engineer on your side to walk through specific configuration questions.
Tell us. We have one of two responses: either we agree and reissue the corrected report at no charge (this happens occasionally — sometimes a client knows their stack better than we have inferred from the data), or we disagree and explain why with reference to the evidence in the appendix. The dispute process exists to make the report better, not to defend our position. The reports are technical documents and they earn their value by being correct.
Frequently yes. Deliverability consultants generally focus on strategy and engagement; an audit is a structured technical baseline that complements ongoing strategy work. We have run several audits where the existing consultant requested the engagement, used the audit as the input to their strategy work, and remained the client's primary advisor afterward. The audit is the snapshot; the consultant is the relationship.
Partially. Auditors and assessors increasingly ask about email authentication posture as part of communications-security controls. The Enterprise tier compliance evidence pack documents your authentication state in a form suitable for inclusion in your control evidence library. It is not a substitute for the broader compliance work (that is the job of your compliance partner), but it removes one specific evidence-gathering task from the assessor checklist.
Reports are written in English by default. We can produce Spanish and Brazilian Portuguese versions on request (Pro and Enterprise tiers only) with a 3 to 5 business day translation turnaround after the English version is final. Translations are done by deliverability-domain translators we have worked with for years, not generic agencies.
You can book a tier directly and we kick off within 48 hours. Or you can talk to the lead auditor first — a 20-minute call where we ask about your stack and tell you which tier is the right fit, with no obligation to proceed.
