Corporate email deliverability: the 2027 planning guide

What delivery actually means

An application accepting “send”, an SMTP server accepting a message, a receiving service delivering it and a person seeing it are different events. A successful SMTP handoff transfers responsibility to the receiving server; it does not attest to inbox placement or reading. [IETF RFC 5321: SMTP]

Microsoft also documents that a trace can show “Delivered” for spam-filtered mail routed to Junk or quarantine. Start with the event you can prove, then investigate the next boundary. [Microsoft: message trace FAQ]

The GURU Protect triangle

Trust asks whether the identity and sending path are credible. Reputation asks what the receiver has learned about the sending stream. Engagement asks whether recipients want and use the messages. Investigate all three, but do not treat them as three independent switches or a formula for guaranteed placement.

The triangle is our diagnostic model. Mailbox providers apply their own filtering policies. A first-contact or transactional message has no necessary history of recipient interaction. Authentication alone is not an endorsement of message safety, and receivers retain their own filtering decisions. [IETF RFC 9989: DMARC]

Trust: start with the real sending estate

Document each system that sends as your organisation: employee mail, finance, CRM, support, recruitment and application notifications. Our recommended inventory records its business owner, visible From domain, envelope sender, signing domain, provider, purpose and change owner. Check messages from each service; a DNS record by itself cannot demonstrate how every message is sent.

Use the separate SPF, DKIM and DMARC guides to distinguish authorisation, signing and alignment. Review forwarding separately: ARC can preserve authentication history, but it is not an automatic acceptance instruction.

A material standards update for this edition is RFC 9989, which replaces the earlier core DMARC specification. Aggregate reporting is described in RFC 9990. Check provider implementation as well as the standard before changing production policy. [IETF RFC 9990: DMARC aggregate reporting]

Reputation: diagnose by stream and receiver

A single test score is not a universal view of reputation. Google’s Postmaster Tools exposes Google-specific measures and can omit low-volume data. Its user-reported spam figure can also look low when much of the mail already goes to spam. Read the denominator and coverage before presenting a percentage as success. [Google: Postmaster Tools dashboards]

Our investigation separates user email, transactional traffic and subscribed campaigns, then compares affected recipients, dates and sending routes. Look for changes in volume, audience, application configuration or infrastructure. Record the hypothesis and test one controlled change at a time. See sender reputation.

Engagement: relevance, with honest measurement

An open-tracking event is not proof of a human reading. Apple’s privacy controls can prevent senders from learning whether a message was opened and can privately fetch remote content. Treat open rates cautiously. [Apple: Mail Privacy Protection]

Our recommended measurement combines the purpose of the message with the evidence available: account activation for a welcome email, a real response to a conversation, or an agreed recipient-side check for an incident. Do not apply a newsletter re-engagement rule blindly to an employee’s mailbox or a necessary service notification. Read email engagement and measurement.

Provider requirements are a baseline

[Google: email sender guidelines] [Yahoo: sender requirements] [Microsoft: high-volume sender requirements]

These consumer-service rules are not a complete description of every corporate Microsoft 365 or Google Workspace tenant. Recipient organisations can apply additional security and mail-flow policies. Passing a sender checklist is not a promise of delivery.

A corporate investigation that produces an answer

• Record a small set of affected and unaffected examples: sender, recipient, UTC timestamp, message ID and exact SMTP response.
• Establish the last confirmed handoff. Request the next provider’s evidence through the agreed incident owner.
• Check real-message authentication and the systems that created or modified the message.
• Compare affected destination groups and business streams. Avoid treating all recipient systems as one population.
• Agree a change, test criteria, approval and rollback before implementation.
• Verify the result at the relevant receiving boundary, document remaining uncertainty and monitor subsequent messages.

Recipient-side records may be needed to complete an investigation. See message tracing and our corporate IT arrangements.

What to avoid

• Treating DMARC pass, SMTP acceptance or a single seed test as proof that all recipients saw the message.
• Changing several sending controls together and losing the ability to explain what changed the outcome.
• Using an invented universal “engagement score” or claiming to know unpublished filter weights.
• Weakening inbound security to solve an outbound delivery complaint without examining the actual route.
• Promising a fixed recovery period without evidence from the affected provider.

Preparing for 2027

This is a planning edition researched on 18 October 2026. It does not claim knowledge of unpublished 2027 filtering policies. Before deployment, recheck provider requirements, standards status and product documentation. Maintain a review owner for sending services, authentication, complaints and operational evidence.

We can assess the estate through Email Review, investigate a live delivery issue through Email Resolution, implement agreed changes through Email Projects and maintain the controls through Managed Email.