For an already provisioned mySMTP dedicated server, use the domain-specific DNS instructions supplied for your account, publish the full public DKIM TXT record and reconcile SPF, then check DNS verifications in the dedicated dashboard. Have mySMTP confirm the setup before sending. A green DNS status is not proof that your application’s actual messages have an aligned signature.
This guide covers the current dedicated SMTP relay route. It does not configure a historical shared-IP product, purchase a server, deploy hosted MailWizz, enable a future API or replace another application’s native authentication. The current FAQ describes dedicated IPs for its plans; the exact assigned server and existing entitlement still govern your configuration. Current mySMTP FAQ.
No customer account access, DNS changes, support request, test send or receiver-header test was performed.
Confirm the existing account and authorized sending route
Identify the provisioned dedicated server, account administrator, intended sending application, visible From address and domain owner. Keep the existing approved application route intact while planning the change. A server hostname, SMTP credential or DNS record from a different account is not interchangeable with yours.
The account owner can select the relevant server in Server Fleet at the dedicated dashboard. A subuser has a restricted view. If a needed control is unavailable, ask the authorized owner or mySMTP to confirm access; do not expand privileges or create credentials merely to match a tutorial. The client-account login and application SMTP credentials can differ. Dedicated dashboard roles and server selection.
Confirm that the organization has approved this application’s transmission of mail through mySMTP. Changing providers or sender identities can change data handling and operational behavior. Do not redirect production traffic, enable a Bcc archive, alter IP whitelisting, modify security controls or purchase an upgrade as a casual authentication fix.
Locate the authoritative DNS operator, not simply the registrar. Save existing SPF, DMARC, DKIM selectors, aliases and delegated namespaces. Agree which exact owners and values may change and preserve other services’ legitimate dependencies.
Obtain the account-issued public records
mySMTP supplies setup instructions and credentials during provisioning and helps verify configuration before sending. For this existing-account workflow, retrieve the current domain packet from the authorized administrator or confirm it with mySMTP through an approved channel. Do not place SMTP passwords or private signing keys in DNS, support screenshots or a shared document. Provisioning and pre-send assistance.
The current native documentation describes SPF TXT, DKIM TXT and DMARC TXT. It shows the SPF authorization include:_spf.mysmtp.com and a DKIM owner example mysmtp._domainkey, but the displayed DKIM value is only a placeholder for a generated 2048-bit key. The full public value must come from mySMTP, not from that example or a third-party key generator. Confirm the exact current selector, owner and complete TXT tags for your domain. mySMTP DNS explanation, provider-issued DKIM record.
Do not assume the same selector applies to every server, a second selector exists, or a legacy shared-service include is equivalent. If the packet differs from the public example, resolve the account-specific requirement with mySMTP before publishing. Do not silently omit a required row.
Map TXT owners to the actual DNS authority
Keep a record’s owner separate from its TXT content. For an illustrative account-issued owner mysmtp._domainkey.example.com, a DNS editor managing example.com may need the relative host mysmtp._domainkey. The example is not an instruction to overwrite a working selector.
For mysmtp._domainkey.mail.example.com, the relative owner may be mysmtp._domainkey.mail in the parent zone or mysmtp._domainkey in a separately delegated mail.example.com zone. If _domainkey.mail.example.com is separately delegated, use its actual authority. Confirm the editor’s full-name handling so it does not append the suffix twice. Preserve existing NS delegations rather than removing them to force a record into the parent zone. DNS authority and delegation.
Publish the complete issued public DKIM TXT value, including its tags. A DNS editor may display one logical TXT value as multiple quoted character strings; preserve the concatenated value without inserting spaces into the key. Never publish the private key. TXT records for unrelated purposes can coexist, but that does not permit duplicate SPF policies or conflicting DKIM key records at the same selector.
If the proposed TXT owner already contains a CNAME, stop: ordinary TXT and CNAME cannot coexist there. Do not delete a working alias or repoint another sender’s selector without a supported migration plan. This native TXT procedure does not require converting the key to CNAME, changing proxy settings or moving inbound MX. DNS record representation.
Merge SPF rather than replace other senders
For the documented current native route, mySMTP gives include:_spf.mysmtp.com. At the applicable SPF owner, reconcile that authorization into the single approved v=spf1 TXT policy. Preserve legitimate existing senders and the terminal qualifier; do not paste a second policy or replace an established apex record with a one-provider example. Current native SPF instruction.
Only where no SPF policy exists at the intended owner and the mail administrator approves mySMTP as the sole authorization, the documented starting example is v=spf1 include:_spf.mysmtp.com ~all. It is not a universal replacement policy or a historical shared-product recipe.
SPF evaluates the actual SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From. Publishing SPF at a brand domain does not prove the application used that domain as its envelope sender. The reviewed sources do not establish a universal mySMTP Return-Path or custom-envelope control. Check the actual message rather than inventing one. SPF policy is not inherited from a parent domain. SPF identities and evaluation.
Keep within ten evaluated DNS-dependent terms, including nested mechanisms, not ten top-level includes. Put the authorized addition before the terminal all; mechanisms after all do not provide the intended authorization, and redirect is ignored when all is present. Validate syntax and the resulting lookup budget. No qualifier guarantees how every receiving service will deliver or reject the message.
Preserve DMARC enforcement and report recipients
Review both the direct policy and any applicable inherited policy for the intended From domain. An empty lookup at one _dmarc owner is not enough to conclude that no policy applies. Preserve existing enforcement and approved report destinations. Do not copy the public example’s masked email text, add duplicate policies, replace reject or quarantine with none, or create a child override just to obtain a green indicator.
Only if no direct or applicable inherited policy exists, the domain owner approves and a monitored introduction is appropriate, a first TXT policy may be v=DMARC1; p=none. For From example.com, its full owner is _dmarc.example.com; for From mail.example.com, it is _dmarc.mail.example.com. In the latter case, the relative owner is _dmarc.mail in the parent zone or _dmarc within the delegated child zone. This minimal record requests no aggregate reports. Do not use obsolete pct rollout guidance. Current DMARC policy standard.
Obtain separate owner approval for report sharing. When a destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. DNS authorization is not a replacement for the privacy and data-sharing decision. RFC 9990 section 4.
Check DNS and confirm readiness with mySMTP
In the dedicated dashboard, select the correct server and open DNS verifications. Compare status with the exact account-supplied records after publication. Resolve wrong owners, incomplete values, duplicate policies and stale cached answers. The public dashboard illustration confirms that DNS verifications is a distinct area from Log Reports and Server Fleet; it does not show a separate DKIM activation toggle. Do not invent one. Dedicated dashboard DNS verification.
The DNS explainer allows for propagation time, but waiting cannot fix an incorrect record. Compare authoritative answers first, then the resolver’s cached view. If status remains unclear, provide necessary redacted domain, selector and diagnostic details through the approved support channel. Have mySMTP confirm the domain’s signing setup and readiness before the controlled send, as described in its onboarding assistance. Pre-send configuration checks.
Do not rotate keys, regenerate credentials or delete a working selector merely to retry a check. Preserve queued-message and shared-server dependencies. A domain check, SMTP login and receiving-server acceptance are three different kinds of evidence.
Test the intended application through the assigned relay
For an existing authorized integration, verify that it uses the assigned hostname and approved SMTP credentials. The current FAQ recommends port 587 with STARTTLS and lists 2525 as an alternative. Use the account’s actual supported settings; do not downgrade encryption, disable certificate validation, change a firewall or add an IP exemption just because a connection fails. Escalate those changes to the responsible administrator. Current connection requirements.
Use an approved, harmless test to controlled valid recipients through the real application and dedicated server. Do not trigger a real invoice, password reset, customer notification or bulk campaign merely to check headers. Do not transmit customer content to an external testing service without separate approval. A different application, server or sender does not certify the intended route.
Locate the message in Log Reports and examine its actual SMTP response. The current dashboard retains detailed logs for 30 days. An accepted status means the receiving server accepted the message, not that it reached the inbox or was read. Avoid resubmitting an already accepted message merely because a recipient has not yet found it. Log Reports and acceptance meaning.
Obtain original received-message evidence from the receiving service’s known processing boundary and consult its documented handling of externally supplied Authentication-Results. Ask its administrator for a trace if needed. Header position or a familiar authserv-id text alone cannot establish trust; ignore externally injected results. Authentication-Results trust requirements.
Record the visible From, SMTP MAIL FROM, intended mySMTP DKIM signature’s d= domain and s= selector, plus trusted SPF, DKIM and DMARC results. Acceptance for this branded route requires that intended signature to pass and align with the intended From, together with trusted dmarc=pass. A rewritten provider From or unrelated passing signature is not successful customer-domain authentication.
DMARC can pass through aligned SPF or aligned DKIM, but a pass through SPF alone does not prove DKIM is working. Relaxed alignment compares Organizational Domains; strict adkim requires an exact DKIM-domain match, while strict aspf requires an exact MAIL FROM-domain match. A child envelope domain can align relaxed and fail strict. See raw DKIM versus aligned DKIM results.
Troubleshooting and safe recovery
DNS is green, but the intended signature is missing: confirm the application used the assigned server and intended From, then ask mySMTP to inspect that domain’s signing configuration. Do not assume a new Enable switch exists.
DKIM is present but fails: check the full public key at the actual selector and investigate downstream content modification with the responsible administrators. Do not disable required compliance or security controls to preserve a signature.
SPF reports a permanent error: inspect duplicate policies, syntax and the evaluated lookup budget. Temporary lookup errors require a different DNS investigation; an ordinary SPF fail means the evaluated sender was not authorized by that result. Diagnose these separately even if DKIM supplies DMARC’s pass.
Raw DKIM passes but DMARC fails: compare the passing signature’s domain with the actual From under the current alignment policy. Do not weaken enforcement or infer customer-branded success from a provider-domain signature.
The SMTP connection fails: verify the assigned host, approved port, TLS settings and correct existing credentials. Do not send a password to support or enable unauthenticated access as a shortcut.
A message is rejected: inspect the actual SMTP diagnostic. DMARC failure alone does not establish the rejection cause. Recipient policy, suppression, consent and reputation issues need their own investigation. Authentication does not guarantee inbox placement.
If an approved change disrupts service, pause the affected workflow where safe and coordinate restoration to the last approved state. Keep keys and DNS records until queued mail and shared dependencies are understood. Share only necessary redacted diagnostics with approved recipients, not credentials, private keys or unrelated customer correspondence.