Sales & Marketing AutomationThe CRM and Marketing Automation Guru's You Can Trust.
Sales & Marketing Automation
An email platform can report that a campaign was delivered even when many messages landed in spam, were delayed, or never reached the people most likely to respond. That gap is why an email deliverability audit must look beyond a single dashboard. It should connect domain setup, sender identity, list quality, sending behavior, message structure, mailbox-provider feedback, and the business process that controls each change.
The rules for reaching major consumer inboxes are now stricter. Google requires core authentication and infrastructure controls for all senders to personal Gmail accounts, with added SPF, DKIM, DMARC, alignment, and one-click unsubscribe requirements for higher-volume senders. Yahoo has similar requirements for bulk senders, and Microsoft applies SPF, DKIM, and DMARC requirements to domains sending more than 5,000 messages per day to Outlook.com consumer addresses. Review the current guidance from Google, Yahoo Sender Hub, and Microsoft before changing a live sending program.
This guide explains how to run a platform-neutral audit across marketing automation tools, email service providers, CRM systems, and transactional mail. You will learn how to build a complete sender inventory, test SPF, DKIM, and DMARC, review list and suppression rules, study bounce and complaint data, test message and link paths, and create a repair plan that can be measured. For wider planning, review our guide to marketing automation platform migration and our overview of email automation services.
An email deliverability audit is a structured review of the systems and practices that affect whether email is accepted, filtered, delayed, rejected, or placed in the inbox. It is not only a DNS check, a template review, or a list-cleaning task. Each of those areas can affect delivery, but the audit must show how they work together.
Delivery normally means the receiving server accepted the message. Inbox placement describes where the message appeared after acceptance, such as the primary inbox, a category tab, the spam folder, or another filtered area. A high delivered rate can exist beside weak inbox placement. The audit should keep these measures separate so the team does not treat server acceptance as proof that the campaign reached the intended view.
A sudden drop in results may come from several places. A new platform may sign with the wrong DKIM domain. A list import may add old or unverified contacts. A sending spike may change mailbox-provider behavior. A tracking domain may be unverified or have a poor history. An unsubscribe process may fail to update every connected system. The audit should trace the full path from consent through send, receipt, feedback, suppression, and reporting.
A marketing automation health check can uncover authentication gaps, unhealthy lists, broken suppression rules, workflow problems, and reporting issues before they affect more sends.
Start the audit by mapping the full sending environment. Many companies know which marketing platform sends newsletters, but they do not know every system that can send as the company domain. CRM alerts, sales tools, support platforms, billing systems, product notifications, event tools, website forms, and employee mail may all use the same organizational domain or related subdomains.
A complete map prevents one platform from being fixed while another continues to send unauthenticated or unwanted mail. It also shows which systems share reputation, which teams control DNS, and where a suppression request may be lost.
Visible From address, display name, Reply-To, envelope sender, return path, and DKIM signing domain.
The identity shown to the reader does not align with the domains used for authentication.
Sending platforms, IP addresses, DNS records, PTR records, TLS status, tracking domains, and selectors.
An unknown sender, broken record, or shared resource creates inconsistent authentication or reputation.
Signup source, consent text, date added, expected frequency, engagement history, and audience purpose.
Contacts receive mail they did not request, no longer expect, or cannot easily stop.
Headers, HTML, plain-text version, subject, image hosts, redirects, landing pages, and unsubscribe links.
Misleading identity, broken HTML, unsafe links, or long redirect chains reduce trust.
Bounces, blocks, deferrals, complaint reports, provider reputation, inbox tests, and response trends.
The team sees a total delivery rate but misses provider-specific filtering and rejection patterns.
Owners, approvals, access, change history, test plans, incident steps, and suppression responsibilities.
Several teams can change sending behavior without one shared process or clear accountability.
Ask each department which tools can send email using a company domain. Confirm the answer with DNS, SPF includes, DKIM selectors, DMARC aggregate reports, platform billing records, and message headers. Do not assume that a system is inactive because nobody remembers using it. Old tools may still send form notifications, renewal reminders, test campaigns, or automated alerts.
List marketing, transactional, support, product, billing, security, and one-to-one sales email as separate streams. These messages have different audience expectations and business needs. Yahoo recommends separating bulk or marketing mail from transactional and user mail by IP or DKIM domain where practical. Even when a platform controls the IP layer, separate subdomains, identities, and reporting can make each stream easier to protect and troubleshoot.
Capture current authentication results, sending volume, complaint rate, hard and soft bounces, deferrals, top SMTP errors, unsubscribe processing time, and outcomes by mailbox provider. Save message headers from several real sends. Without a baseline, the team may make several changes and still be unable to tell which one improved or harmed performance.
Email authentication helps receiving systems verify which servers may send for a domain and whether a message was signed by an authorized domain. The audit should test both the DNS records and the result shown in real message headers. A record can exist and still fail because the sending platform uses a different domain, an old selector, an unauthorized server, or a broken alignment path.
Sender Policy Framework, or SPF, identifies which systems may send using the envelope-from domain. Confirm that the domain has one valid SPF record, every approved sender is included, retired services are removed, and the record stays within the DNS lookup rules defined by RFC 7208. Too many nested includes can create a permanent error even when each vendor was added with good intent.
SPF does not directly authenticate the visible From address. It authenticates the envelope domain used during mail transfer. DMARC can use SPF only when that authenticated domain aligns with the visible From domain. The audit must therefore inspect the message header instead of checking only whether an SPF TXT record exists.
DomainKeys Identified Mail, or DKIM, adds a cryptographic signature that receiving systems can verify through DNS. Confirm that each sending platform signs mail, the selector exists, the public key is reachable, the signature passes, and the signing domain aligns with the visible From domain when DKIM is used for DMARC. The core standard is documented in RFC 6376.
Google and Yahoo require a DKIM key of at least 1024 bits for the mail covered by their sender rules and recommend 2048 bits when the provider supports it. The audit should also record key age, selector ownership, rotation plans, and whether an email gateway changes the subject, body, links, or footer after the signature is applied.
Domain-based Message Authentication, Reporting, and Conformance, or DMARC, connects the visible From domain to SPF or DKIM. A message passes DMARC when at least one approved authentication method passes and aligns with the visible From domain. Review RFC 7489 for the protocol details.
A policy of p=none can support monitoring, but it does not tell receiving systems to quarantine or reject failing mail. Do not move to a stronger policy before every legitimate sender is known and aligned. Start with reporting, correct unknown or failing sources, test important forwarding and third-party paths, and then increase enforcement through an approved plan.
Send controlled tests from each platform and inspect the full headers at Gmail, Yahoo, Outlook.com, and key business domains. Record the visible From domain, return path, SPF result and domain, DKIM result and signing domain, DMARC result, selector, sending IP, and any provider-specific filtering information.
Authentication-Results: spf=pass smtp.mailfrom=mail.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
The infrastructure review explains how email leaves each platform and how that path appears to receiving systems. It should cover domains, subdomains, IPs, reverse DNS, TLS, tracking, redirects, and the difference between shared and dedicated resources.
Google and Yahoo require valid forward and reverse DNS for sending IPs covered by their guidelines. The PTR record should resolve the sending IP to a hostname, and that hostname should resolve back to the same IP. Teams using a managed email platform may not control this record, but they should confirm the provider is handling it correctly.
A shared IP combines the behavior of several senders, while a dedicated IP gives one organization more direct control and more responsibility. A dedicated IP is not automatically better. It needs enough steady, wanted volume to build and maintain its own reputation. A low-volume or irregular sender may perform better on a well-managed shared pool.
Record which streams use each IP, how volume changes by day, which mailbox providers show delays, and whether the platform moves traffic between pools. Avoid sudden spikes. Google advises senders to increase volume slowly, send at a consistent rate, begin with engaged recipients, and watch SMTP errors and reputation while volume grows.
A custom sending subdomain can make ownership and reporting clearer. A custom tracking domain can keep links tied to the brand instead of a shared vendor hostname. Confirm that every tracking domain has valid DNS, uses HTTPS, resolves without errors, and leads to trusted pages. Review redirects for unnecessary hops, mixed domains, expired certificates, or security warnings.
A migration can change the sending platform, IP pool, return path, DKIM selector, tracking domain, template code, and volume pattern at the same time. Treat the change as a controlled reputation event. Microsoft’s official guidance on warming a sending domain recommends gradual volume growth and beginning with highly engaged recipients. Our marketing automation migration framework explains how to connect technical changes to a wider operating plan.
Receipts, password resets, security alerts, and other required messages should not depend on the same audience practices as promotional campaigns. Separate the streams where possible, keep transactional templates focused on their main purpose, and make sure a marketing complaint or sending spike does not place required product mail at unnecessary risk.
Mailbox providers judge whether people want the messages they receive. A technically perfect domain can still have poor performance when the audience did not request the mail, no longer expects it, or cannot leave easily. The audit should trace each contact from the point of collection through segmentation, sending, feedback, and suppression.
For each source, record the signup form, consent statement, date added, expected content, expected frequency, region, and system of record. Review events, imports, partner lists, sales uploads, lead vendors, old customer files, gated content, checkout forms, and offline collection. Do not treat a business email address as automatic permission for ongoing marketing.
Google advises senders not to buy email addresses or send to people who did not sign up. Yahoo recommends specific opt-in, clear frequency expectations, and confirmed opt-in as a way to reduce uninterested or invalid addresses. The audit should flag sources that cannot show a clear reason the recipient expects the message.
Separate hard bounces, soft bounces, blocks, and deferrals. A hard bounce may show that the address is invalid or cannot receive mail. A soft bounce may be temporary, but repeated failures need a rule. A block may point to authentication, policy, content, reputation, or rate limits. Save the exact SMTP code and provider response instead of grouping every failure into one bounce total.
Confirm that unsubscribes, complaints, hard bounces, legal suppressions, and manual do-not-email requests reach every platform that can send marketing mail. A person who unsubscribes in one system should not be re-added by a nightly sync, import, CRM update, or separate campaign tool. The audit should test the full update path with controlled records.
Engagement can help identify which recipients still value the mail, but open rate should not be treated as a direct inbox-placement measure. Google states that it does not track open rates and cannot verify third-party open-rate accuracy. Privacy tools, image blocking, and automatic image loading can also change reported opens. Use a wider set of signals such as recent signup, clicks, replies, site activity, conversions, purchase activity, account use, and direct preference updates.
Marketing and subscribed messages sent at higher volume to Gmail must support one-click unsubscribe and a visible unsubscribe link. Yahoo requires functioning list-unsubscribe support for bulk promotional mail and says unsubscribe requests should be honored within two days. The technical one-click method is defined in RFC 8058.
Remove duplicates, invalid contacts, old bounces, broken properties, and unsafe audience sources before they create more sending and reporting problems.
A strong audit follows a fixed order so the team can separate evidence from assumptions. Starting with random template changes may hide a DNS, permission, or infrastructure problem. Changing several systems at once makes the result harder to explain.
Platforms, domains, IPs, message types, lists, owners, and current reports.
Is every sending source known and assigned to a business and technical owner?
A verified sender inventory and evidence request list.
DNS records, headers, permissions, suppression rules, and platform settings.
Do identity, authentication, consent, and control paths work as designed?
A pass, fail, or needs-review result for each control.
Controlled sends across message types, providers, domains, and audience groups.
Where do messages fail, delay, filter, or show a different result than expected?
Headers, SMTP responses, placement observations, and repeatable test cases.
Provider trends, reputation data, list history, campaign changes, and test evidence.
Which issue is the likely root cause, and which findings are only related symptoms?
A ranked risk register with owners and dependencies.
Approved changes, rollback steps, test groups, and success measures.
Did the change correct the issue without harming another sending stream?
Before-and-after evidence, updated documentation, and a monitoring plan.
Build test accounts at major consumer providers and include important company domains. Use the same message, sender, and timing when comparing one variable. Seed tests are useful for repeatable checks, but they do not prove placement for an entire live audience. Combine them with real provider data, SMTP responses, complaints, and campaign outcomes.
Do not change the sending domain, IP pool, list rules, template, From address, frequency, and tracking domain in one launch. When possible, isolate the highest-risk variable, test it with a small engaged group, and watch the result before expanding. This makes rollback easier and protects the team from false conclusions.
For every test, save the date, platform, sender, audience, message ID, domain, IP, subject, volume, authentication result, SMTP response, placement observation, and business outcome. A repeatable record helps the team compare changes over time and gives support teams the detail they need when a provider investigation is required.
Content is only one part of deliverability, but message structure can still create problems. The audit should inspect identity, subject lines, HTML, plain text, links, images, footers, headers, and the unsubscribe path. Test actual messages from the live platform because exported HTML does not show every change made during sending.
The display name, From address, Reply-To address, subject, and message body should tell one clear story. Google advises senders not to use misleading display names, fake reply markers, deceptive subjects, or hidden content. Avoid making a campaign look like a reply or urgent personal message when it is not.
Check for broken tags, hidden blocks, unreadable text, excessive code, missing alternative text, very large images, and a weak mobile layout. Confirm that the plain-text version is readable and that the key message does not depend on images alone. The goal is not a fixed text-to-image formula. The goal is a clear, honest, accessible message that renders well and matches the reader’s expectation.
Click each link from a real received message. Confirm that the visible copy matches the destination, the tracking domain is expected, HTTPS works, redirects are limited, and the final landing page is active and safe. A broken or flagged landing page can harm results even when the email platform itself is configured correctly.
Verify the List-Unsubscribe and List-Unsubscribe-Post headers on promotional mail where required. Then test the visible link in the body. The process should not require a login, should update the right preference or global suppression, and should stop future promotional sends within the required time.
Do not mix major promotions into receipts, security alerts, password resets, or other required messages. Google advises senders not to combine different message types in one email. A clear purpose helps recipients understand why they received the message and helps teams keep required mail separate from promotional risk.
A deliverability dashboard should show where problems happen and what changed before the decline. A single total delivery rate can hide a major issue at one mailbox provider, one domain, one message stream, or one audience source. Review measures by provider, domain, subdomain, campaign type, audience source, and time period.
CHECK 01
SPF, DKIM, DMARC, domain alignment, selector errors, and unauthorized sources.
Results differ by platform, provider, domain, or message type.
Confirm sender identity and find broken or unknown sending paths.
CHECK 02
Hard bounces, soft bounces, temporary delays, blocks, and top SMTP codes.
One provider, IP, domain, or list source moves away from its normal pattern.
Separate invalid addresses, rate limits, policy blocks, and infrastructure problems.
CHECK 03
Spam complaints, unsubscribe rate, processing time, and repeat sends after suppression.
Complaint rate rises after a source, frequency, content, or audience change.
Measure audience expectation and find broken preference or suppression rules.
CHECK 04
Domain and IP reputation, spam-rate trends, complaint feedback, and provider alerts.
Reputation changes after a volume spike, platform move, list import, or new message stream.
See how mailbox providers view the sender over time.
CHECK 05
Inbox, category, spam, delays, and authentication results across controlled accounts.
The same message behaves differently by provider or sending path.
Create repeatable tests and support a wider diagnosis.
CHECK 06
Clicks, replies, conversions, revenue, account activity, and results by audience source.
Technical delivery looks stable but useful customer action continues to fall.
Separate inbox problems from weak targeting, timing, offer, or message value.
Use Google Postmaster Tools for available Gmail reputation, spam-rate, authentication, and delivery data. Use Yahoo Sender Hub and its Complaint Feedback Loop for Yahoo-managed domains. Review Outlook.com sender support and SMTP responses for Microsoft consumer mail. Provider data may have minimum-volume limits and should be read beside platform reports.
Google’s current guidance says to keep the spam rate shown in Postmaster Tools below 0.10% and avoid reaching 0.30% or higher. Yahoo requires bulk senders to remain below 0.3%. Treat these values as maximum risk limits, not performance goals. A lower, stable complaint rate gives the sender more room when a campaign has an unusual spike.
Track the exact code, response text, recipient domain, campaign, IP, and time. Grouping every temporary response as a soft bounce removes useful detail. A 4xx response may show rate limiting or a temporary policy problem, while a 5xx response may show a permanent rejection. Always read the provider’s message before deciding whether to retry, pause, slow volume, or correct configuration.
A campaign can reach the inbox and still fail because the audience, offer, timing, or message is weak. It can also show strong clicks among a small delivered group while a large share of the intended audience was filtered. Report technical delivery, audience response, and business outcomes as separate layers so each team works on the correct problem.
The repair plan should reduce immediate risk first, correct system design second, and build ongoing control third. The exact timing depends on access, DNS ownership, platform limits, sending volume, and the severity of the issue. Do not promise an instant reputation reset. Mailbox providers need time and consistent wanted behavior to observe a change.
Deliverability is not a one-time technical project. Domains, vendors, lists, laws, provider rules, audience behavior, and company goals change. A stable program needs a business owner, a technical owner, a regular review, and a clear process for approving changes.
The business owner approves audience purpose, consent, content, frequency, and risk. The technical owner maintains DNS, platform settings, integrations, headers, tracking domains, suppression flows, testing, and provider monitoring. Both owners should approve major changes to sending domains, platforms, volume, or audience sources.
Set alerts for authentication failures, complaint spikes, hard-bounce increases, provider blocks, unusual deferrals, suppression-sync failures, and unexpected volume. An alert should name the affected stream, show the baseline, identify the owner, and link to the evidence needed for review.
Any new CRM, sales tool, support platform, event system, or automation service that sends as the company domain should pass a sender review. Confirm the From address, envelope domain, DKIM signing, SPF needs, DMARC alignment, tracking links, unsubscribe behavior, suppression sync, data source, and owner before the first live send.
Record the date, request, reason, owner, approval, platform, domain, audience, expected effect, test plan, rollback plan, and final result. This log becomes critical when performance changes weeks after a migration, new campaign, list import, domain update, or vendor change.
Teams that need help maintaining workflows, data, reporting, and governance can also review our guide to marketing automation managed services. For nurture strategy after list and sending controls are stable, see our B2B lead nurture campaign guide.
Find the gaps across authentication, data, automation, suppression, sending behavior, and reporting before they affect more campaigns.
An email deliverability audit is a structured review of the systems and practices that affect whether email is accepted, filtered, delayed, rejected, or placed in the inbox. It normally covers sending domains, authentication, infrastructure, list sources, permission, suppression, bounces, complaints, message structure, links, provider feedback, reporting, and governance.
Delivery means the receiving mail server accepted the message. Inbox placement describes where the accepted message appeared, such as the primary inbox, a category tab, or spam. A campaign can have a high delivered rate and still have weak inbox placement.
No. Authentication helps receiving systems verify sender identity and is required by major providers for many sending programs. Inbox placement also depends on permission, complaints, list quality, sending volume, reputation, content, links, infrastructure, and recipient behavior.
Confirm that the domain has one valid SPF record, every approved sender is included, retired services are removed, the record stays within SPF lookup limits, and real messages pass SPF. Also check whether the authenticated envelope domain aligns with the visible From domain when SPF is used for DMARC.
Confirm that each platform signs mail, the selector and public key exist, the signature passes, the signing domain is correct, and the key length meets current provider requirements. Review key rotation, selector ownership, and any gateway or platform step that changes the message after signing.
Not usually. First inventory every legitimate sender, review DMARC reports, correct authentication and alignment problems, and test important third-party and forwarding paths. Move from monitoring to stronger enforcement through a controlled plan so valid mail is not rejected by mistake.
Run a full audit after a platform migration, domain change, major volume increase, unexplained decline, security event, or large list change. A stable program should also review core controls on a regular schedule and monitor provider feedback, authentication, complaints, bounces, and suppression continuously.
Open rate is useful as one campaign signal, but it is not direct proof of inbox placement. Privacy tools, image blocking, and automatic image loading can change reported opens. Use open data beside provider reputation, complaints, SMTP responses, placement tests, clicks, replies, conversions, and audience activity.
Major providers publish maximum risk limits, not ideal targets. Google advises keeping Postmaster Tools spam rate below 0.10% and avoiding 0.30% or higher. Yahoo requires bulk senders to remain below 0.3%. A sender should aim for a lower, stable rate and investigate any rise quickly.
Simple configuration errors may be corrected quickly, but reputation recovery can take longer because mailbox providers need to observe consistent wanted mail over time. The timeline depends on the cause, list quality, complaint history, volume, provider response, domain history, and how safely the repair plan is rolled out.
A separate subdomain can make message streams, ownership, authentication, reporting, and incident control easier to manage. It does not remove the need for permission and good sending behavior, and it should not be used to hide poor practices. The right structure depends on message type, volume, platform, and business risk.
Outside help may be useful when several platforms send as the same domain, DNS ownership is unclear, authentication results conflict, complaints or blocks are rising, suppression does not sync, a migration is planned, or internal teams cannot identify the root cause. A good review should provide evidence, priorities, owners, and a testable repair plan.