# Email security: protect the recovery inbox and control who can send as your domain Canonical: https://www.web3sec.news/blog/email-account-security-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Email Published: 2026-11-08 Updated: 2026-11-08 Separate mailbox compromise, domain spoofing and support impersonation into controls with observable tests. ### Diagram: Account recovery is part of the authority graph. Review login, sessions, service grants and recovery as connected control paths. ![Account login creates a session, which can grant connected services downstream authority. An independent recovery channel must be separately verified and must not depend entirely on the same compromised account. Session revocation alone may leave downstream grants active.](https://www.web3sec.news/diagrams/identity-recovery.svg) [Full-size SVG](https://www.web3sec.news/diagrams/identity-recovery.svg) · [PNG download](https://www.web3sec.news/diagrams/identity-recovery.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Inventory senders and high-impact mailboxes Assign the email administrator ownership of both mailbox security and domain authentication. Identify accounts used to recover the registrar, cloud provider, identity service, billing and publishing systems. Review delegates, shared mailboxes, forwarding destinations and applications with mailbox access. An employee may have no administrator role but still control recovery for a more important system through the messages they receive. Maintain a separate list of legitimate sending services: transactional email, marketing tools, support software, recruitment platforms and billing. Record the domain, DKIM selector, administrator and business purpose for each. Do not build a restrictive domain policy from memory. An undocumented sender is an operational problem to investigate, rather than a reason to leave every sender permanently permitted. ## Deploy authentication with a measured rollout NCSC and government email guidance describe SPF, DKIM and DMARC as complementary mechanisms for email-domain authentication. Our procedure is to observe legitimate traffic, correct alignment and move toward an enforcement policy after testing delivery. Publishing a policy is different from verifying that the services sending real customer messages satisfy it. Include subdomains and domains that never intentionally send mail in the review. Use controlled external inboxes to inspect authentication results from each sending service. Confirm that password resets and incident messages arrive without unexpected forwarding or broken links. Plan changes with the product owner, retain the previous DNS values and allow for caching. DMARC does not prove that a message is harmless, and a message from an actually compromised legitimate mailbox can still pass domain checks. ## Investigate persistence, not just the password Google’s compromise-recovery guidance explicitly includes reviewing forwarding and filters. Apply that principle to your provider: inspect mailbox delegates, rules, application grants, recovery methods, active sessions and recently registered authentication factors. Preserve the relevant audit history before changing configuration. A quiet rule that diverts invoices or suppresses security notifications can remain after the initial suspicious sign-in ends. Contain a confirmed compromise from a trusted environment, revoke sessions and unauthorized grants, restore approved settings and determine which messages were accessed or sent. Notify owners of downstream accounts whose recovery messages may have been visible. For payment-detail changes, use an existing verified phone or business channel; do not confirm the instruction by replying to the same potentially affected mailbox. ## Exercise a realistic failure and measure closure Use a test mailbox to add a harmless external forwarding rule and application grant. Confirm that monitoring records both, routes a useful notification to the right person and supports rapid removal. Separately send a controlled spoofing test for an organization-owned test domain. Check receiving behavior across several providers instead of concluding success from the existence of DNS records alone. Repeat the sender inventory review when a team adds a SaaS service or ends a vendor relationship. Remove obsolete selectors and authorizations deliberately, after proving they are unused. Maintain a recovery contact outside the primary email domain for a domain-wide outage. The completion evidence is a tested delivery path, a tested containment path and an owner who can explain each remaining exception. ## Controls to take away - Domain authentication and mailbox security solve different problems. - A recovery inbox belongs in the privileged-access inventory. - Test legitimate delivery before tightening domain enforcement. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Identify mailboxes that recover critical accounts. - [ ] Inventory delegates, rules and application access. - [ ] Test SPF, DKIM and DMARC on real sending paths. - [ ] Exercise forwarding-rule detection with a test mailbox. - [ ] Confirm downstream account review after mailbox compromise. ## Sources & further reading - [UK government: set up email services securely](https://www.gov.uk/guidance/set-up-government-email-services-securely) - [NCSC: email security and anti-spoofing](https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing) - [Google: secure a compromised account](https://support.google.com/accounts/answer/6294825) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)