Email Deliverability for Law Firms: Stop Invoices Landing in Spam

Most communication failures announce themselves. Deliverability does not: the message leaves, nothing bounces, and the recipient never sees it. The firm concludes the client is unresponsive; the client concludes the firm went quiet.

For correspondence this is an irritation. For invoices and deadline notifications it is money and risk, and it is the reason "I never received it" is so often true rather than convenient.

Receiving systems authenticate mail using three DNS records, and firms typically have one or two configured rather than all three.

• SPF lists which servers may send for your domain. A firm that has added a practice system, a marketing tool and an accountant's portal over the years frequently exceeds SPF's lookup limit, at which point it fails silently.
• DKIM cryptographically signs outbound mail so the recipient can verify it was not altered and genuinely came from your domain.
• DMARC tells receivers what to do when the other two fail, and — importantly — sends you reports about mail claiming to be from you.

DMARC is the one most firms lack, and it is the one that turns deliverability from guesswork into something observable.

Systems that send "on behalf of" a firm from their own infrastructure put a firm's client communication in a shared reputation pool it does not control. Someone else's behaviour affects whether your invoice arrives.

Where a system sends transactional mail for you, it should authenticate as your domain with your DKIM key. Better still for correspondence: send through the lawyer's own mailbox, so the client sees the address they already correspond with and the message inherits an established sending reputation.

PDF attachments are exactly what filters are most suspicious of, particularly from senders with thin reputation, and they are the part of the message most likely to be stripped or quarantined by a corporate gateway.

They are also poor practice for another reason: an attachment gives no evidence of receipt. A link to a hosted document does — the firm knows when it was first opened. Sending the PDF and making the same document available at a stable link covers both the client who prefers the file and the firm that needs to know it arrived.

Reputation degrades quietly. A stale contact list producing bounces, a compromised account sending spam for a weekend, or a marketing campaign to unengaged recipients all damage the same domain that sends your invoices.

DMARC reports make this visible. So does the simple discipline of separating bulk sending from transactional and correspondence mail, ideally on a subdomain, so that a marketing problem cannot take client communication down with it.

Even correctly configured, a share of mail will be filtered — corporate gateways are aggressive and their rules are not published. The operational answer is not to try harder but to stop treating email as proof.

Delivery is not receipt, and neither is an authority to act. A system that treats "we sent the notification" as equivalent to "the client was informed" will eventually make a consequential decision on a message nobody read.

Correspondence goes through the lawyer's own connected Gmail or Outlook, so client mail comes from the address the client knows and inherits that mailbox's reputation rather than a shared pool.

Invoices are emailed with their PDF and hosted at a stable link, so the firm records when the client first opened it and captures an acknowledgment where given — which converts "I never received it" from an argument into a question with an answer. Reminders schedule from the due date rather than depending on anyone remembering.

Deliberately, delivery is never treated as authority anywhere in Mersal. Notification state does not gate any consequential action: nothing is locked, escalated or removed on the strength of an email having been sent, because a message that was sent is not a message that was read.