Sending client email from your own domain, properly

If your client portal sends a report-ready notice from a domain that is not yours, two things happen: your brand leaks, and your deliverability becomes somebody else’s problem. Sending from your own domain fixes both, but only if the three records underneath it agree with each other. Most of the "the client never got the email" tickets in this industry come down to one of them being wrong.

What each record is actually for

Alignment is the one that catches people. A message can pass SPF against the sending platform’s domain and still fail DMARC, because the domain that passed is not the domain in the From header your recipient sees. That mismatch is exactly what DMARC exists to detect, and it is why "SPF passes, so why is it in junk" is such a common and misleading observation.

The order to do it in

Do these in sequence. Doing them in a different order is how firms end up publishing a strict policy that rejects their own invoices.

• Inventory every system that already sends as your domain: the mail host, the accounting package, the CRM, the marketing tool, the portal. Missing one is the usual cause of a self-inflicted outage later.
• Publish a single SPF record covering all of them. One record only. Two SPF records is a permanent error, not a merge, and watch the ten-lookup limit that nested includes blow through quietly.
• Enable DKIM signing on each sender and publish its selector. Prefer a 2048-bit key where the sender allows it.
• Publish DMARC at p=none with an rua address, and then wait. Two weeks of reports, minimum.
• Read the reports. They will show at least one legitimate sender you forgot. Fix those before tightening anything.
• Move to p=quarantine, watch again, then p=reject once a fortnight of reports is clean.

p=none is not a failure state, it is the observation phase. The mistake is not starting at none; it is never leaving it, and never reading the reports it produces.

Relay choices for a consultancy

Three arrangements are common and they trade off differently.

Your existing mailbox provider. Simplest to authenticate because the records mostly exist, and your sent items are where you expect them. Watch for per-account send limits: a portal that emails fifty client contacts about a delivered report can trip a threshold designed for a person typing.

A dedicated transactional relay. Better throughput and far better diagnostics, at the cost of another DKIM selector and another entry in your SPF record. Worth it once portal mail becomes operationally important, mostly because their logs will tell you what happened to a specific message.

Your own mail server. Almost never the right answer now. Reputation on a fresh address range is difficult to build and easy to lose, and a testing firm has better places to spend that effort.

Things worth doing that nobody tells you

• Set a reply-to that a human reads. Portal mail that comes from a no-reply address teaches clients to ignore it, which is expensive when the message is "your critical finding has been released".
• Send from a subdomain for portal traffic. It keeps automated sending reputation separate from the address your directors use, so one bad week does not affect both.
• Warm a new relay gradually rather than switching all traffic in one afternoon.
• Test against the mail systems your clients actually use, not just your own. A corporate filter behaves nothing like a consumer inbox.
• Keep the sign-in email plain. Heavy HTML, tracking pixels and link rewriting are exactly the features that make a security-conscious recipient’s gateway suspicious.

The scanner problem

Enterprise mail security products open links before the recipient does. If your sign-in email contains a one-time link, the scanner can consume it, and your client sees an expired-code message for a code they never used. This is not rare, and it is not their IT department being unreasonable.

Two defences work. Put the token in the URL fragment, which browsers never transmit to a server, so an ordinary scanner cannot see it. And offer a typed code alongside the link, so a recipient behind an aggressive gateway always has a path that does not depend on a URL surviving.