Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Confirm the provider instructions before implementation
The SMTP.com setup portion of this guide remains on hold. Current readable first-party configuration instructions were not recovered during this research. The known provider authentication and DKIM help links failed through the web retrieval tool; a separate read-only HTTP fetch returned a JavaScript loading shell rather than the article. This is a documentation-retrieval limit, not evidence that SMTP.com is unavailable or that a feature is unsupported.
Do not publish DNS records from this draft. It deliberately supplies no SMTP.com include, selector, public key, CNAME target or activation sequence. Third-party descriptions disagree about the signing method and cannot establish what the current account requires. The safe next step is for an authorized administrator to obtain the current instructions and issued values from the actual account or provider support.
The sections below are a complete conditional verification plan for that handoff. They preserve the original requirement to authenticate the actual SMTP.com route, including SPF, DKIM, envelope identity and DMARC. They do not replace the missing setup evidence with a generic assertion that authentication is already configured.
Define the exact application and sender scope
List each application or integration that hands messages to SMTP.com and record how it submits mail. Use separate rows for routes with different credentials, channels, accounts, From domains or message templates. Record identifiers needed to find the configuration, but do not copy secret values into the worksheet.
Include password resets, order confirmations, operational alerts and other important message classes only where they actually use this route. Ask the application owner to identify any fallback delivery path. If an application quietly switches to another relay during a failure, the fallback needs its own authentication evidence rather than being counted as an SMTP.com success.
Identify the owner of DNS, the owner of the application and the person responsible for domain security policy. Agree on a harmless test and a controlled recipient mailbox. Before changing production, record which messages can be paused and which need an already tested recovery path. This planning is especially important for time-sensitive transactional messages, but no particular workload is assumed here.
Obtain an implementation packet from the account
Request the exact domain-verification method, DNS owner names, record types, values, TTL guidance and account-side activation requirements. Ask whether the account uses a generated TXT key, a delegated CNAME or another supported method. The answer must be tied to the account and route under review, not to a sample screenshot from another customer.
For SPF, request the domain on which authorization is expected and the supported authorization mechanism. For DKIM, request the intended signing domain and selector, who controls the private key and how signing becomes active. For the envelope identity, ask whether it is provider-managed, inherited from the submission or configurable, and which restrictions apply. Record an explicit unknown where the provider has not answered.
If the provider requires a separate activation step, keep it as a distinct acceptance item. Publishing a public key does not cause a relay to sign messages automatically. Conversely, a relay can sign using a different domain even when the desired key is present in DNS. Configuration and observed behavior must agree before the route is approved.
Review DNS changes as a bounded change
Prepare a before-and-after record list only after the current packet is available. Identify the authoritative DNS provider and confirm how its editor handles the zone suffix. Verify that every proposed owner is available for the intended use. Do not overwrite an existing selector or a hostname used by another application without an approved migration plan.
Preserve other authorized senders in the single SPF policy at the relevant owner. Two separate SPF policies are invalid. Evaluate nested DNS-querying terms against the protocol limit rather than counting only top-level includes. RFC 7208, sections 4.5 and 4.6.4.
Keep private signing keys and credentials out of DNS, tickets and screenshots. If a supported procedure involves handling a private key, use the organization's approved secret-management process and authorization controls. Record the key custodian and rotation responsibility without putting the key itself in the implementation evidence.
Confirm the identity emitted by the tested route
Once the provider's setup and account-side activation are complete, send a harmless message through the real application route. Save its UTC time, application identifier, Message-ID and any provider event identifier. A successful application API response or SMTP submission establishes only that part of the path; it does not establish receiver-side authentication or inbox placement.
Obtain the original headers from the receiving mailbox. Record the visible From, Return-Path, trusted SPF domain and result, and every DKIM signing domain and selector. DKIM's d and s values identify the public-key lookup used for that signature. RFC 6376, sections 3.5 and 6.1.
Evaluate alignment against the actual visible From. A passing provider-domain signature may be useful authentication evidence without aligning to the organization's domain. The DMARC result requires at least one passing aligned mechanism. Distinguish the raw SPF or DKIM outcome from the alignment comparison and the receiver's final disposition. RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
Investigate mismatches before changing policy
If no message reaches the receiver, start with the application submission result and provider event history available to the administrator. Capture the actual rejection or delay information. A connection or authorization problem should not be diagnosed as a DNS-alignment problem without evidence.
If the observed From differs from the approved address, inspect application overrides and the selected route. If DKIM is absent or uses an unexpected domain, compare the provider's confirmed signing configuration with the exact tested message. If DKIM fails, inspect the observed selector and DNS response, then consider whether content or signed headers changed in transit.
If SPF passes for a different domain, record that result accurately. Do not declare custom envelope support merely because a plugin has a field labelled Return-Path. Confirm what the provider actually emits. If a required strict alignment outcome cannot be achieved, leave the requirement unresolved and ask for supported options rather than weakening policy as an undocumented workaround.
Build a repeatable release record
Use the SMTP.com evidence request and verification worksheet. It separates missing provider instructions from implementation evidence, so a reviewer can see what is researched, issued, configured and tested. Include one received-message row per material route and a named reviewer for every hold.
Release requires current provider instructions, approved DNS changes, any required account activation, and trusted receiver evidence for the exact route. Retest after a change of application, sending domain, account, signing key or DNS host. Maintain an approved recovery procedure and avoid deleting old keys while messages signed with them may still be in transit.
Fictional diagnostic case involving an unconfirmed signing method
Fictional example only: Juniper Tools finds a CNAME recipe in an old integration note and a TXT recipe in a newer plugin tutorial. The team publishes neither. It obtains the current account-issued record set and activation instructions, then tests the application. The receiver evidence determines the active signing domain rather than the age or popularity of either tutorial. No Juniper account, provider response, DNS record or message was inspected.
Original scope is not yet accepted
This is an unpublished conditional draft. Current first-party SMTP.com setup text, account-issued records, supported envelope behavior and live received-message evidence remain missing. Original-scope acceptance, independent technical review, visual review and human SME approval remain pending. No provider-specific setup claim, DNS edit, message send or publication is implied.
Retained conditional verification worksheet. No filled account or received-message observations are supplied.