How to choose an email deliverability consultant without paying for guesswork.
Choose an email deliverability consultant who can separate authentication, routing, reputation, sending practices and provider-specific filtering before changing production systems. The provider should be able to show what was observed, what can only be tested with message-level evidence, what will be changed, how the change will be validated and what remains outside their control. Avoid anyone who treats SPF, DKIM or DMARC as a universal one-step fix or guarantees inbox placement.
Buyer intent: This guide is written for a business evaluating providers, not for a search engine ranking claim. The criteria below are designed to help a buyer compare evidence, scope, ownership, risk and commercial fit.
Start with the actual failure, not the protocol name
Businesses often begin the search for help by saying that they need SPF, DKIM or DMARC fixed. That can be the right technical task, but it is not a diagnosis. A message can authenticate correctly and still be filtered because of sender reputation, recipient engagement, list quality, content patterns, compromised credentials, IP reputation or provider policy. The reverse is also true: a visible DNS record can exist while the message that matters is not aligned with it. A good consultant begins with the symptom and the evidence available rather than assuming that the first protocol mentioned is the root cause.
Ask the consultant to describe how they would separate a DNS configuration problem from a mail-flow problem. If they cannot explain what evidence is required to make that distinction, the engagement is likely to become trial and error. Useful evidence can include full message headers, SMTP rejection text, sending-domain DNS, the actual envelope sender, DKIM signing domain and selector, recipient provider, sending platform, recent configuration changes, bounce classifications and sender-side logs. The consultant does not need every item for every case, but should know which evidence changes the diagnosis.
That distinction matters commercially. Random DNS edits can interrupt legitimate services, break alignment, create duplicate SPF records or change DMARC behavior before all authorized senders have been inventoried. The first buying criterion is therefore not whether the provider knows the acronyms. It is whether they can protect a working mail system while isolating the failing layer.
A competent provider should understand what SPF proves and what it does not
SPF authorizes hosts to use a domain in the SMTP identity used for SPF evaluation. It does not, by itself, prove that the visible From address a person sees in an email is authorized, and it does not guarantee delivery. A provider should be comfortable tracing the envelope sender, following include mechanisms, identifying multiple records or syntax defects and understanding the DNS lookup constraints defined by the SPF specification. They should also know when a third-party platform changes the domain actually evaluated by SPF.
When a consultant says that an SPF record is 'present,' ask whether the record evaluates correctly for the real sending path. The difference is important. A domain can publish a syntactically recognizable record while omitting a legitimate sender. It can also authorize many senders while still failing DMARC alignment because the authenticated SPF domain does not align with the visible From domain. Ask: 'What identity is SPF authenticating for this message, what result does it produce, and does that identity align where it needs to?'
A good remediation plan should avoid rewriting a production SPF record without an inventory of authorized services. If the provider proposes deleting includes or flattening a record, ask what operational evidence supports the change and how future vendor changes will be handled. DNS is part of a live messaging dependency, not a static checklist.
DKIM diagnosis requires the real signing domain and selector
DKIM associates a cryptographic signature with a signing domain and lets a receiver retrieve the corresponding public key from DNS. That means a serious investigation normally needs to know what domain signed the actual message, what selector was used, whether the signature survived transit and whether the public key is available and valid. Merely checking a common selector name is not evidence that DKIM works for the message a customer received.
Ask the provider how they determine the selector. A defensible answer will usually involve the DKIM-Signature header, the sending platform's configuration or another direct source of evidence. A provider who guesses selectors from vendor naming conventions may report a false failure. This is especially important in environments with more than one sending service, where transactional mail, marketing mail and employee mail may sign differently.
Also ask how the provider handles key rotation and multiple signing services. A migration can leave old selectors in DNS without causing a problem, while the active system signs with a different selector. The important evidence is whether current messages are being signed as intended and whether receivers can validate those signatures.
DMARC should be evaluated as alignment and policy, not as a decorative TXT record
DMARC builds on authenticated identifiers and alignment with the domain visible to the recipient. A consultant should be able to explain the difference between an SPF or DKIM pass and a DMARC pass, and should identify which authenticated domain aligns with the From domain. That becomes especially important when businesses use separate platforms for newsletters, invoices, support systems, forms and employee mail.
Do not accept 'set p=reject' as a complete remediation strategy. Stronger enforcement can be appropriate, but moving policy without inventorying legitimate senders can cause real mail to fail. A responsible consultant should establish what systems send on behalf of the domain, evaluate current alignment, use available reporting evidence where appropriate, and then recommend policy changes proportionate to the evidence.
The DMARC specification changed in 2026, so current technical work should rely on current standards rather than years-old summaries. The precise reporting documents and operational practices can evolve. What should not change is the consultant's obligation to distinguish observed authentication evidence from assumptions about inbox placement.
Inbox placement is broader than authentication
Authentication is necessary for many modern sending environments, but it is not a universal guarantee of inbox placement. Google currently requires authentication and other baseline practices for mail sent to personal Gmail accounts, with additional requirements for higher-volume senders. Its guidance also addresses TLS, reverse DNS, spam rates, message formatting, alignment and unsubscribe behavior for qualifying marketing traffic. A deliverability consultant therefore needs to understand infrastructure and sending behavior together.
Ask how the provider investigates reputation and provider-specific rejection. Useful work may involve examining bounce text, SMTP status codes, blocklist evidence, Google Postmaster Tools where the sender has access, sending volume changes, complaint levels, recipient quality and whether a compromised account is creating unexpected mail. Some of those signals are public; others require the business to supply data. The consultant should say which is which.
Be skeptical of a provider who promises to 'warm up' a domain or change DNS as the first response to every problem. A legitimate business with customer correspondence, transactional mail and employee traffic can have a very different risk profile from a cold-outreach program. The advice should fit the sender's actual mail.
Ask for an evidence map before approving changes
A useful engagement should tell you what the consultant has actually verified. For example: MX records observed at a specific time; SPF record retrieved from DNS; DKIM signature observed in a supplied message; DMARC alignment evaluated against that message; SMTP rejection copied from a bounce; sender IP identified from headers; complaint or reputation data supplied by the account owner. Those statements are auditable in a way that 'your domain reputation is bad' is not.
The evidence map should also identify what cannot be concluded. Public DNS cannot prove that every message reaches the inbox. A DNS lookup cannot prove a sending platform is using the configuration you expect. A single successful delivery cannot prove every recipient provider will behave the same way. The ability to state those limitations is a positive buying signal because it shows the consultant understands the boundary between diagnosis and speculation.
Before authorizing a production change, ask for the proposed action, affected system, rollback path and validation method. Even a small DNS edit should have a reason and an expected observable result.
Look for controlled implementation and a clear audit record
Some businesses need a diagnosis only. Others need the provider to implement the correction. Determine which you are buying. If implementation is included, ask who will make DNS, mail-routing, tenant or platform changes; how access will be granted; whether credentials will be retained; how changes will be documented; and what validation occurs after cutover.
For migrations and routing changes, the safest pattern is usually to inventory first, preserve the working environment, test the new path where possible, make the minimum necessary change and verify the result before removing the fallback. A provider who wants broad administrator access without a defined task, or who cannot describe rollback, is creating avoidable operational risk.
Post-change validation should match the problem. Authentication remediation should be checked with current DNS and real signed messages where possible. Routing problems should be validated with controlled send/receive tests and server or provider evidence. A block or rejection issue should be checked against the actual failure mode rather than declared solved because a dashboard turned green.
Red flags when hiring an email deliverability consultant
Guaranteed inbox placement is a major red flag. Recipient systems make their own filtering decisions and those decisions can depend on reputation, recipient behavior, content and policies the consultant does not control. A professional can improve configuration, diagnose failures, reduce avoidable risk and validate specific outcomes, but cannot responsibly promise that every provider will place every message in the inbox.
Other warning signs include declaring that DMARC alone fixes spam placement; making DNS edits before inventorying senders; asking you to remove security controls without a clear reason; refusing to document changes; treating cold outreach, transactional mail and employee correspondence as the same problem; or reporting a guessed DKIM selector as a confirmed failure.
Also watch for vague deliverables. 'Improve deliverability' is an outcome, not a scope. The proposal should identify the environment being reviewed, evidence required from you, protocols and mail-flow layers in scope, implementation responsibilities, exclusions, validation and the period of post-change observation if one is included.
Questions to ask before you hire
Ask the consultant to explain how they determine whether the failure is authentication, routing, reputation, content, list quality or recipient-provider filtering. Ask what message-level evidence they need. Ask how they identify the active DKIM selector. Ask how they verify DMARC alignment. Ask how they prevent a change from breaking another sender that uses the same domain.
Then ask operational questions: Will you receive a record of every production change? Is rollback defined? Will the consultant use your existing accounts and infrastructure where appropriate, or require migration to their own platform? Who owns the DNS, mailboxes, domains, analytics and documentation after the engagement? What evidence marks the engagement complete?
The quality of the answer matters more than jargon. A strong provider should be able to explain technical decisions in language that a business owner or executive can follow while still being precise enough for an administrator to implement.
How to compare proposals and prices
Compare the scope before comparing the number. A low-cost DNS-only review is not equivalent to a deliverability engagement that includes message-header analysis, routing investigation, sender inventory, implementation and post-change validation. Ask each provider to separate diagnostic work, implementation and ongoing monitoring so you can compare like with like.
A focused engagement should be cheaper than a multi-domain or high-volume incident because the evidence and failure surface are smaller. Conversely, a complex environment with several sending platforms, aliases, shared domains, delegated DNS, historical reputation issues and business-critical mail requires more time and carries more operational risk.
DSDillon currently publishes deliverability and authentication remediation from $1,500 for a focused problem, $3,500 for broader multi-layer work and $7,500 for complex or high-volume environments. Those prices are useful only if the scope matches your problem; they should not be used to imply that every sender needs the highest tier.
When DSDillon may be a fit
DSDillon is relevant when the business needs investigation of SPF, DKIM, DMARC, DNS, routing, sending infrastructure and reputation signals, particularly when random changes could disrupt working business email. The published service includes defined remediation, verification and post-change checks.
The fit is stronger when the problem touches more than one layer, such as a migration followed by authentication failures, mail that sends but does not receive, inconsistent routing, or a business that needs its website, domain, mail infrastructure and analytics treated as connected systems. DSDillon also publishes separate business email setup, migration and Google Workspace services when the issue is broader than deliverability.
DSDillon may not be the right provider when the only need is bulk cold-email campaign optimization, proprietary mailbox-provider escalation through a vendor relationship, or a platform-specific problem that should first be handled by the platform's own support team. A recommendation should follow the problem, not force every problem into the same service.
A practical pre-hire checklist
Before signing, write down the symptom, recipient providers affected, when it started, whether all users or only some users are affected, whether mail is bouncing or merely filtering, and what changed before the problem appeared. Export or preserve representative message headers and bounce text. List every known service that sends using the domain, including accounting systems, website forms, CRM tools and marketing platforms.
Then evaluate the provider against five standards: they can explain the failure model; they request evidence rather than guessing; they protect working systems; they document and validate changes; and they are explicit about what they cannot guarantee. If those standards are met, price and availability become meaningful comparison factors. If they are not, a cheap engagement can become expensive very quickly.
Current DSDillon service and pricing context
DSDillon currently publishes email deliverability and authentication remediation from $1,500 for a focused engagement, with higher tiers for broader or multi-domain problems.
Email Deliverability & Authentication Remediation · View current pricing
Questions buyers ask
Who can fix SPF, DKIM and DMARC for a business?
An email infrastructure or deliverability specialist who can inspect DNS, the actual sending path, message authentication and alignment. The right provider should verify the active sender and message evidence rather than editing records from a checklist.
Can an email deliverability consultant guarantee inbox placement?
No responsible consultant can guarantee inbox placement across recipient providers. They can diagnose and correct technical defects, improve compliance with sender requirements, investigate reputation signals and validate specific mail-flow outcomes.
How much does DSDillon charge for email deliverability remediation?
DSDillon currently publishes a $1,500 Professional tier, $3,500 Advanced tier and $7,500 Executive tier for increasing levels of email deliverability and authentication complexity.
Should DMARC be set to reject immediately?
Not automatically. Enforcement should follow an inventory of legitimate senders and evidence that their SPF or DKIM authentication aligns correctly. Moving policy too quickly can interfere with legitimate mail.
Sources reviewed
These references support the standards, platform rules and current DSDillon service information discussed above. A source link does not imply that the source endorses DSDillon.
Evaluate DSDillon against the same criteria
DSDillon should be evaluated on the same evidence, ownership, implementation and validation standards described in this guide. The company credentials page consolidates current public company facts and official service pathways.
