# Cold email deliverability agency for outbound teams

GrowthPal is a B2B outbound and GTM engineering agency operated by Inferno Media, LLC, working from Kathmandu, Nepal.

Last reviewed 29 October 2026

A cold email deliverability agency finds out why outbound mail stops reaching the inbox and fixes the cause rather than the symptom. The work starts from what you can observe, such as spam placement at one provider but not another, a bounce spike or a reputation drop, names the probable cause, and names the record lookup or report that proves it before anything is changed.

## When a cold email deliverability agency is the right call

### Who this is for

- **Placement changed and nothing on your side did.** Same list, same copy, same volume, and mail that used to land now does not. That pattern points at the sending side and is diagnosable.
- **One provider, not all of them.** Spam at Gmail but the inbox at Outlook, or the reverse, is the most informative symptom there is. The two have different causes, different dashboards and different fixes.
- **You send enough to be measured.** Google and Microsoft both publish requirements that apply above 5,000 messages a day to their users. Above that line you are being scored, and the score is readable.
- **You want the diagnosis written down.** A report that names the symptom, the cause and the evidence, so your team can check the reasoning rather than take the conclusion on trust.

### Who this is not for

- **Replies are low but every signal is clean.** Reputation good, spam rate under the thresholds, authentication aligned, no blocklist hits. That is a targeting or offer problem presenting as a sending problem, and we will say so instead of selling a fix.
- **You want the checklist.** If nothing is broken yet and you want the pre-send steps in order, the deliverability checklist on this site is free and is the better page.
- **You want a warm-up tool.** Warm-up is one phase of a remediation plan, not the service. The planner on this site handles the scheduling.
- **The domain is already burned and you need it back today.** No mailbox provider publishes a recovery time, so no honest provider can promise one. If the timeline is fixed and short, moving to new infrastructure is usually the faster answer and we will tell you that up front.

## What a deliverability audit covers

| Component | What is done | What the client receives | Who owns it |
|---|---|---|---|
| Symptom intake | Record what is actually observed, per provider, with dates, rather than starting from a list of best practices. The symptom determines which half of the diagnostic runs. | A written statement of the failure, per recipient provider, with the date it started. | Client |
| Authentication review | Read the SPF record and count its DNS-resolving mechanisms against the limit in RFC 7208, query the DKIM selector in DNS and confirm the key resolves, then check that the visible From domain aligns with the SPF or DKIM domain. | A record by record report of what is published and what is failing. | Client |
| Receiver-side evidence | Read Google Postmaster Tools for domain reputation, spam rate, authentication pass rate and delivery errors, and Microsoft SNDS for per IP complaint rate, trap hits and filter result. | Dated screenshots and the series that moved first. | Client |
| Aggregate report analysis | Parse the DMARC aggregate reports, which are the only source showing what receivers actually saw rather than what the DNS records look like. | A per source breakdown of pass, fail and alignment. | Client |
| Bounce and response code forensics | Pull raw SMTP response codes from the sequencer rather than the platform's bounce label, because most platforms collapse a block and a bounce into the same category. | Bounces separated into data problems and blocks, segmented by when the records were sourced. | Client |
| Blocklist and URL checks | Check the sending IP, the sending domain and every link and tracking domain in the body, since a clean sending domain can still be blocked on a listed link. | A list of any listings found, with the cause identified before any delisting request is filed. | Client |
| Remediation plan | An ordered plan with an owner and a duration against each item, separating what must change now from what has to wait for reputation to recover. | The plan, and the infrastructure changes implemented if you want us to run them. | Client |
| Re-measurement | The same dashboards read again on the same date ranges after the changes, so the effect is measured rather than assumed. | A before and after on the same charts. | Client |

## How the audit runs

1. **Write down the symptom** Record which provider, since when, on which domains and at what volume. Most engagements start with a general sense that things got worse, and the first job is to turn that into a specific, dated, per provider statement. What you provide: Access to the sequencer's send and bounce data, and the dates you first noticed the change.
2. **Read the published records** SPF, DKIM and DMARC for every sending domain in use, checked against the specifications rather than against a scoring tool's letter grade. SPF authorizes the envelope sender, not the visible From address, which is the distinction that makes alignment matter. What you provide: DNS read access, or a list of the sending domains so we can query them publicly.
3. **Read what the receivers report** Google Postmaster Tools and Microsoft SNDS are the two sources that report what Gmail and Outlook actually did, and they report different things. The DMARC aggregate reports are the third, and the only one that is receiver independent. What you provide: Postmaster Tools access for the sending domains, SNDS registration for the sending IPs, and the mailbox the aggregate reports are sent to.
4. **Separate the bounces** A cluster of 550 5.1.1 responses across many recipient domains is a data problem. The same count against one recipient domain returning 550 5.7.x is a block. These need opposite responses and are routinely confused. What you provide: Raw log export from the sending platform, not the summary view.
5. **Find what moved first** Reputation is a lagging signal, so the cause predates the drop by days or weeks. Overlaying reputation, spam rate, delivery errors and authentication on one date range shows which series moved first, and the send log then shows what entered the stream that day. What you provide: A send log covering the period, with segment or campaign names attached.
6. **Report before changing anything** The report names the cause and the evidence for it. Changing infrastructure before the cause is identified destroys the baseline and is the single most common way a deliverability problem gets worse. What you provide: A review call to agree the diagnosis before remediation starts.
7. **Remediate in order** Authentication and list problems first, because they are under your control and have immediate effect. Reputation recovery last, because it is a function of time and consistent behavior rather than of a setting. What you provide: A decision on who implements, your team or ours.
8. **Re-measure on the same charts** The same dashboards, the same date windows, after the changes. If a number did not move, that is reported too. What you provide: Continued access for the measurement window.

## Symptom, likely cause, and the check that proves it

The diagnostic below is the table the rest of the market does not publish. Every page competing to be your cold email deliverability agency asserts that it will find the problem; none shows how. Read down the left column to the symptom you have, and the right column names the lookup or report that confirms the cause. This is the first part of the engagement, and there is no reason it should be private.

| What you observe | Likely cause | The check that confirms it |
|---|---|---|
| Spam at Gmail, inbox at Outlook and Microsoft 365 | A domain reputation or engagement problem at Google specifically. Google weights the sending domain and recipient engagement heavily, and its published requirement is a spam rate below 0.3 percent in Postmaster Tools. | Open Google Postmaster Tools for the sending domain and read Domain Reputation and Spam Rate side by side over 30 days. A low or bad domain reputation with a spam rate above 0.3 percent confirms it. Read IP Reputation on the same dashboard to rule the IP in or out. |
| Spam or junk at Outlook.com and Hotmail, inbox at Gmail | A Microsoft-side authentication or IP reputation failure. Since 5 May 2025 Microsoft enforces SPF, DKIM and DMARC for domains sending over 5,000 emails a day to Outlook.com, and routes non-compliant mail to junk. | Register the sending IP in Microsoft SNDS and read the Data tab for complaint rate, trap hits and filter result per IP. Separately confirm the visible From domain aligns with the SPF or DKIM domain. Enroll in Microsoft JMRP for the complaint feed SNDS summarizes. |
| A sudden bounce spike on a campaign that was stable | Either a bad data batch entered the list, or a provider started rejecting rather than accepting. These require opposite responses. | Pull raw SMTP response codes from the sequencer, not the platform's bounce label. A 550 5.1.1 class clustered across many recipient domains means stale or invalid data. One recipient domain returning 550 5.7.x means a block. Microsoft's authentication rejection returns 550 5.7.515. Then segment the bounces by the date the records were sourced. |
| Spam complaint rate climbing toward the threshold | A list and targeting mismatch, or a missing or broken unsubscribe path. | Read Spam Rate in Google Postmaster Tools against the 0.3 percent requirement and the separate 0.10 percent guidance. Read complaint rate per IP in Microsoft SNDS. Enroll in Yahoo's Complaint Feedback Loop. Then confirm the List-Unsubscribe and List-Unsubscribe-Post headers are present and that the HTTPS POST endpoint actually processes an opt out, as RFC 8058 requires. |
| Domain reputation falls with no change in volume | Engagement decay, a newly acquired bad segment, or complaints crossing a threshold. Reputation lags, so the cause predates the drop. | Overlay Domain Reputation with Spam Rate, Delivery Errors and authentication pass rates on one date range and identify which series moved first. Reconcile that date against the send log to find which segment entered the stream. Change nothing until that is identified. |
| Authentication failures, or recipients see unauthenticated warnings | An SPF record over its lookup limit, a broken or rotated DKIM selector, or alignment failing because the From domain does not align with the SPF or DKIM domain. | Count the DNS-resolving mechanisms in the SPF record against the limit set in RFC 7208. Query the DKIM selector TXT record directly and confirm the public key resolves, per RFC 6376. Then read the DMARC aggregate reports, which show SPF and DKIM results and alignment per source IP as receivers evaluated them. |
| Rejections or deferrals from several unrelated recipient domains at once | A blocklist listing on the sending IP, the sending domain, or a URL inside the message body. | Run a multi-list lookup against both the IP and the domain, since they are listed separately. Query Spamhaus directly rather than relying on an aggregator. Check URI blocklists for every link and tracking domain in the body. Identify and remove the cause before filing any delisting request. |
| Opens look normal, replies are near zero, every signal is clean | This is usually not a deliverability problem at all. It is targeting, offer or timing presenting as a sending problem. | Confirm the negative first: reputation high or medium, spam rate under the thresholds, aggregate reports showing alignment passing, bounce rate stable, no listings. Then run a seed-list placement test, because open tracking is unreliable where image proxying is in use. If placement is good, classify the replies. A high share of wrong person or not relevant points at the list and the definition of the buyer, not the infrastructure. |

### What each tool actually reports, and what it cannot tell you

| Tool or lookup | What it reports | The limitation we state up front |
|---|---|---|
| Google Postmaster Tools | Domain reputation, IP reputation, spam rate, authentication pass rates and delivery errors, for Gmail recipients | Gmail only, requires DNS verification, and the data is sparse below a daily volume Google does not publish |
| Microsoft SNDS | Per IP complaint rate, trap hits, filter result and sample data for Outlook.com and Hotmail | IP based, so of limited use on shared infrastructure, and it needs IP ownership verification |
| DMARC aggregate reports | Per source SPF and DKIM results and alignment, as the receiver evaluated them | XML, useless without a parser, and daily rather than real time |
| SPF record lookup | What authorization is published and whether the record exceeds its DNS lookup limit | Shows the record, not whether a given send passed. Pair it with aggregate reports |
| DKIM selector query | Whether the public key for a given selector resolves | Selector specific. A platform-managed selector can break without the DNS record changing |
| Multi-list blocklist lookup | Whether an IP, domain or URL is listed, and where | Lists differ in weight and in who consults them. A listing is not automatically the cause |
| Seed-list placement test | Where one message landed across a panel of seed accounts | A panel is not your audience. It measures filtering, not engagement |
| Raw SMTP response codes | What the receiving server actually said | Many sequencers collapse blocks and bounces into one label, which is the failure this check exists to catch |

### What the mailbox providers and the specifications actually say

Almost every page competing for this term names SPF, DKIM and DMARC, and almost none cites the document that defines them or the provider that enforces them. The rules below are quoted from the publishers themselves and dated at the foot of this page.

- **Google.** Senders of more than 5,000 messages a day to Gmail accounts must set up SPF, DKIM and DMARC for the sending domain and must support one click unsubscribe on marketing mail. The requirement is a spam rate below 0.3 percent in Postmaster Tools. Separately, and more strictly, Google advises staying below 0.10 percent and never reaching 0.30 percent. Those are two different sentences and should not be merged into one number. Enforcement began on 1 February 2024.
- **Yahoo.** All senders need SPF or DKIM at a minimum and a spam rate below 0.3 percent, which Yahoo calculates on mail delivered to the inbox. Bulk senders need both SPF and DKIM plus a published DMARC policy of at least p=none that passes, with the From domain aligning to the SPF or DKIM domain. Unsubscribe requests are to be honored within 2 days.
- **Microsoft.** From 5 May 2025, Outlook.com enforces SPF, DKIM and DMARC for domains sending over 5,000 emails a day, and routes non-compliant messages to junk. Microsoft's page says it will later reject such messages until the records are corrected but gives no date for that, so nobody can honestly tell you one.
- **SPF, RFC 7208.** SPF authorizes the envelope sender and the HELO domain, not the visible From address a recipient reads. That gap is exactly why alignment exists, and it is the point most pages on this subject skip.
- **DKIM, RFC 6376.** A cryptographic signature bound to a domain, with the public key published in that domain's DNS. Because relays usually leave content unchanged, the signature generally survives transit, which is what makes it the more durable of the two.
- **DMARC.** RFC 7489 was the Informational specification from 2015. It has now been obsoleted by RFC 9989, RFC 9990 and RFC 9991, and DMARC has moved onto the IETF standards track. Any guidance still describing RFC 7489 as current is out of date, including some that is widely linked.
- **One click unsubscribe, RFC 8058.** Both Google and Yahoo point at this specification. It requires a List-Unsubscribe-Post header, an HTTPS POST to the unsubscribe address, a DKIM signature covering the headers, and forbids the sender redirecting the POST. A header that is present but does not process the opt out fails the requirement.

### Three numbers we will not give you

- A recovery time. No mailbox provider publishes one. The four to twelve week figures in circulation come from vendors estimating their own results. What can be described is the observable signal that recovery is happening, and that is what the re-measurement step reads.
- An inbox placement benchmark. Every percentage found was published by a vendor about its own customers, on a seed panel rather than a real audience.
- A bounce rate you should expect. It depends entirely on where your records came from and when, which is why the bounce forensics step segments them by source date rather than comparing them to an average.

## What to ask a deliverability provider before you hire them

The commercial incentive across this market is to classify every outbound failure as a deliverability failure, because that is the product. These are the questions that separate a cold email deliverability agency doing diagnosis from one doing sales.

| What to check | The question to ask | What a good answer looks like |
|---|---|---|
| Diagnosis before change | What will you change in the first week? | Nothing, until the cause is identified and the evidence shown. Anyone changing infrastructure before reading the baseline has destroyed the only comparison that was available. |
| Receiver-side access | What access do you need, and what do you do if we cannot give it? | Named sources: Postmaster Tools, SNDS, the aggregate report mailbox and raw send logs. A provider who does not ask for these is working from the DNS records alone and can only see half the picture. |
| Recovery promises | How long until we are back in the inbox? | A refusal to give a date, because no provider publishes one, followed by the signal they will watch. A confident number here is a sales answer. |
| The Microsoft half | What would you do differently if the problem is at Outlook rather than Gmail? | A different dashboard, a different enrolllment and a different cause set. If the answer is the same for both, they only know the Google half. |
| Honesty about scope | What would make you tell us this is not a deliverability problem? | A clean set of signals with poor replies. A provider with no answer to this question has never declined this work. |
| What you keep | At the end, who holds the domains, the records and the report? | You do, and the report is written so your own team can check the reasoning rather than take the conclusion on trust. |

## What we can show you, and what we will not claim

- 4M+ cold emails sent for 40+ B2B companies, across Prabesh Khanal's five years of outbound work, including campaigns led before GrowthPal was founded in 2025. What it counts: Emails sent, cumulative across every engagement in the founder's career. Not one campaign, not an average, and not confined to GrowthPal.. Source: https://growthpal.io/llm-info/
- The interested-reply definition and counting rules. What it counts: Not a figure. A link to the published methodology.. Source: https://growthpal.io/glossary/#methodology

### What stands behind the diagnosis

- **No deliverability-specific outcome is published yet.** GrowthPal has not published a before and after from a standalone deliverability engagement, so there is no case study to point you at for this service in particular. The figures above cover outbound work as a whole and are defined on the glossary page.
- **Every rule on this page is cited to its publisher.** Google, Yahoo, Microsoft and the IETF specifications, each listed at the foot of the page with the date it was checked. Where a publisher gives no date, this page says so rather than inventing one.
- **The diagnostic is the method, in public.** The table above is the first stage of the engagement written out in full. You can run several of those checks yourself before speaking to anyone, and if they come back clean you have saved the cost of the audit.
- **We decline work that is not ours.** A clean signal set with weak replies is a targeting problem. Saying so loses a sale and is the reason the scope boundary is written on the page rather than discovered in the kickoff call.

## Questions about cold email deliverability work

### How do I know whether this is a deliverability problem or a targeting problem?

Confirm the negative first. If domain reputation is high or medium, the spam rate is under the published thresholds, DMARC aggregate reports show alignment passing, bounces are stable and nothing is listed on a blocklist, then the mail is arriving and the problem is what it says, who it goes to or when. A seed-list placement test separates real placement from reported opens, because open tracking is unreliable where image proxying is in use.

### What does the audit need access to?

Google Postmaster Tools for each sending domain, Microsoft SNDS registration for the sending IPs, the mailbox receiving your DMARC aggregate reports, DNS read access or the list of sending domains, and a raw log export from the sequencer rather than the summary view. Without the receiver-side sources an audit can only read what your records say, not what receivers did with them.

### How long does recovery take?

Nobody can tell you honestly, because no mailbox provider publishes a recovery time. The figures circulating come from vendors estimating their own outcomes. Authentication and list fixes take effect immediately. Reputation is a function of time and consistent sending behavior, so the measurable thing is the direction of the reputation and spam rate charts, read on the same date windows as the baseline.

### Is Microsoft really different from Google?

Yes, in cause, in tooling and in what each publishes. Google reports domain and IP reputation and a spam rate through Postmaster Tools. Microsoft reports per IP complaint rate, trap hits and filter result through SNDS, which means it is of limited use if you do not own the IP. Since 5 May 2025 Microsoft also enforces SPF, DKIM and DMARC above 5,000 messages a day to Outlook.com and junks what fails.

### Our DMARC record says p=none. Is that a problem?

Not for the published requirements. Google requires a DMARC record for bulk senders and accepts an enforcement policy of none, and Yahoo requires a policy of at least p=none that passes. What matters more than the policy value is whether the visible From domain aligns with the domain that passed SPF or DKIM, and the aggregate reports are the only place that is visible.

### Should we move to new domains instead of fixing these?

Sometimes, and we will say so if that is the answer. If the cause is unidentified, moving just recreates it on clean infrastructure in a few weeks. If the cause is identified, fixed, and the only remaining problem is accumulated reputation on a domain you do not need, new infrastructure is often faster than waiting. That is a judgement made after the diagnosis, not before it.

### Why does the raw SMTP response code matter?

Because most sending platforms collapse two different events into one label. A 550 5.1.1 class response spread across many recipient domains means the addresses are invalid, which is a data problem. The same volume against a single recipient domain returning a 550 5.7.x response means you are being blocked, which is a reputation or authentication problem. The platform label calls both of them a bounce.

### Do you also run the sending, or only the audit?

Either. The audit is a standalone piece of work with a written report, and plenty of clients take the report and have their own team implement it. Where we run outbound end to end, the same diagnostic runs as part of the setup rather than as a separate engagement.

### What is the difference between this and your deliverability checklist?

The checklist is ordered by what to do before you send, and it is free on this site. This page is ordered by what has already gone wrong. A cold email deliverability agency is worth paying only once the checklist has not solved it. They are different documents for different moments, which is why the checklist is linked rather than repeated here.

## Sources

- Email sender guidelines, Google, Gmail Help, no publication date displayed by the publisher. https://support.google.com/a/answer/81126. Accessed 29 October 2026.
- Sender Best Practices, Yahoo, Sender Hub, no publication date displayed by the publisher. https://senders.yahooinc.com/best-practices/. Accessed 29 October 2026.
- Outlook.com Postmaster, high volume sender requirements, Microsoft, enforcement stated as beginning 5 May 2025. https://sendersupport.olc.protection.outlook.com/pm/policies.aspx. Accessed 29 October 2026.
- RFC 7208, Sender Policy Framework version 1, IETF, RFC Editor, April 2014. https://www.rfc-editor.org/info/rfc7208. Accessed 29 October 2026.
- RFC 6376, DomainKeys Identified Mail signatures, IETF, RFC Editor, September 2011. https://www.rfc-editor.org/info/rfc6376. Accessed 29 October 2026.
- RFC 7489, DMARC, now obsoleted, IETF, RFC Editor, March 2015. https://www.rfc-editor.org/info/rfc7489. Accessed 29 October 2026.
- RFC 9989, DMARC, the current standards track specification, IETF, RFC Editor, no publication month displayed, copyright 2026. https://www.rfc-editor.org/info/rfc9989. Accessed 29 October 2026.
- RFC 8058, signaling one-click functionality for list email headers, IETF, RFC Editor, January 2017. https://www.rfc-editor.org/info/rfc8058. Accessed 29 October 2026.
- GrowthPal reporting methodology and counting rules, GrowthPal. https://growthpal.io/glossary/#methodology. Accessed 29 October 2026.

## Related

- [Cold email deliverability checklist](/blog/cold-email-deliverability-checklist/) the pre-send steps in order, free and self-serve.
- [Warm-up planner](/free-tools/warmup-planner/) scheduling for the remediation phase.
- [Inbox calculator](/free-tools/inbox-calculator/) how many inboxes a given volume needs.
- [Cold email agency](/cold-email-agency/) the end to end engagement, where this diagnostic runs as part of setup.
- [Glossary and reporting methodology](/glossary/) what every figure on this site counts.
- [Enterprise outbound](/enterprise-cold-email-agency/) the same authentication questions, asked by a security review.

If outbound mail stopped landing and you do not yet know why, send us the symptom and the sending domains. The first thing you get back is the diagnosis and the evidence for it.

Free GTM plan: https://growthpal.io/free-plan/