On this page: Inventory the domain and submission paths · Add AuthSMTP to the existing SPF policy · Generate domain-specific DKIM in AuthSMTP · Understand the pre-signed-message exception · Confirm provider authorization and operational readiness · Troubleshooting AuthSMTP-specific failures · Frequently asked questions · Publish DMARC without weakening existing protection · Verify DNS and trusted receiver evidence separately · Review scope and implementation boundary
To authorize a customer-owned sending domain in AuthSMTP, publish valid SPF covering AuthSMTP, publish and verify the domain's AuthSMTP DKIM configuration, and maintain a valid DMARC policy. AuthSMTP requires all three even though a message can technically pass DMARC through either aligned SPF or aligned DKIM. AuthSMTP authorization baseline
This guide covers outbound mail relayed through AuthSMTP using a domain you control. It does not change your incoming mailbox provider or configure unrelated SMTP services. SMTP login authentication proves an application can submit mail; it is not the public-domain authentication that recipients evaluate.
Inventory the domain and submission paths
Write down the visible From address, application, envelope sender if configurable, AuthSMTP account and DNS administrator. Include website forms, desktop software, scheduled jobs and failover systems. A domain used by several applications needs more than one representative message sample.
Keep a copy of the authoritative DNS records and TTLs before editing. Identify the nameservers actually serving the zone rather than assuming the registrar's editor is active. Record existing DKIM selector owners, SPF authorizations and DMARC policies for the From domain and its parents.
A crucial AuthSMTP distinction is whether messages arrive already DKIM-signed. That decision can differ between applications sharing one account. Identify which application signs first, the signing domain it uses, and whether any intermediary changes content after signing. Put signed and unsigned submission routes on separate worksheet rows.
Use the settings issued for your account and domain; do not invent regional targets or reuse another customer's selector.
Add AuthSMTP to the existing SPF policy
The required provider mechanism is include:authsmtp.com. AuthSMTP instructs customers to merge it into the existing SPF TXT policy before the terminal all, preserving every other legitimate sender. AuthSMTP SPF setup
For a domain where AuthSMTP is genuinely the only authorized sending service, this scoped example illustrates the syntax:
Owner: example.com
Type: TXT
Value: v=spf1 include:authsmtp.com ~all
Replace example.com with the actual domain. Do not replace an existing complete policy with this example. If the existing policy uses -all, adding AuthSMTP does not require changing that to ~all; preserve the owner's existing decision unless a separate review changes it.
If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.
AuthSMTP's longer FAQ also shows a and mx in an example. These are additional authorizations for the domain's address and MX hosts. They are not part of the AuthSMTP include and should be retained or added only when those systems legitimately send. Your laptop's private address is not the public server that delivers relayed mail. SPF source inventory and syntax
An a mechanism authorizes the applicable resolved A/AAAA addresses; mx authorizes addresses of the mail exchangers returned for its domain. Compare those resolved destinations with the approved outbound-sender inventory, rather than authorizing a website/CDN or inbound mailbox service merely because it exists. SPF a and mx evaluation.
Check the actual SMTP MAIL FROM domain on delivered mail. SPF passing there does not automatically authenticate a different visible From domain for DMARC. If the application controls an envelope address, document it alongside From; changing Reply-To will not repair SPF alignment.
Generate domain-specific DKIM in AuthSMTP
In the Control Panel, open Advanced Config → DKIM Signing for the sending domain. New configurations prefer the CNAME method, with a selector and destination generated by AuthSMTP. The structural pattern is:
Owner: SELECTOR._domainkey.YOUR_DOMAIN
Type: CNAME
Target: SELECTOR.YOUR_DOMAIN.dkimkey.com
Replace every placeholder using the actual panel output. Neither SELECTOR nor a tutorial's example selector is a universal fixed value. Publish the generated target exactly and verify it in AuthSMTP after DNS publication. The panel's alternative TXT/public-key method is available when CNAME cannot be used. Current AuthSMTP DKIM configuration
For CNAME, enter the owner and destination in separate fields. If the editor appends the zone automatically, use the correct relative owner. Confirm the destination does not accidentally become a name under your own zone. Use ordinary DNS resolution, not a web proxy setting intended for website traffic.
For full owner SELECTOR._domainkey.news.example.com, a relative field in example.com needs SELECTOR._domainkey.news; one in a separately delegated news.example.com zone needs SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, its owner field is SELECTOR. These structural examples apply to either issued record type. Preserve existing NS delegations, selectors, inbound MX and forwarding; do not change nameservers or DNSSEC merely to publish this record. DNS zone boundaries.
Do not create TXT and CNAME records at the same selector owner. If an old TXT key is present, identify its users and coordinate a replacement before switching record types. Keep unrelated selectors intact. The CNAME approach delegates key maintenance to AuthSMTP; a manually hosted TXT key needs future DNS updates when the key changes. AuthSMTP DKIM operations guide
For AuthSMTP's CNAME method only, apply the following controls; they are not instructions to convert its alternative TXT key into an alias. Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.
For the TXT alternative, copy the entire generated public-key value, including its tags. Never put private keys, account passwords or SMTP credentials in DNS. A public selector record enables verification but does not itself prove any application used that selector. DKIM verification model
Understand the pre-signed-message exception
AuthSMTP preserves an incoming DKIM signature and does not add its own signature to an already-signed message. Nevertheless, its verified DKIM configuration remains required for the domain and provides signing for unsigned submissions from other applications. AuthSMTP pre-signing behavior
This changes how you investigate a failure. Suppose a website signs as mailer.vendor.example but uses From example.com. Publishing a valid AuthSMTP selector does not cause that pre-signed message to acquire a second aligned AuthSMTP signature. Inspect the application's signing configuration and verify the complete route instead of continually replacing the AuthSMTP public key.
Treat that example as a diagnostic scenario, not an observed incident. The corrective choice depends on who owns the upstream signer: configure its aligned signing domain, or deliberately use a supported unsigned-submission path so AuthSMTP can sign. Do not strip signatures blindly from production messages. Preserve evidence, test the proposed route and coordinate changes with the application owner.
Test at least one normal unsigned submission and one normal pre-signed submission when both exist. Record the resulting selector and signing domain separately. A working safety-net signer cannot repair a broken upstream signature on mail it deliberately leaves unchanged.
Confirm provider authorization and operational readiness
Complete DNS verification, then use Control Panel → From Addresses → Add Address or Add Domain and check authorization status. A login that works but receives a not-authorized-to-send response needs a domain and sender review, not necessarily a password reset. AuthSMTP explicitly requires SPF, DMARC and verified AuthSMTP DKIM before customer-owned-domain authorization. Authorization troubleshooting
Keep the domain, selector, issued record, check date and application owner in a maintenance record. Monitor CNAME resolution or coordinate TXT-key replacements; retain old records until their traffic is understood.
Troubleshooting AuthSMTP-specific failures
No AuthSMTP signature appears: first determine whether the application pre-signed the message. Also confirm the actual domain and account rather than testing against an unrelated verified entry.
A signature is present but fails: query the selector named in that message, not the selector you expected. Check for missing DNS, stale keys or content changed after signing. A provider status check and a cryptographic verification answer different questions.
Only some templates fail: compare message construction, MIME encoding, line handling and duplicate headers. AuthSMTP's operational guidance highlights formatting and content transformations as DKIM risks. Investigate with a minimal controlled template before altering a shared key. DKIM operational troubleshooting
Moving from TXT to CNAME causes errors: check for the old TXT record at exactly the same owner and a destination with an appended domain suffix. Do not delete another service's record merely because its name contains _domainkey.
SPF changes break other mail: restore any accidentally removed authorization from the saved snapshot, then review the merged policy. Do not add a second SPF record as a quick workaround.
Publish DMARC without weakening existing protection
Inspect the From domain's policy and any applicable inherited parent policy first. Preserve established enforcement, reporting destinations and subdomain settings. Do not create a child p=none record merely to bypass a parent's protection.
Only for a domain with no established or inherited policy and an approved monitoring rollout, this is a starter template:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
For From example.com, the relative owner is _dmarc in that zone. For From news.example.com, a deliberate domain-specific policy belongs at _dmarc.news.example.com, entered as _dmarc.news in the parent zone or _dmarc in a separately hosted news.example.com zone. Check inherited protection before adding it.
Replace the domain and reporting mailbox with a working destination you control or one explicitly supplied by your reporting service. Keep semicolons between tags and mailto: before the address. Publish one DMARC policy at the intended owner. p=none requests monitoring, not quarantine or rejection of failures.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.
DMARC passes when SPF or DKIM passes and aligns with From. Relaxed alignment permits an organizational-domain match; strict alignment requires an exact domain match. Review reports across all legitimate senders before stronger enforcement. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around that obsolete percentage tag. Current DMARC standard
Verify DNS and trusted receiver evidence separately
Replace the example names before running read-only checks:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com
Check the authoritative answer and a recursive resolver if results differ. For TXT-based DKIM, expect the issued public key; for CNAME-based DKIM, expect the issued alias and a resolvable public key at its target. Expect only one SPF policy at each evaluated owner. Recursive SPF evaluation must stay within the ten evaluated DNS-querying-term limit across include, a, mx, ptr, exists and redirect, including nested processing; counting the includes visible in the top-level record is insufficient. SPF evaluation rules
Send a newly generated message through each production route to a mailbox where you can inspect raw headers. Use the receiving system's trusted Authentication-Results, not an arbitrary earlier field a sender could have inserted. Record spf, smtp.mailfrom, dkim, header.d, and dmarc with header.from; obtain the selector from DKIM-Signature when needed. Authentication-Results trust boundary
Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.
For an unsigned submission that AuthSMTP is meant to sign, acceptance requires trusted dkim=pass for the intended AuthSMTP-issued selector and branded d= domain, alignment with the unchanged intended From under the effective adkim policy, and trusted dmarc=pass for that From. For the documented pre-signed exception, require the expected upstream branded signature to pass and align through the complete AuthSMTP route, plus trusted dmarc=pass; do not expect AuthSMTP to add a second signature. Its verified domain DKIM configuration remains required for the domain even when every normal submission is pre-signed. An unrelated passing signature, a rewritten provider From or SPF-only DMARC pass does not prove the intended DKIM route works. AuthSMTP pre-signed and unsigned behavior, DKIM alignment.
Investigate SPF independently even when aligned DKIM supplies DMARC pass. For fail or softfail, check the actual MAIL FROM domain, sending IP and any forwarding hop against its policy. For permerror, check multiple policies, syntax and nested lookup limits. For temperror, investigate DNS availability and retest after recovery. Do not authorize an unknown IP or edit an unrelated apex policy to hide an error. SPF result definitions.
A DNS lookup cannot prove this. Preserve a redacted sample, route and timestamp; do not upload confidential message bodies to public tools. Authentication also does not guarantee inbox placement or eliminate reputation, consent and content problems.
If Google Workspace also sends as your domain, review EmailAuth's guide to Workspace aliases and secondary-domain alignment separately. Keep both providers authorized; completing this service's setup does not validate your mailbox route.
Review scope and implementation boundary
No customer account was configured, DNS changed or delivery test performed for this guide. Before deployment, complete the account, DNS and message checks above for your sending route. Authentication does not guarantee delivery.