A startup’s team email works, but password-reset messages from the product arrive inconsistently. A separate marketing platform uses the same visible domain, while a billing provider sends receipts through another configuration.
The company may think it has one email setup. Operationally, it has several sending systems.
A reliable authentication review begins by identifying each of them and verifying actual messages rather than assuming that one successful configuration covers the entire domain.
Build an inventory of senders
List every service authorized to send: employee mail, application notifications, billing, support, and subscribed marketing messages.
For each, record the visible From address, sending provider, technical owner, and expected message type.
This inventory matters because Google’s sender guidance recommends authenticating sending domains and including legitimate third-party senders in the relevant setup. Using an email service provider does not remove the need to verify the configuration.
Start with the messages essential to product use. A beautifully designed onboarding flow is incomplete if users cannot reliably receive the email needed to continue.
Understand the authentication relationship
SPF, DKIM, and DMARC serve related roles.
SPF identifies authorized sending infrastructure for the domain checked by SPF. DKIM provides a domain-associated signature. DMARC connects authentication with the domain presented in the visible From address through alignment and a published policy.
Google’s FAQ explains that, for direct messages subject to its alignment requirements, either the SPF or DKIM organizational domain must align with the From domain. Passing an authentication check for an unrelated domain is not the same as establishing that alignment.
For a startup using several providers, this is an important handoff detail. A dashboard saying “verified” should be followed by inspection of a real message sent through the production route.
Test a representative message from each system
Send controlled test messages to accounts owned by the team. Inspect the received message’s authentication results and confirm the visible sender.
Use the real application path where possible. A provider’s demonstration message may not exercise the same configuration as a password reset triggered by the product.
Record the result for each service. If one fails, the inventory identifies the responsible owner and the affected message type.
Avoid copying DNS examples from another organization. Provider-specific instructions and the domain’s existing configuration need to be reconciled deliberately.
Treat delivery as a broader responsibility
Authentication supports delivery, but it does not guarantee inbox placement.
Google’s guidance also addresses unwanted mail, message formatting, infrastructure, and unsubscribe behavior for relevant traffic. A startup should therefore separate authentication checks from the question of whether recipients actually expect the messages.
Product notifications and promotional campaigns also have different operational purposes. Keep those purposes clear when designing sender identities and reviewing performance.
A rise in complaints should trigger investigation even if authentication continues to pass.
Maintain the inventory
When adding a new platform, include authentication verification in its launch checklist. When retiring a service, review its authorization as part of the shutdown.
Give the inventory an owner and a review date. Otherwise, a configuration that was correct at launch can become incomplete as the company adds tools.
The strongest practical improvement is simple: know which systems send on the domain’s behalf, verify each route, and keep the evidence connected to the person responsible for maintaining it.