Transactional Email Is Infrastructure, Not Marketing

A password reset that lands in spam looks exactly like a password reset nobody requested. The customer tries again, fails again, and calls support, or leaves. By the time someone notices that order confirmations stopped arriving, the failure is three weeks old and the cause is a DNS record changed in a different quarter by a different team.

Email is the one integration in a typical stack where the receiving side can silently downgrade your message and never tell you. Your application hands the message to your provider and gets a 250. The provider hands it to Gmail and gets a 250. The message goes to spam. Every log in the chain reports success.

That gap got wider. Gmail and Yahoo started requiring authentication from bulk senders in February 2024. Microsoft followed for Outlook, Hotmail, and Live addresses on May 5, 2025. In November 2025, Gmail moved from temporary deferrals to permanent rejections for senders that still do not comply. A 5xx from Google is unambiguous: the message never reaches a mailbox, and if nobody watches the bounce stream, nobody finds out.

Most of the problem is ownership. Email is production infrastructure with an on-call surface, and it usually gets run as a marketing channel with a vendor. The team that owns the checkout does not own the DNS zone, and the team that owns the DNS zone does not know which application sends the receipts.

What the rules actually require

For anyone sending 5,000 or more messages a day to Gmail addresses:

• SPF and DKIM configured, with a DMARC record published.
• Domain alignment, meaning the domain in the From header matches the domain that passed authentication.
• One-click unsubscribe (RFC 8058) on marketing and subscribed mail.
• Spam complaint rate under 0.10%, and never at 0.30%.

Below 5,000 a day you are not a bulk sender, which is the exemption a lot of retailers think they are using. It stops applying the moment a Black Friday campaign goes out, because the threshold is daily, not annual.

A quieter requirement catches teams too. Valid forward and reverse DNS on the sending IPs is expected of all senders now, not just bulk ones, so a misconfigured PTR on a new relay presents itself as a reputation problem rather than a configuration error.

SPF is a budget, not a list

An SPF record authorizes senders against a fixed budget of 10 DNS lookups. Every include: costs at least one, and some cost more, because a and mx mechanisms resolve additional names underneath them.

Here is a record that looks reasonable and is already past the limit:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com
 include:spf.mailchimp.com include:cmail1.com include:servers.mcsv.net
 include:amazonses.com include:_spf.salesforce.com ~all

Eight includes. _spf.google.com alone expands into several nested lookups. Past 10, the whole record returns a permanent error, and a permanent SPF error against a ~all or -all policy is a failed authentication for every message that depends on SPF, including the transactional ones that have nothing to do with whatever tool someone added.

Two habits keep it contained. Count the lookups, not the includes, using a checker that walks the tree and reports the total rather than the visible list. And keep a separate subdomain for anything you do not control, so a newsletter vendor signed up in another department cannot consume the budget your receipts depend on.

Passing is not the same as aligning

This is the part that trips up competent engineers. SPF authenticates the envelope sender, the bounce address, which is almost never the address the customer sees. When a provider sends as bounces@em123.example.net on behalf of From: orders@example.com, SPF passes cleanly and DMARC still fails, because the authenticated domain does not align with the From domain.

DKIM is what fixes that, because it signs the message including the From header. A provider that signs with d=em123.example.net has the same alignment problem in a different place. A provider that signs with d=example.com in a selector you control closes it.

Check the headers on a real delivered message instead of the provider's configuration page:

dig +short TXT selector1._domainkey.example.com

If that returns nothing, the signing domain is not yours and alignment is being carried by SPF alone. That holds until a forwarder rewrites the envelope, which is exactly what mailing lists and some corporate gateways do.

DMARC at p=none is a monitoring exercise

p=none instructs receivers to deliver failing mail anyway. It is a reasonable starting position and a poor permanent one. The ladder is p=none with a rua= reporting address, then p=quarantine, then p=reject, advancing only when aggregate reports show that every legitimate stream authenticates.

The reports are the awkward part. They arrive as XML attachments, one per receiving domain per day, and nobody opens them. Either put a parser in front of that mailbox or skip publishing rua=, because an unread inbox is not monitoring.

One 2026 detail worth knowing before flipping to p=reject: the DMARCbis revision, published as RFC 9989, directs receivers to treat p=reject as p=quarantine for indirect flows such as forwarding and mailing lists. That removes much of the risk for ordinary user mailboxes. Transactional domains on dedicated infrastructure are the case where p=reject remains the right target, since no legitimate third party should be relaying your password resets.

Where it breaks after a provider change

The most common way a working setup stops working is a migration nobody called a migration. An e-commerce platform adds a shipping notification vendor. A team moves from one ESP to another and leaves the old records in place. Three things tend to go wrong at once.

The new vendor's DKIM selector gets added and the old one never gets removed, so the record set fills with signatures nobody can revoke. The SPF record gains a ninth and tenth include from whoever was holding the ticket, with no lookup count. And the From address quietly moves to a shared domain the vendor owns, which delivers fine right up until the vendor's reputation takes a hit from a different customer.

Provider changes deserve the treatment a schema migration gets: an inventory of every stream, a DNS diff reviewed before cutover, and a check that the new DKIM selector resolves and aligns before the old sending path is switched off.

Separate the streams

The highest-leverage change here is architectural rather than forensic. Split sending into streams with their own subdomains, and their own IPs where volume justifies it.

• Transactional: password resets, receipts, shipping notices, invoices. mail.example.com.
• Marketing: newsletters, promotions, cart abandonment. em.example.com.
• System: monitoring alerts, error reports, internal notifications. alerts.example.com.

The point is failure isolation. A promotion that pushes the complaint rate over 0.30% damages the reputation of the domain and IP that sent it. When that is the same domain your order receipts use, a marketing mistake becomes a support queue by Monday morning.

This is also where a lot of teams discover they cannot separate the streams in their own logs. If the only identifier on an outgoing message is "the app sent it", the first task is tagging every send call with a stream name so bounce and complaint rates can be attributed to something.

Measure inbox placement, not delivery

Delivery rate is the number providers put on the dashboard because it is the number that looks good. It counts handoffs, not arrivals.

What you can actually observe:

• Google Postmaster Tools per domain, for spam rate, reputation, and authentication results.
• Your own bounce stream, filtered for 5xx from google.com and outlook.com. A rise in 550 responses carrying a policy reason means Gmail is enforcing the rules against you.
• Complaint rates from the feedback loop, tracked per stream rather than in aggregate.
• DMARC aggregate reports, which will show you sending streams you did not know existed. There are always a few.

Alert on the 5xx rate per stream. It is the one signal that moves before customers call, and it moves within minutes rather than days.

New sending IPs need time as well. A freshly provisioned address has no reputation, and volume that ramps too quickly reads like a compromised host. Ramp in steps over a few weeks, watch the deferral rate rather than the bounce rate, and keep a fallback path so password resets keep flowing if the new address gets throttled. Providers do not warn you about this. They just slow you down.

If you want the logo in the inbox

BIMI is the last step, and it only works from a position of strength: a DMARC policy at p=reject, or p=quarantine with pct=100, stable for a while, plus a logo in SVG Tiny PS format. Gmail and Apple Mail display it.

The friction is the certificate. A Verified Mark Certificate needs a registered trademark and runs about $1,500 a year. The Common Mark Certificate skips the trademark requirement but is supported by Gmail only, so the audience you get it for is smaller than the audience you have.

Vendors quote open-rate lifts for BIMI in the high thirties. Treat those as marketing numbers rather than controlled studies. The defensible case is recognition and trust in a crowded inbox, which has real value and is not the same thing as a lift you can put in a forecast.

The checklist

• Count SPF lookups, not includes, and leave headroom below 10.
• Make sure at least one DKIM signature aligns with the From domain.
• Publish DMARC with rua=, and plan a measured path to p=reject.
• Split transactional and marketing onto separate subdomains.
• Support one-click unsubscribe on everything that is not purely transactional.
• Watch the 5xx stream instead of the delivery rate.
• Test into real mailboxes at Gmail, Outlook, and one corporate domain. A seed-list score of 9.8 out of 10 says nothing about where the message landed.

None of this is glamorous work. It is DNS records, header inspection, and a dashboard with three panels. But email is the one channel where a silent failure costs revenue every day and appears in no error log, which makes it worth a deliberate afternoon every quarter.

If your transactional email has not been audited since the last provider change, that is work we do. Tech Hub Services reviews email authentication and deliverability for e-commerce and enterprise clients, including the DNS changes that come with it.