CRM Email Automation Not Sending? 7 Checks

Where a missing CRM email can disappear

A missing automated email is not one failure state. The contact might never enter the workflow. It might enter but fail an eligibility rule. The CRM might build the message but refuse to send it. The email provider might accept the message and later report a bounce, delay, or complaint. A receiving mailbox might deliver it to spam even though the provider recorded delivery.

That sequence matters because each layer has different evidence. A CRM workflow screen cannot prove mailbox delivery, and a mailbox search cannot prove workflow enrollment. Choose one affected contact, record the expected send time, and follow the same identifier across CRM history and provider events. Avoid bulk edits until you know the first state that differs from the expected path.

This guide focuses on emails that do not send or do not show a reliable provider outcome. If the message reaches the provider but mailbox placement is the main problem, use the more focused CRM email deliverability checklist.

1. Prove the contact enrolled

Open the execution or enrollment history for one affected contact. Confirm the exact trigger, the time it occurred, the workflow version, every enrollment filter, and the branch that should lead to the email. A workflow marked active only means it can process eligible records. It does not show that this record qualified.

Inspect the source record as it existed at the trigger time. A lifecycle stage may have changed after the event. A form submission may have created a second contact. A lead owner may have been blank while the routing condition ran. A date-based filter may use the account timezone rather than the contact's local time. Re-enrollment can also be disabled even when the business expects the same person to enter again.

HubSpot's workflow troubleshooting guidance lists enrollment criteria, settings, and action timing among the items to inspect. The platform also exposes automation issues that need review. Other CRMs use different labels, but the diagnostic question is the same: can you show a contact-level record of entering the intended version and reaching the intended branch?

2. Check recipient eligibility and suppression

If the contact reached the email action, inspect every rule that can suppress the send. Common controls include unsubscribe state, subscription category, marketing-contact status, prior hard bounce, quarantine, invalid address, global or campaign exclusion lists, unengaged-contact suppression, frequency caps, and account send windows.

HubSpot documents that automated marketing emails are sent only to eligible contacts and gives examples such as non-marketing contacts or people who unsubscribed from all email. Its workflow error reference also notes that unengaged-contact settings and specific execution windows can prevent or reschedule sends. Do not disable those protections simply to make a test pass. Explain why the contact is eligible, then use a controlled test record with the correct consent and status.

For commercial email, technical eligibility is only one part of the decision. The FTC's CAN-SPAM guide describes requirements for commercial messages, including accurate routing and subject information, a valid postal address, a clear opt-out method, and honoring opt-out requests. Consent and privacy obligations can vary by message type and jurisdiction, so review the applicable policy and legal requirements before changing subscription controls.

Document the suppression reason in a place the workflow owner can find. A silent skip creates repeat tickets and encourages unsafe workarounds. The marketing automation failure checklist explains how missing ownership and hidden exceptions turn isolated skips into recurring operational problems.

3. Validate recipient, sender, and message data

Verify the recipient address character by character and confirm that the workflow is reading the intended field. Imports, integrations, and form mappings can populate a secondary email field while the action reads the primary field. Whitespace, placeholder values, malformed domains, and overwritten fields can also stop a send before provider handoff.

Check every personalization token required by the template. Some platforms allow a fallback value, while others can produce a rendering error or skip an action when a required value is unavailable. Confirm the token belongs to the same record type as the workflow. HubSpot notes that token types can limit which workflow type can use an automated email.

Then inspect the configured sender. Confirm that the From address still exists, the connected inbox or sending service is authorized, the owner-based sender has a value, and reply routing points to an actively monitored address. A message can be valid while the chosen sender identity is unavailable for that contact or branch.

Use a controlled contact that contains the minimum required data. If that contact sends successfully, add the production fields one at a time until the error returns. This is more reliable than editing several template and workflow settings together.

4. Verify domain authentication and alignment

Sender authentication does not explain every missing email, but it is a required part of a reliable sending path. Check which domain appears in the visible From address, which domain the provider uses for the return path, and which service signs the message. Confirm that the DNS records published for those domains still match the active sending services.

Google's current sender guidelines require SPF or DKIM for all senders to personal Gmail accounts. Higher-volume senders have additional requirements, including SPF, DKIM, DMARC, valid DNS, TLS, low spam rates, domain alignment, and one-click unsubscribe for marketing and subscribed messages. Google also recommends authenticating each sending domain and monitoring DMARC reports.

SPF authorizes sending infrastructure. DKIM applies a domain signature that recipients can verify. DMARC evaluates alignment with the domain visible to the recipient and publishes a handling policy. A green check in the CRM may show that a setup step was completed, but DNS can later change. Verify the live records and send a message whose headers show the expected authentication results.

If several tools send as the same domain, maintain an inventory of every authorized sender. Remove obsolete services carefully and test after DNS changes. Do not publish multiple conflicting SPF records. Ask the provider or a qualified email administrator to review records when ownership is unclear.

5. Read provider events, not a single sent label

The CRM's send action and the email provider's delivery pipeline are separate systems. A completed action may mean the message was submitted, not that the receiving server accepted it. Find the provider message ID or correlation ID and review the event history for the same recipient and time.

Amazon SES documents event publishing for sends, deliveries, opens, clicks, bounces, complaints, rejections, rendering failures, and delivery delays. Those states illustrate the evidence a sending platform should expose. Your provider may use different names, so map each status to a clear operational meaning.

• Send or accepted: the provider accepted the request for processing.
• Delivery: the receiving mail server accepted the message. This does not guarantee inbox placement or reading.
• Delay or deferral: delivery is still being retried or postponed.
• Bounce: the receiving system rejected the message, either permanently or after retries.
• Rejection or rendering failure: the provider did not proceed with the message as submitted.
• Complaint: the recipient or mailbox provider reported the message as unwanted.

Capture the first non-success event, its code, timestamp, message ID, and sanitized explanation. Do not treat an open-tracking event as required proof because privacy controls and image blocking can make opens incomplete. Use provider acceptance and delivery events for transport diagnosis.

6. Look for timing races and state changes

Some emails fail because the workflow is logically correct but state changes in the wrong order. A contact can be enrolled before marketing status finishes updating. An owner-based sender can be evaluated before assignment. A branch can run before an integration writes the field it depends on. A contact can be removed from the workflow while waiting.

HubSpot recommends a short delay when a workflow changes a contact to marketing status and then sends a marketing email, so the status change has time to process. Treat that as a platform-specific example of a broader rule: when one step depends on committed state from another system, verify the destination state rather than relying only on visual action order.

Inspect timestamps in both systems. If the trigger and update occurred within seconds, repeat the test with an explicit condition that waits for the required value, or split the process at a reliable event emitted after the write completes. A fixed delay can reduce symptoms, but a state-based wait is usually easier to reason about when the upstream latency varies.

Related handoff problems often affect more than email. The CRM workflow handoff failure guide covers identifiers, ownership, and cross-system state transitions in more detail.

7. Recover safely and make the failure observable

Before replaying an email, confirm that the original message was not delivered and that the contact still qualifies. Check whether later steps already ran, such as task creation, pipeline movement, SMS follow-up, or a second email. Replaying the entire workflow can duplicate those actions even when only one message failed.

Prefer a bounded recovery path. Record the affected contact, original execution ID, provider message ID, failure reason, correction, and replay decision. Use a unique replay key or an explicit recovery flag so the same incident cannot be processed twice. Start with one controlled recipient, verify the provider events, then release the remaining eligible contacts in small batches.

Make the workflow observable after repair. Assign a named owner, route failures to a reviewed queue, define which statuses require action, and keep a test record for regression checks. Alert on missing completion evidence, not only explicit errors. A workflow that silently skips contacts needs a reconciliation report comparing expected sends with provider outcomes.

The workflow automation audit checklist provides a wider review of ownership, access, exceptions, and change control. For client communication sequences, the unresponsive follow-up automation guide explains how to prevent a technical gap from becoming a relationship gap.

Frequently asked questions

Why is my CRM email automation not sending?

The contact may not have enrolled, may be ineligible because of subscription or suppression rules, may have invalid data, or the message may have been rejected after provider handoff. Trace the first missing state.

How can I tell whether the workflow reached the email step?

Open contact-level enrollment or execution history and confirm the trigger, filters, branch, timing, and send action. Do not rely on the workflow's active status.

Can a CRM say sent when the recipient did not receive the email?

Yes. Sent can mean the request was accepted for processing. Check provider delivery, bounce, rejection, delay, and complaint events for the same message ID.

Do SPF, DKIM, and DMARC affect automated CRM email?

Yes. They help recipient systems authenticate the sender and evaluate domain alignment. Requirements vary by recipient and sending volume, so follow the current provider guidance.

Is it safe to replay a failed automated email?

Only after confirming eligibility, non-delivery, and duplicate protections. Test one controlled recipient and use a bounded recovery path instead of restarting the entire workflow.