A green run only means the mail server took your email
Automated email fails silently. Order confirmations and reminders sit in junk folders while every run stays green, usually because of DKIM alignment, an exhausted SPF record or bounces nobody processes. Here is how we set automated sending up instead.
A green run only means the mail server took your email
That is the whole guarantee. A mail module turns green when some server accepted the message for relay. Whether it reached an inbox, a junk folder or nothing at all is decided a few seconds later by the receiving side, and when the verdict is spam, nobody tells you.
We audited a clinic group's appointment reminders last year. Twelve thousand messages a month, zero failed runs, and a no-show rate that had climbed by a fifth since the workflow went live. Roughly one in eight reminders was being filed as junk. The reception desk had noticed patients saying they never got anything and assumed people were forgetting.
Where the trust comes from
Receiving servers decide whether a sender is allowed to write on behalf of your domain, and three DNS records drive that decision.
SPF lists the servers permitted to send for you. If your automation platform relays through its own infrastructure, that infrastructure has to appear there. The record allows ten DNS lookups and no more, and each include: can trigger further ones. Companies that have added a newsletter tool, a CRM, a helpdesk and an accounting system over the years are usually at the ceiling already. Everything past lookup ten is ignored, and that tends to be whatever was added most recently.
DKIM cryptographically signs each message so the receiver can verify it against a public key in your DNS. Without it, forwarded mail fails, because SPF is evaluated against the forwarding server. Any organisation that distributes a shared inbox internally hits this daily.
DMARC tells receivers what to do when a check fails, and it adds a requirement the other two do not have: the verified domain has to match the address in the From header. That requirement is what catches most automations. The platform signs with its own sending domain, your domain sits in the From field, and DMARC treats the mismatch as a failure even though SPF and DKIM each passed on their own.
Google and Yahoo have required all three from higher-volume senders since early 2024. Corporate mail gateways have applied comparable rules for longer, without publishing them.
Reputation, and how automations damage it
DNS records get you past the door. What happens after that depends on how the sending behaves.
A newly created subdomain has no history, so pushing three thousand confirmations through it on day one looks like a purchased channel. We ramp instead: a few hundred a day, increased over two or three weeks.
Bounces are the expensive part, and they are almost always unhandled. When a workflow keeps mailing addresses that no longer exist because nothing writes back to the CRM, the sending domain's reputation drops. One logistics client had forty dead addresses out of 2,800, all of them contacts who had changed jobs.
A noreply@ address with no real mailbox behind it loses you bounce data, complaints and customer replies in one move, and some filters penalise senders that cannot be reached at all.
Mixing transactional mail and marketing on the same channel costs you the transactional side. A campaign people delete unread will drag down the order confirmation sharing that subdomain.
The internal case is the one nobody tests. An automation mailing a colleague on your own domain still arrives from outside with your domain in the From field, and Microsoft 365 or Google Workspace reads that as spoofing. Approval requests sit in an admin quarantine for a week while the build was verified against somebody's private Gmail, which sailed through.
What we set up instead
Automated sending gets its own subdomain, so a reputation problem never reaches the domain the leadership team writes from.
The SPF record gets counted rather than estimated, with dead services removed. Flattening is the fallback, with the caveat that it has to be maintained by hand whenever a provider changes IP ranges.
DKIM is configured with a custom sending domain. Every serious provider supports it, it costs two DNS records, and it is what makes DMARC alignment pass.
DMARC starts at p=none with a reporting address. The reports arrive daily and show every service sending as you, usually two you had forgotten about. Once two weeks look clean, we move to quarantine, then reject. Starting at reject instead once took a client's invoicing offline for half a day.
Bounces go to a mailbox that is actually read. A hard bounce flags the contact, and the workflow skips that address from then on. Two modules, and more effect on delivery than any further DNS change.
Delivery is measured, not sending. Providers emit webhooks for delivered, bounced and complained, and those events belong back in the automation so a daily delivery rate exists. Below a threshold, someone gets alerted.
We also add one mailbox each at Gmail, Outlook and a large consumer provider as a silent recipient of a daily test send. If the message lands in junk there, you know that day.
The ten-minute check
Send one message from the automation to a Gmail account and open Show original. SPF, DKIM and DMARC are listed with pass or fail, along with the domain that signed the message. If that domain differs from your From address, alignment is your problem, three passes notwithstanding.
Then check whether _dmarc.yourdomain.com resolves to anything. About half the setups we look at have no record, which means no reports either, which means nobody knows who is sending as the company or how well it arrives.
For the clinic group the fix was alignment plus a bounce feed into the patient system. Two hours of configuration, delivery back above 98 percent, and a no-show rate that returned to where it had been before anyone automated anything.