Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Identify which system will sign
References: RFC 6376 §3.5.
An application submitting mail to AuthSMTP can rely on relay signing or arrive with its own signature. That distinction determines which key the recipient must find. Start by recording the application, AuthSMTP account, intended From domain and whether application-side DKIM is enabled. Ask the application owner rather than assuming the relay will repair an existing signature.
AuthSMTP documents that it preserves an existing DKIM signature without adding its own. It still requires a verified AuthSMTP DKIM configuration for the domain, providing coverage for unsigned submissions. This means a green relay configuration cannot prove that a pre-signed application message uses the expected signer. AuthSMTP DKIM
Complete the domain authorization sequence
References: RFC 7208 §3.2, RFC 7208 §4.6.4, RFC 1034 §3.6.2.
In the Control Panel setup workflow, add the sending domain, configure its authentication, verify the records, then authorize the From addresses. Configure the application using its approved SMTP settings. The service's authorization baseline requires SPF, verified DKIM and a valid DMARC policy, even though DMARC itself can pass with one aligned authentication method. Getting started
For a new DKIM setup, use the domain's generated selector and CNAME destination. Publish them at the authoritative DNS host and verify in the Control Panel. The service also documents a TXT alternative when CNAME is unavailable. Do not publish both types at the same selector. If that owner is occupied, investigate its use before replacing anything. DKIM procedure
AuthSMTP's SPF instruction is to incorporate include:authsmtp.com into the existing policy before its final all mechanism. Preserve other legitimate senders and evaluate SPF’s ten-term limit across evaluated include, a, mx, ptr, exists and redirect terms, including nested processing. It is not simply a count of visible includes or raw DNS packets. Publish a single SPF TXT policy at the applicable owner, not a second AuthSMTP-only policy. SPF procedure
Use a two-branch acceptance test
References: RFC 9989 §4.4.
Original test design: send one harmless message from each materially different application path to a controlled mailbox. Where the application can send both pre-signed and unsigned messages, treat them as separate test cases. Do not disable a production signer just to manufacture a test without an approved change window.
For each case, retain the receiving system's authentication results, visible From domain, envelope sender, every DKIM signing domain and selector, and the actual relay route. Compare those observations with the planned signer. DMARC requires a passing aligned SPF or DKIM result; a passing unrelated signature is not the acceptance criterion. A relay log showing submission success answers a different question from the receiver's verification result.
Illustrative scenario: a reporting application signs with a retired application key before relay submission. Publishing a fresh relay selector leaves that application signature unresolved. The useful decision is to correct the application's active signing configuration or approve a switch of signing responsibility, then retest. Repeated relay DNS edits do not address the wrong signer.
Recover and keep ownership clear
Save the pre-change application settings and affected public records. On failure, pause the new application route, identify which layer supplied the bad identity and restore the last approved configuration at that layer. Leave unrelated mailbox authorization alone. Keep prior valid selectors until queued mail and DNS caching are accounted for.
Recheck after an application deployment, sender-domain addition or signer change. Close the work only when each application path has a named owner and recorded evidence. This guide is based on documentation reviewed on 8 November 2026. No AuthSMTP account, DNS change or delivered message was tested here; the scenario and acceptance design are illustrative.