1. Scope agreed
Agreed with the managing partner on 13 July 2026.
- One domain:
samplefirm.example. - Main mail provider: Microsoft 365.
- Three other services that send as the firm: a case management system, a billing service and a newsletter platform.
- Not in scope: other domains, MTA-STS and TLS reporting.
2. People
| Role | Part in the project |
|---|---|
| Managing partner | Agrees the scope and each policy step, and accepts the record. |
| Practice manager | Confirms which services send email as the firm. |
| IT provider | Makes every change in DNS and in Microsoft 365. |
| mailcounsel | Brings the sender inventory, the tests, the report review and this record. |
3. Settings before and after
| Record | Before, 14 July 2026 | After, 12 August 2026 |
|---|---|---|
| SPF | v=spf1 include:spf.protection.outlook.com include:spf.billing.example include:spf.oldnewsletter.example ~all | v=spf1 include:spf.protection.outlook.com include:spf.billing.example ~all |
| DKIM | Microsoft 365 signed with the tenant's onmicrosoft.com domain, which does not align with samplefirm.example. The case management system and the newsletter platform signed with their own domains. | Microsoft 365 (selector1 and selector2), the case management system and the newsletter platform all sign as samplefirm.example. The billing service already did. |
| DMARC | v=DMARC1; p=none | v=DMARC1; p=reject; rua=mailto:[email protected] |
4. Services confirmed in this project
Each was tested with a real message from the firm’s own account. The result is what the receiving mailbox recorded in the message’s Authentication-Results header.
| Service | Sends | Passes DMARC through | Tested | Result |
|---|---|---|---|---|
| Microsoft 365 | Staff email | SPF and DKIM | 15 July, to Gmail and Outlook.com mailboxes | dmarc=pass |
| Case management system | Client portal notices | DKIM, from 15 July | 16 July | dmarc=pass |
| Billing service | Invoices and month-end statements | SPF and DKIM | 16 July, and the 31 July statement run in the reports | dmarc=pass |
| Newsletter platform | Updates to clients | DKIM, from 22 July | 23 July | dmarc=pass |
5. Changes, each with a way back
| When | Change | Made by | Way back |
|---|---|---|---|
| 15 July, session 1 | Published the Microsoft 365 DKIM records and switched signing on for samplefirm.example. | IT provider | Switch signing off in Microsoft 365. |
| 15 July, session 1 | Published the DKIM records for the case management system. | IT provider | Remove the two records. |
| 15 July, session 1 | Removed the SPF entry for a newsletter platform the firm no longer uses, once the practice manager had confirmed it. | IT provider | Restore the earlier SPF record in section 3. |
| 15 July, session 1 | Added DMARC reporting to [email protected]. Policy left at p=none. | IT provider | v=DMARC1; p=none |
| 22 July | Set up domain authentication in the newsletter platform. | Practice manager, with the IT provider | Remove the platform's records. |
| 29 July | Sent the office scanner's email through Microsoft 365 instead of directly. | IT provider | Restore the scanner's earlier mail setting. |
| 5 August, session 2 | Moved the DMARC policy to p=quarantine. | IT provider | v=DMARC1; p=none; rua=mailto:[email protected] |
| 12 August | Moved the DMARC policy to p=reject, in the agreed change window. | IT provider | v=DMARC1; p=quarantine; rua=mailto:[email protected] |
6. What the reports showed
Aggregate reports from 15 July to 11 August, from the receivers that send them. From 23 July every message from the four confirmed services passed DMARC. Two other sources appeared, and both were explained before the policy changed:
- An office scanner emailing scans directly, failing SPF and DKIM. The IT provider identified it on 28 July and sent it through Microsoft 365 from 29 July.
- Copies forwarded by recipients’ own mail systems, failing SPF and passing DKIM. Expected: forwarding breaks SPF, and DKIM kept these messages passing.
7. Policy decision
p=quarantine on 5 August, in the second session. Three weeks of reports, including the month-end statement run on 31 July, showed every confirmed service passing and no source left unexplained.
p=reject on 12 August, in the agreed change window. Seven days at quarantine brought no failures from confirmed services. The managing partner agreed the step, the IT provider published it, and the change was confirmed on two public resolvers.
No pct tag at any step. RFC 9989, published in May 2026, removed it, so each step changes the whole policy and gets its own observation window. The test flag t=y was not used either: receivers that do not support it would apply the stronger policy anyway.
8. Open items
| Item | Owner | When |
|---|---|---|
| A recruitment platform starts sending as the firm in October. It needs DKIM for samplefirm.example before its first message. | Practice manager, with the IT provider | Before it goes live |
| No subdomain sends email, and subdomains follow the reject policy. A new one is checked before anything sends from it. | IT provider | When one is added |
| MTA-STS and TLS reporting were discussed and left out of this scope. | Managing partner | At the next review |
9. If legitimate email is rejected
The IT provider restores the previous DMARC record, v=DMARC1; p=quarantine; rua=mailto:[email protected], listed in section 5. The record’s time to live is 3,600 seconds, so most receivers see the change within an hour. Messages already rejected are not recovered; they have to be sent again.
10. What this record does not show
- Every system the firm might use. It lists the services confirmed in this project.
- What happens at receivers that send no aggregate reports.
- Compliance. It records the work done; it is not a certificate, and not a statement that the firm meets a regulator's or an insurer's requirements.
- Protection from every threat. DMARC does not stop a compromised mailbox, or a lookalike domain registered by someone else.
Acceptance
Accepted by the managing partner on 14 August 2026, against this record — not against a score from any checker.