Order Emails Landing in Spam and Customers Saying "I Never Got It": How to Build a Transactional Email System with SPF, DKIM, DMARC, Bounce Handling and Real Deliverability

An online course business came to us last month with what sounded like a small problem: "some students say they never got the class notification." We pulled three months of send logs. Total sent: 41,200. Reported successful by the system: 40,930. Actually landing in an inbox: roughly 31,600 — meaning about 22% went to spam or bounced. Inside that 22% sat 180 class notifications to students who had already paid. Support fielded 94 phone calls about it. Nothing was broken. The code was fine. SMTP returned 250 OK every time. What had failed was sender reputation — a line item nobody has ever seen on a quote.

When This Is Worth Building — And When It Isn't

Build the full transactional email stack if:

• Your site sends more than 3,000 system emails a month (orders, notifications, verification codes, reminders)
• Non-delivery costs real money: payment confirmations, class notices, shipping alerts, password resets
• Support needs to answer "was it sent, and did they open it?" without escalating to engineering
• You have multiple sending contexts requiring separate domains (transactional and marketing must be split)
• Your customers are enterprises with strict inbound mail gateway rules

Don't spend the money yet if:

• You send fewer than 500 emails a month with no time sensitivity — plain SMTP is fine
• Your real notification channel is LINE or SMS and email is only a fallback
• The site isn't live yet — optimising deliverability without real send data is guesswork
• You only send marketing newsletters and no transactional mail — that's a newsletter platform, not a build

Alternatives Matrix

For most SMBs the right answer is: transactional mail through Postmark or Resend, marketing mail through SES or a newsletter platform on a different subdomain. The two sending domains must be separate.

Full Process Breakdown (Phases, Time, Deliverables, Tools)

• Phase 1 — Current-state audit (3 working days): catalogue every send point in the system (usually twice as many as the client believes), current sending domains, and baseline deliverability. Deliverables: send-context inventory plus baseline report. Tools: MXToolbox, Google Postmaster Tools.
• Phase 2 — Domain authentication (2 working days): configure SPF, DKIM and DMARC DNS records and establish a dedicated transactional subdomain such as mail.yourbrand.com. Deliverables: DNS record list and verification screenshots. Tools: Cloudflare DNS, DMARC.org checkers.
• Phase 3 — Sending service integration (5–8 working days): integrate the sending API, build the template system, implement queueing and retries. Deliverables: working template library and test report. Tools: Laravel Mail + Queue, Mailpit for local testing.
• Phase 4 — Event ingestion and suppression list (5 working days): consume delivered / bounce / complaint webhooks, auto-suppress hard bounces, cap soft bounce retries. Deliverables: event tables and a support lookup screen.
• Phase 5 — Warm-up and monitoring (14–30 days): ramp volume on the new domain in stages, watch complaint rate daily. Deliverables: deliverability dashboard. Tools: Google Postmaster Tools, DMARC report parsing.

Real Cost Breakdown

• Development: basic integration 16–24 hours; full build with bounce handling, suppression, support lookup and template management runs 80–140 hours
• Sending service: SES at 40,000 emails ≈ NT$130/month; Postmark at the same volume ≈ NT$1,500–3,000
• Hidden cost 1: DNS and certificate management for the dedicated subdomain, NT$0–3,000/year depending on provider
• Hidden cost 2: human time during warm-up — someone must check complaint rates daily for the first 30 days, about 0.5 hours/day
• Hidden cost 3: localisation and mobile adaptation of templates, 2–4 extra hours per template
• Hidden cost 4: DMARC reports arrive as XML; reading them needs a tool or service, NT$0–900/month
• ScriptWalker service: Transactional Email and Notification System Build, from NT$68,000 (three authentication records, sending service integration, bounce and suppression handling, five templates)

Implementation Reality vs Client Expectation

• Clients assume: "sent" in the dashboard means delivered. Reality: an SMTP 250 OK only means the receiving server accepted it, not that it reached an inbox. The real metric is inbox placement rate, visible only through external tools like Google Postmaster Tools.
• Clients assume: SPF is enough. Reality: Google and Yahoo bulk sender requirements call for SPF, DKIM and DMARC together, plus one-click unsubscribe headers, plus keeping spam complaint rate below 0.3%. Missing any one of these is grounds for downgrading you.
• Clients assume: switching provider fixes deliverability. Reality: reputation attaches to the sending domain, not the vendor. Move a damaged domain to a new provider and things improve for two weeks, then revert.
• Clients assume: marketing and transactional mail can share a domain. Reality: marketing complaint rates typically run ten times higher. Sharing a domain means your newsletter drags down the deliverability of your order confirmations.

Common Traps and How to Avoid Them

• Trap 1: sending from a gmail.com or yahoo.com address. Fix: always use your own domain, and that domain must carry a DMARC record.
• Trap 2: no suppression list, so hard bounces get retried forever. Fix: write every hard bounce to a suppression table and stop permanently. This is the single fastest way to destroy reputation.
• Trap 3: launching DMARC straight at p=reject. Fix: start at p=none, collect reports for two weeks, confirm every legitimate sender passes, then step up to quarantine and reject.
• Trap 4: sending 50,000 emails on day one from a new domain. Fix: warm up — 200 on day one, growing 30–50% daily, reaching target volume in 14–30 days.
• Trap 5: verification codes share a queue with everything else. Fix: time-critical mail goes to a high-priority queue, marketing and reports to low priority, so the monthly report never blocks a login code.
• Trap 6: templates tested only on desktop. Fix: before handover, view every template in the Gmail app, Outlook desktop and Apple Mail. Outlook's CSS support remains its own planet.

Success Metrics and the 90-Day Roadmap

• Days 1–30: complete warm-up. Targets — delivered/sent ≥ 97%, hard bounce ≤ 2%, spam complaints ≤ 0.1%. Check domain reputation in Google Postmaster Tools daily.
• Days 31–60: optimise content and inbox placement. Targets — transactional open rate ≥ 45%, "didn't receive it" support tickets down 60%+ against pre-launch. Begin splitting marketing and transactional subdomains.
• Days 61–90: move DMARC from p=none to p=quarantine and evaluate BIMI so your logo renders in the inbox. Target — DMARC pass rate ≥ 99%.

Decision Checklist

• ☐ We send more than 3,000 system emails a month
• ☐ A missed email directly causes refunds or complaints
• ☐ We do not currently know our actual delivery rate
• ☐ Our sending domain has no DMARC record
• ☐ Marketing and transactional mail share one domain
• ☐ Hard bounces are not automatically suppressed
• ☐ Support cannot look up the status of a specific message
• ☐ Customers have reported our mail landing in spam
• ☐ Verification or password reset emails have been delayed over 5 minutes
• ☐ Nobody here monitors Google Postmaster Tools
• ☐ Templates have never been tested in Outlook desktop
• ☐ We expect send volume to more than double in the next 12 months

Five or more ticked: schedule this for next quarter. Eight or more: it is already costing you money daily.

FAQ

What's the actual difference between SPF, DKIM and DMARC?

By analogy with physical post: SPF asks whether this sender is authorised to post in your company's name, DKIM asks whether the wax seal has been broken in transit, and DMARC is your published policy on what a recipient should do when either check fails. Missing any one gives major mailbox providers a reason to downgrade you.

Does cheap SES mean worse deliverability?

No. Deliverability depends mainly on your domain reputation and sending behaviour, not the vendor. The price of SES is that bounce events, suppression lists and dashboards are your build — all of which come included with transactional specialists. The difference is engineering hours, not inbox placement.

Can a domain already flagged as spam be recovered?

Yes, but slowly. The usual path: stop all non-essential sending, complete all three authentication records, purge invalid addresses, then rebuild reputation over 30–60 days of low-volume warm-up. If the domain has hit major blacklists, delisting requests must be filed individually.

Can we skip warm-up and send at full volume?

Technically yes; the usual result is a new domain flagged immediately. Keep week-one volume on a new domain or IP under 1% of target, then grow 30–50% daily. The two weeks you save typically take two months to repair.

Want to Know What Share of Your Mail Actually Arrives?

We run a one-off Email Deliverability Health Check, delivering a report with current delivery rates, authentication gaps, bounce classification and a prioritised remediation list you can drop straight into next quarter's sprint plan.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p