The best email setup for an accounting practice starts with your own domain. Every person gets a named mailbox, with multi-factor authentication on all of them. One address is named as the record for client documents. Anything carrying a taxpayer’s identifying number goes by a second channel. Most of that is required of you rather than recommended to you.
- The FTC’s Safeguards Rule names accountants in its own examples, and the exception for small firms leaves the two things that decide your mailbox exactly where they are: multi-factor authentication and encryption in transit.
- Email is the delivery notice, not the delivery. The document travels another way and the password travels a third way.
- Your setup is judged twice: on an ordinary Tuesday, and on the morning somebody else signs in as you. The second one carries a next business day deadline.
- Almost all of this is decided rather than bought. The domain, the address plan, the authentication and the written program are decisions, and whatever software you choose later sits on top of them.
Start with the domain
The domain is the only part of this that’s genuinely yours, and it outlives every product decision you make around it. Mail platforms get switched, portals get replaced, practice management gets migrated. The address on your letterhead stays, and so do the eleven years of archive attached to it. Every one of those switches is easy exactly to the degree that you own the name.
Three things about the domain are worth checking once and then forgetting. It’s registered to the firm rather than to whoever set it up in 2014, which is the version that becomes a problem when that person retires. Its renewal is automatic, and its expiry date is known to more than one person. And the registrar account itself sits behind multi-factor authentication, because an attacker who reaches the registrar controls where your mail goes.
The reason to say this to accountants specifically is that a working alternative exists and is common. A sole practitioner can run a practice from a consumer mailbox on somebody else’s domain, and plenty do. IRS Publication 4557, the Service’s guide to safeguarding taxpayer data, puts the requirement plainly: “Use separate personal and business email accounts; protect email accounts with strong passwords and two-factor authentication if available” (Rev. 6-2024, checked September 6, 2026). Separate is the requirement. A domain is just the cheapest way to make separate durable.
Named mailboxes and role addresses
Then the address plan. In a practice of five to fifteen people it’s smaller than firms expect. Every person gets a named mailbox. Beyond that, three role addresses cover most practices: the general one on the website, one for documents, and one for billing. Each address past those three is one more place mail can land while everyone assumes somebody else is watching it.
How you build a role address matters more than it looks. The three mechanisms behave differently, and the differences bite in this vertical.
An alias is free. It lands in a named person’s mailbox and lets them send as that address. That’s the right answer for billing. For documents in a firm of more than two people, it turns one person’s absence into a gap in the record.
A shared mailbox is a real mailbox that belongs to the firm rather than to a person. In Microsoft 365 it holds up to 50 GB unlicensed and supports a maximum of 25 users (checked September 6, 2026), which comfortably covers this size of firm. The same page carries the constraint that decides the design: “Email sent from a shared mailbox can’t be encrypted because the mailbox doesn’t have its own security context (username and password). As a result, it can’t be assigned an encryption key” (Microsoft 365 admin documentation, checked September 6, 2026).
Read that against what a documents address is for, and the answer takes shape. Build the address that handles your most sensitive traffic as a shared mailbox, and it becomes the one address in the firm that can’t send protected mail. So let it receive. Outbound goes from a named person who has a security context of their own, and anything sensitive leaves by the second channel.
Which address is authoritative for a given client’s documents is a separate decision. It’s the one that stops four honest people giving three different answers about the same return. Running the firm inbox is where that argument lives, along with what to do about clients who reply to whoever wrote last.
The floor the Safeguards Rule puts under it
Most buying guides treat security as the part you bolt on after choosing. In a tax practice it runs the other way. Several of these decisions are made for you before you start.
The FTC’s Safeguards Rule uses accountants as its worked example. “An accountant or other tax preparation service that is in the business of completing income tax returns is a financial institution because tax preparation services is a financial activity listed in 12 CFR 225.28(b)(6)(vi)” (16 CFR 314.2(h)(2)(viii), checked September 6, 2026). The IRS says the same thing in plainer words, in Publication 5708: “Under the GLBA and Safeguards Rule, tax and accounting professionals are considered financial institutions, regardless of size” (Rev. 8-2024, checked September 6, 2026).
Two of the rule’s elements land directly on the mailbox.
Multi-factor authentication, on everything. The text is broader than most firms assume. “Implement multi-factor authentication for any individual accessing any information system, unless your Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls” (16 CFR 314.4(c)(5), checked September 6, 2026). Any individual, any information system. That reaches past the tax software, and past the mailboxes that happen to hold returns. The seasonal preparer’s account is inside it. So is the front desk account. So is the dormant one that was left enabled after somebody left.
Encryption in transit. The text is “Protect by encryption all customer information held or transmitted by you both in transit over external networks and at rest,” with compensating controls allowed only where you’ve determined encryption is infeasible and your Qualified Individual has approved them.
Both of those apply at every size. The rule’s exception is one sentence: “Section 314.4(b)(1), (d)(2), (h), and (i) do not apply to financial institutions that maintain customer information concerning fewer than five thousand consumers” (16 CFR 314.6, checked September 6, 2026). Those four are the written risk assessment, the penetration testing and vulnerability scanning regime, the written incident response plan, and the annual report to a governing body. That’s the whole list. Authentication stays. Encryption stays. So does the requirement that your program be “written in one or more readily accessible parts”, which sits in a different section (16 CFR 314.3(a)).
The IRS publishes a template for that written program in Publication 5708, aimed squarely at smaller practices. What the exception buys a small firm, and how to write a policy people will actually follow rather than a copy of a large firm’s paperwork, is the subject of a simple AI policy a small firm will actually use. The part that belongs here is narrower. Your email setup is one of the things that document has to describe. So make these decisions once and write them down, rather than making them again every few months and remembering them differently.
None of this is legal advice, and your own counsel may read a clause differently. The shape of it is settled, though, and the practical consequence is short. If you’re choosing between a mail arrangement that supports authentication and encryption and one that skips them, the choice has already been made.
What email should carry and what it should not
The single most useful line to draw in a practice setup runs between what email carries and what it merely announces.
The IRS is direct about where it falls. Publication 4557 says: “Send only password-protected and encrypted documents if you must share files with clients via email or use Secure File Transfer Protocol (SFTP) to transmit files instead of email.” Read the framing. Email is the fallback, and even then the file travels protected.
The sample plan in Publication 5708 turns it into a policy a firm can adopt as written. “It is Firm policy that PII will not be in any unprotected format, such as e-mailed in plain text, rich text, html, or other e-mail formats unless encryption or password protection is present. Passwords MUST be communicated to the receiving party via a method other than what is used to send the data; such as by phone call or SMS text message (out of stream from the data sent)” (Rev. 8-2024, checked September 6, 2026).
Two channels for the document, three for the exchange. The password travels separately from the thing it protects. That last part is where firms quietly fail. A protected PDF and its password in the same thread is one compromised mailbox away from being an unprotected PDF.
So the setup needs a documented second channel and a rule about what crosses into it. Draw the line at identifying numbers and account numbers rather than at what feels sensitive, because feel is inconsistent across a team of nine in March. A W-2, a K-1, a bank statement, a driver’s license, a signed 8879: those go by the other channel. A question about a vehicle stays in email.
Check what the built-in encryption in your mail platform covers before you count on it at your size. Google’s hosted S/MIME is available on Frontline Plus, Enterprise Plus and the three Education editions (Google Workspace admin help, checked September 6, 2026). Those sit above the edition a seven-person firm buys. Microsoft’s shared mailboxes stop at the line quoted above. The realistic answer is usually a portal, a secure file transfer service, or a mail product with a genuinely sealed channel. What matters is having exactly one of them, and everybody knowing which.
Then the part every policy meets on contact. Your clients will email it anyway. Somebody photographs a W-2 on a kitchen table and attaches it to a reply. The client who used your portal correctly in February forwards the reminder to their spouse in March. Inbound arrives however your clients send it, so the setup’s job for inbound is different. Make sure it lands somewhere covered by the same authentication and retention as everything else. Make sure the reflex when it arrives is to stop forwarding it onward in the clear. The craft of asking for a document in a way that gets it sent correctly the first time is managing client document requests.
Making the firm hard to impersonate
A tax practice is an unusually good domain to forge, and the reason is your calendar rather than your security. For several weeks a year, every one of your clients is expecting an email from you about money, refunds and bank details. A forgery that lands in that window can be crude and still work.
Sender authentication is the cheap half. Google requires every sender to Gmail accounts to “Set up SPF or DKIM email authentication for your sending domains,” and that has applied to all senders since February 1, 2024 (Gmail sender guidelines, checked September 6, 2026). If your mail is being delivered, you’ve probably met it already.
That tells a receiving server the mail is genuinely yours. DMARC is the record that tells it what to do with a message that fails. Google requires DMARC of senders above 5,000 messages a day to Gmail accounts, a volume a firm of this size stays well under, so the requirement passes you by. Publish one anyway. Put it on the domain you send from, and on any domain you own and never send from. The second case is the one firms forget, and a parked lookalike domain with no policy on it is a free letterhead for somebody else.
The other direction is stranger, and the IRS states it plainly enough that it’s worth quoting rather than paraphrasing: “Never open or download attachments from unknown senders, including potential clients; make contact first by phone, for example.” That’s a rule almost no other business could operate under. A new inquiry with a document attached is exactly what a growing practice wants. It’s also exactly the shape of the attack aimed at preparers every January.
That’s hard to train away, so build the intake around it. Strangers arrive at the general address or the website form. That’s the address where somebody expects to make a phone call before opening anything, and the person watching it in season knows that’s the job. Named preparer mailboxes are for clients who already exist.
One more from the same publication, because it points back at you: “A legitimate business will never email and request personal or sensitive information be sent to them via email, unless through a secured mail service.” Read it as an instruction about your own outbound. A firm that routinely asks clients to email a scan of a Social Security card has spent a season teaching two hundred people to comply with whoever asks next in the same tone.
While you’re in the signature block, the standard Circular 230 disclaimer at the bottom of every message has been optional since 2014. In the preamble to the final regulations, effective June 12, 2014, Treasury and the IRS wrote that “these amendments will eliminate the use of a Circular 230 disclaimer in e-mail and other writings” (T.D. 9668, checked September 6, 2026). An accurate statement of the limits of advice you actually gave is still fine. What’s over is the reflexive block on every message, including the ones that carry no tax advice at all.
Access while people come and go
The standard the rule sets for access is finer than any mail platform can meet. It wants controls that “limit authorized users’ access only to customer information that they need to perform their duties and functions” (16 CFR 314.4(c)(1)(ii), checked September 6, 2026). That’s a per person, per record grain, finer than anything products in this category offer. The argument about where those lines actually run inside a practice is one of its own. What the setup can do is coarser, and it’s still worth doing.
Access to a role mailbox comes through named accounts. Each person signs in as themselves. Microsoft’s own guidance on shared mailboxes is unambiguous about the account behind one: “Always block sign-in for the shared mailbox account and keep it blocked” (checked September 6, 2026). The reason to care is evidence rather than tidiness. A log naming a person tells you who read the mail, a log naming documents@ tells you the mailbox was open, and the difference shows up in the one conversation where it matters.
The seasonal preparer is the recurring failure. Firms are quick to grant access in January and slow to remove it in May, and an account that sits idle stays quiet while somebody else uses it. Put the removal date in the calendar on the day you grant it.
When someone leaves for good, the mailbox stays a firm record. It gets converted or forwarded rather than deleted, because what’s in it is the history of what your clients were asked and when. Publication 4557 adds two housekeeping items to the same moment, and both are easy to skip. Check e-file applications and PTIN accounts for the return counts filed under your EFINs and PTINs. Then “Withdraw from any outstanding authorizations (power of attorney/tax information) for taxpayers who no longer are clients.”
What to keep and the two clocks after a breach
Retention in a practice pulls two ways, and both directions have a rule behind them.
The Safeguards Rule leans toward deletion. It requires secure disposal of customer information “no later than two years after the last date the information is used in connection with the provision of a product or service to the customer to which it relates, unless such information is necessary for business operations or for other legitimate business purposes, is otherwise required to be retained by law or regulation” (16 CFR 314.4(c)(6)(i), checked September 6, 2026). It also asks you to review the retention policy periodically, and to keep only what you have a reason to hold.
A practice mailbox nearly always sits inside that exception. Correspondence about a return supports the return, and the return has its own retention period under other law. An exception is a reason you give, so be ready to say which one applies when somebody asks.
The IRS template puts the decision in front of you by leaving it blank. Publication 5708’s sample retention attachment reads: “In no case shall paper or electronic retained records containing PII be kept longer than ____ Years.” Filling in that blank, for mail as well as for files, is the piece of setup most firms still have ahead of them. Pick the number from your longest applicable retention obligation rather than from instinct. Write it down. Then let the mail platform enforce it, rather than whoever cleans up in July.
Then the clocks, which are the reason all of this is worth an afternoon.
If you are an Authorized IRS e-file Provider, Publication 1345 is direct: providers “must report security incidents to the IRS as soon as possible but not later than the next business day after confirmation of the incident,” and the sixth of the six e-file standards, Reporting of Security Incidents, “is now mandated for all Providers” (Rev. 12-2025, checked September 6, 2026). The route is your local stakeholder liaison. The IRS’s own page on data theft says liaisons “will notify IRS Criminal Investigation and others within the agency on your behalf. Speed is critical” (checked September 6, 2026).
Separately, the Safeguards Rule requires notice to the FTC where a notification event “involves the information of at least 500 consumers.” That notice is due “as soon as possible, and no later than 30 days after discovery of the event” (16 CFR 314.4(j)(1), checked September 6, 2026).
Next business day, and thirty days. Look back at the setup with those two numbers in hand, because they change what “good” means. A firm under 5,000 consumers can skip the written incident response plan. The next business day deadline still applies, and that one is hard to hit from a standing start while you’re working out who to call. Two things make it survivable, and both are configuration rather than purchase. One is an audit log, turned on before anything happens, that somebody knows how to read. The other is one page naming who calls the stakeholder liaison, who calls the insurer, and who tells the clients. That page is the smallest useful version of a plan, and it takes about twenty minutes.
Where Point sits in all this
Everything above is yours. Point is a layer you put on top of it afterward, and one worth judging on whether it inherits your setup or asks you to redo it.
Point is an AI email client. Point signs in to the Gmail or Microsoft 365 mailbox your firm already runs, so the domain you registered, the addresses you planned and the archive you’re keeping stay exactly where they are. No new address, no migration, nothing for your clients to learn. The address you named as the record for documents goes on being that address.
What changes is the mail in front of you. The feed is sorted before you open it, weighed on what a message is worth to you and how much time is left on it, so the client with a filing date sits above a software receipt on the worst morning of the year. There’s more on how that weighing works if you want it. Each thread carries a plain summary you read before opening. An ask inside a message becomes a dated task, with the thread still hanging off it. Leave a standing request to hear when one particular document lands, and you hear about it once, on arrival, rather than by checking. Attachments gather into a list instead of vanishing into threads. Ask a document a question and you get an answer with a link back to the page it was read from.
The controls are the part that matters to a firm inside the Safeguards Rule. Autonomy is a dial with its own setting for each kind of action. The dial runs from suggest-only through review to fully handled, and review is the default out of the box. Raise one and Point stops checking in for that kind of action and gets on with it, which is what raising it is for. Actions land in an activity log with times against them, and most can be reversed from there. One limit holds everywhere in software: a message already delivered to somebody else’s server can’t be pulled back. If you run a second business alongside the practice, the two are sealed off from each other, and that boundary is drawn around a business you operate rather than around the clients inside one.
For the exchange that should have no reader at all, Point offers a sealed channel. The message is encrypted on your device before it goes and opened on the recipient’s. The trade is worth knowing in advance. Sealed mail stays out of the ranking and the summaries, and no dated task comes out of it, since Point has no more access to the contents than anyone else. Treat it as the lane your policy’s second channel describes, rather than as a setting for the whole mailbox.
Most of this article stays your work. You register the domain, choose the address plan, write the information security program, fill in the retention number and file the incident report. Point sits next to your portal and your practice management, and leaves the ledger and the returns alone. Connecting Point is a service provider decision, made under the same rule as the rest of the setup, and the questions to put in writing first is the list to send before anything is connected. Everything Point does is the inventory, and Point for accountants reads it back through a practice.
Common questions
Do we need a separate email address just for client documents?
It’s a choice rather than a requirement, and naming one address is what stops the same question getting three answers. The useful version is a receiving address with somebody accountable for it, rather than a second inbox that sits unwatched. Just be careful how you build it. A Microsoft 365 shared mailbox can’t send encrypted mail at all, so let it take documents in, and send anything sensitive from a named account or by the second channel.
Is Google Workspace or Microsoft 365 the better choice for a tax practice?
Both clear the floor this article describes, so the decision is rarely about the mail itself. It usually comes down to what your tax and ledger software already sits beside, and to the two constraints above. Shared mailboxes on Microsoft can’t send encrypted mail. Google’s hosted S/MIME sits on editions a small practice skips. Neither constraint is a reason to pick one over the other. Both are a reason to check your platform’s built-in encryption before your policy calls it the second channel.
We use a client portal. Does any of this still apply?
Yes, and your portal is doing its job. Mail keeps arriving alongside it. Clients reply to the notification instead of logging in. Prospects arrive by email before they’re set up on anything. The notice with a response window on it still lands in the mail. The portal is your second channel, which is exactly what this setup needs it to be. Everything that stays in email stays subject to the same authentication, retention and reporting.
Does a three-person firm really need a written security plan?
Yes, and it’s shorter than you think. The Safeguards Rule’s exception for firms holding information on fewer than five thousand consumers removes four requirements. The written program stays, and so do multi-factor authentication and encryption. The IRS publishes a template for exactly this size of practice in Publication 5708. For what to put in it at the scale you actually work at, a simple AI policy a small firm will actually use is the nearest thing.
What should we change before next busy season?
Four things, in the order of what each one buys you. Multi-factor authentication on every account, including the seasonal ones and the registrar. One documented second channel for anything with an identifying number on it, with the password sent a different way. A retention number written down. And one page naming who calls whom if the mailbox is compromised. Do it in a quiet month. AI email for accountants makes the case for why February is the worst possible time to change how your firm reads its mail.
Is it safe to connect an AI email client to a mailbox full of returns?
It’s the same class of decision as choosing your mail platform, and the rule treats it that way. Selecting a service provider capable of maintaining appropriate safeguards is itself a regulated act. What raises or lowers the risk is what the software is allowed to do next, more than the fact that a model read the mail. Is it safe to use AI with client financial data sorts it properly.
The short version
- Own the domain, register it to the firm, and put the registrar behind multi-factor authentication. Everything else is replaceable, and the domain is the one thing you keep.
- Named mailboxes for people, three role addresses at most, and multi-factor authentication on all of them. The rule says any individual, any information system, and that holds under five thousand consumers too.
- Email announces the document; a second channel carries it and a third carries the password. Check what your platform’s built-in encryption covers before your policy calls it that channel at the price a small firm pays.
- Publish sender authentication so your domain is hard to forge in February, and route strangers to one address where a phone call comes before an attachment.
- Write down a retention number and one page naming who calls whom. The IRS clock after a confirmed incident is the next business day, and the FTC’s is thirty days at five hundred consumers or more.
For the buying decision that comes after the setup, AI email for accountants maps the five categories a practice actually chooses between. For running the mailbox day to day once it’s built, there’s the firm inbox. Then there’s Point itself.