The problem
The assistant signs people in with a six-digit code emailed to them, so there are no passwords to manage. Those codes are sent through our email service, but from a transitional address that has no connection to bookkeepers.org.uk. Because the sending domain and the recipient domain don't match, Microsoft 365 treats the code emails as untrusted.
Our delivery logs show every code was accepted by ICB's mail servers, yet some of the team report the codes in neither their inbox nor their Junk folder. That pattern points at Microsoft 365's third destination: the tenant quarantine, where Defender holds messages it scores as likely phishing. A code email from an unrelated external domain fits that profile exactly. Part 1 has two halves: a quick check in Defender to confirm where the codes are going (and release any held ones), and the DNS change that fixes the cause properly.
First: two minutes in Defender to confirm it
- In the Microsoft Defender portal (
security.microsoft.com), go to Email & collaboration → Review → Quarantine and filter by senderassistant@send.tenentnet.com. If the sign-in codes are sitting there, release them; that unblocks the team today, ahead of the DNS change. - For a definitive record, run a message trace (Exchange admin centre → Mail flow → Message trace) on the same sender over the last two weeks. It shows exactly where each code went: inbox, Junk, quarantine, or filtered by a rule. A screenshot or export of that result back to me would be really helpful.
- Optional interim measure: add
assistant@send.tenentnet.comto the allowed senders in the anti-spam policy so codes flow while the DNS records below propagate. Once the assistant switches to the new sending address, that entry can be removed.
The fix
Authenticate a dedicated sending subdomain, send.bookkeepers.org.uk, so the codes are sent from ICB's own domain with valid SPF and DKIM signatures. Microsoft 365 then recognises them as legitimate and delivers them to the inbox. This is the standard, recommended way to send this kind of automated email for a domain.
It also serves the exemptions work in Part 3: the new exemptions application process will email applicants their personal application links, and those emails need to come from an authenticated ICB address to be delivered reliably. One set of records covers both.
This does not affect ICB's normal email. Every record below sits on the send. subdomain only. None of them touch the mail routing (the MX record) for bookkeepers.org.uk itself, so the team's existing mailboxes send and receive exactly as before. This adds a sending subdomain; it changes nothing about the parent domain.
The three records
Add these to the bookkeepers.org.uk DNS zone. Click any value to copy it exactly.
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDtkjlPkupVHLb1iwVw+iV2m254sWbn91+its7KuLOKWdjJHv+k1t+/pChlFyTxdJGcmIBHHauXKI+5/LhyhZkKNv7Cc/YDNpYuUzHRp+tV+SD+w5IY39PA+fG+Cx8gQlUaGTFVVLFJ8+myKUmKXatB17jCwVhO2yhAgh3xwPUcsQIDAQAB
feedback-smtp.eu-west-1.amazonses.com
v=spf1 include:amazonses.com ~all
Entering the host names
The hosts are given in two forms above. If your DNS panel expects the host relative to the bookkeepers.org.uk zone (most do), use the shorter Relative form. If it expects the full name, use the Full form.
The send.send on records 2 and 3 is correct, not a typo: it is the return-path subdomain of the send sending subdomain.
Or, if you'd rather I did it
If it is easier, give me access to the bookkeepers.org.uk DNS zone (or the relevant panel) and I will add these myself and confirm back to you. Whichever is less work for you.
Removing email from sign-in altogether
The DNS change fixes code delivery, but there is a better long-term answer for staff: a "Sign in with Microsoft" button, so everyone signs in to the assistant with the ICB account they already use every day. No code email, nothing to fish out of a folder, and anyone with a bookkeepers.org.uk account can be admitted without me setting them up individually. The emailed codes stay available as a fallback.
This app handles sign-in only. It confirms who is signing in (their name and ICB email address) and nothing else. It has no access to mailboxes, files, or anything in the tenant beyond that identity check.
Because user consent is disabled tenant-wide (correctly), this needs a small app registration with admin consent. Following the same naming convention as before:
- In Entra admin centre: App registrations → New registration. Name it as below, leave account type as "Accounts in this organizational directory only".
ICB_Agent-02
- Under Redirect URI, choose platform Web and paste:
https://acuzipngzwjktfgtpxzi.supabase.co/auth/v1/callback
This is the assistant's sign-in service endpoint. Register, then continue below. - On the new app: Certificates & secrets → New client secret. Description "Assistant sign-in", expiry 24 months. Copy the secret Value (it is only shown once).
- On API permissions, the default delegated
User.Readis all it needs. Click "Grant admin consent for ICB". This is the step only a Global Admin can do. - Send me the Application (client) ID (from the Overview page) plus the secret Value from step 3 — a Teams message to me is fine; delete it once I confirm receipt.
I wire it in from my side and the "Sign in with Microsoft" button appears for the whole team.
The exemptions mailbox
As Anthony and Nathan will have mentioned (Agatha is in the loop), the exemptions work agreed last week has two pieces: a new structured application journey, and a working surface over the current backlog. Both need sight of the exemptions@bookkeepers.org.uk mailbox, mirroring the setup we did for professional.standards@. Two grants:
3a — My access to the mailbox
Give jordan.copeland@bookkeepers.org.uk Full Access (read and manage) on exemptions@bookkeepers.org.uk — Exchange admin centre → Recipients → the mailbox → Delegation → Read and manage, or in PowerShell:
Add-MailboxPermission `
-Identity exemptions@bookkeepers.org.uk `
-User jordan.copeland@bookkeepers.org.uk `
-AccessRights FullAccess `
-InheritanceType All
3b — Widen the assistant's mailbox scope
When we set up ICB_Agent-01 you locked its reach to exactly two mailboxes with a management scope — the restriction that means it cannot read anything else in the tenant. That restriction stays; we re-issue it with the exemptions mailbox added as a third:
Set-ManagementScope `
-Identity "ICB_Agent-01 Mailboxes" `
-RecipientRestrictionFilter "PrimarySmtpAddress -eq 'jordan.copeland@bookkeepers.org.uk' -or PrimarySmtpAddress -eq 'professional.standards@bookkeepers.org.uk' -or PrimarySmtpAddress -eq 'exemptions@bookkeepers.org.uk'"
Then confirm it took effect (should return Granted):
Test-ServicePrincipalAuthorization `
-Resource exemptions@bookkeepers.org.uk `
-Identity a65ce8ca-68c0-4da2-8909-53b12402f712
Connect-ExchangeOnline). If exemptions@ is an alias on another mailbox rather than its own shared mailbox, let me know and I'll adjust the filter.What happens next
Part 1: once the records are live, I verify them from my side (DNS can take from a few minutes to a couple of hours to propagate), then switch the assistant to send from send.bookkeepers.org.uk. Sign-in codes and, later, exemptions applicant emails then arrive properly. Part 2: as soon as the app details reach me, I wire in the "Sign in with Microsoft" button. Part 3: with the mailbox grants in, the exemptions backlog surface can start reading real correspondence.
None of the three depend on each other, so do them in whatever order suits. Please let me know as each lands, or send me DNS access if you would prefer I handle Part 1 myself.
Jordan
Practice Standards Assistant · 7 July 2026