Define the service and product route being compared
Research on major sending services should compare observable configuration and documented behavior, not assume that a vendor brand corresponds to one uniform email path. A provider can offer transactional APIs, SMTP submission, marketing campaigns, default domains and customer-authenticated domains with different behavior. The study must identify the exact product, route, account context and observation source before classifying a service's authentication support.
This manuscript proposes a documentary and evidence-based method. It does not rank providers, query customer domains, create accounts or send test messages. The word major needs an explicit selection rule, such as a declared product list or independently supported usage criterion. Without a representative market dataset, the study should describe a selected-service comparison rather than imply complete market coverage.
Separate documented capability from observed configuration
A provider's official setup guide can establish what it instructs customers to configure. It does not prove that every account has enabled the feature or that a particular message used it. Conversely, a sample from one account cannot establish every supported product route. Use separate columns for documented capability, account configuration evidence and received-message evidence, with each source's date and scope retained.
The retained Alchemer setup guide illustrates this distinction. It separates its own-server DKIM/SPF integration from custom SMTP and limits the documented integration to particular actions and campaigns. Its Campaign Test Link does not exercise the custom DKIM/SPF route. A comparison that ignores those route details could mistake a test-path result for the provider's general capability.
Preserve account-specific DNS values
Custom-domain setup often supplies account- or domain-specific public values. A study should not invent a universal selector, include target or CNAME pattern from a single example. Retain the current official instruction and identify which fields require authorized account evidence. Do not request or publish private signing keys, API secrets or credentials; the research question usually concerns public configuration and observable identities.
RFC 6376 defines DKIM signing-domain and selector concepts. RFC 7208 defines SPF evaluation for the relevant SMTP identity. These standards support interpreting supplied values, but they do not tell the researcher which values a particular provider assigns to a customer. Missing account-specific evidence must remain a gap.
Distinguish direct service support from delegated infrastructure
A product may use another provider's delivery infrastructure while exposing its own configuration workflow. That relationship should be supported by current first-party evidence before it is asserted. Even when supported, the infrastructure vendor's general documentation does not automatically describe the application's exact sender identity, region, account settings or verification process.
The retained Blackbaud Development Agent guide illustrates a product-specific combination of required forwarding and DKIM, conditional SPF guidance and a separate test sequence. A study should preserve that scope rather than summarize the entire Blackbaud portfolio from this one route. The example is documentary; no Blackbaud account or message was inspected.
Record default and custom identity behavior separately
For each route, identify the documented default From behavior, supported custom-domain options and any evidence about envelope and signing identities. Keep display name, visible From domain, MAIL FROM domain and DKIM d value distinct. A branded display name does not establish domain alignment. A shared provider identity may authenticate correctly without aligning with a customer's intended visible domain.
RFC 9989 defines the alignment relationship. The comparison should ask which path can provide aligned authentication under the supported configuration, not merely whether the provider mentions SPF or DKIM. If no trusted received sample exists, state that capability is documented but operational alignment is unverified. Do not fill the table with guessed pass results.
Avoid comparing unlike verification signals
Providers can use different setup checks: DNS presence, generated test messages, domain ownership checks or route-specific connection tests. Those signals have different coverage. A green verified label should be described according to the provider's documentation, not normalized into a universal proof that every message will authenticate and reach an inbox. Preserve any test side effects and authorization requirements.
Twilio SendGrid's event reference defines processed and delivered events at specific handling stages; delivered concerns the receiving server, not human reading. If delivery telemetry is included in a comparison, retain those semantics and avoid treating one provider's event label as equivalent to another's without evidence. This study has no actual events or delivery outcomes.
Version the source collection and handle blocked evidence
Retain exact official URLs, capture dates, snapshot hashes, product versions where available and supporting sections. Documentation can change while a study is being written. Record whether a claim comes from a current retrieved page, a clearly dated retained capture or an unverified lead. A search snippet is useful for discovery but should not replace a readable primary source for implementation claims.
If a source is denied or returns an unavailable shell, log the failure and hold the unsupported scope. Do not bypass the restriction through another route or substitute a third-party tutorial while labeling the result first-party verified. Providers lacking sufficient first-party support remain unresolved exclusions. Do not convert missing evidence into observed capabilities or count those providers as completed comparisons.
A service-comparison worksheet
Create columns for selection rationale, vendor, product, route, region where relevant, account context, official source, source date and supported setup. Add public-value provenance, verification method, documented limitations, observed From/envelope/signing identities and trusted receiver result where actually available. Distinguish not supported from not evidenced; absence of a readable document is not proof that a feature does not exist.
The dataset should include an error and exclusion log and a stable rule for counting products. One vendor with several distinct routes should not be counted inconsistently across columns or periods. A reviewer should be able to reconstruct every classification from retained evidence without accessing secrets. No such populated comparison dataset or account fixture was produced for this draft.
Fictional diagnosis: a default test message becomes a provider verdict
A fictional researcher sends through a product's preview or test path and sees a provider-owned identity. The draft conclusion says the service cannot support customer-domain authentication. The review identifies missing scope: the test path may differ from the documented custom-domain route, and the account's configuration was not established. The result supports only the tested path, not a universal capability claim.
The proposed correction is to retain the narrow observation, review current route documentation and leave unsupported comparisons open. A later authorized test could evaluate the intended configuration with a trusted received-message table. This scenario is fictional; no message was sent and no provider was assigned a score. It demonstrates why observable configuration must remain tied to the exact product route.
Release status
The catalogue requires a versioned dataset, query method and error/exclusion log that another analyst can reproduce. Those original artifacts remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a comparative research design, not market rankings, executed accounts or a guarantee of service behavior.