Useful for
Introduction
Email is part of the company's external credibility and internal control environment. It is how the company communicates with customers, suppliers, regulators and staff. Weak email authentication increases impersonation risk and makes later security reviews harder than they need to be.
Email authentication
Corporate email should be configured deliberately before the company starts using the domain for customers, suppliers or prospective clients. At minimum, the company should understand and configure:
- SPF, to define which services are allowed to send mail for the domain.
- DKIM, to cryptographically sign email from approved senders.
- DMARC, to tell receiving mail systems how to treat messages that fail authentication.
- DMARC reporting, so failed authentication and spoofing attempts can be monitored.
The early DMARC policy may be cautious while the company learns which systems send mail, but there should still be a clear path from monitoring to enforcement. Leaving DMARC permanently weak makes it easier for attackers to impersonate the company.
External senders
Every tool that sends email on behalf of the company becomes part of the trust boundary. This can include the website, CRM, ticketing system, marketing platform, payment provider and support tools.
The company should record:
- approved email-sending services
- DNS records required by each service
- who owns the service
- whether the service can send as the company domain
- whether SPF/DKIM/DMARC alignment is working
- how the service would be removed if it is no longer trusted
How this evolves as the company grows
- At company setup, configure SPF, DKIM and DMARC early so business communication starts from a trustworthy baseline.
- Before Pilot, external senders such as website forms, support tools or transactional mail need to be included in the email model.
- At Production, email authentication affects customer trust, support, billing, breach communication and deliverability.
- As the company scales, review third-party senders and DMARC reporting so new tools do not quietly weaken the domain.
What an agent should look for
- Are SPF, DKIM and DMARC configured?
- Which external senders are authorised?
- Do support, billing and transactional systems affect email trust?
What good looks like
The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.
How Brokenhouse helps
Turn this into a practical plan.
I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.
Talk through your situationNext guidance
Related decisions to work through
Agent-led consultancy should amplify judgement
Agents should not replace expert judgement. They should help capture, structure, challenge, and reuse it.
Azure Dev Platform Modernisation
Describe the organisation, product, team shape, delivery model, and operating constraints.
Agentic software delivery governance
Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not be part of the customer-facing service, but they can still create risk because they may read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.