DomainFactory SPF, DKIM and DMARC setup, step by step

For DomainFactory Professional E-Mail powered by Titan, use the records from your DomainFactory Email & Office settings. The documented SPF value is v=spf1 include:secureserver.net -all. DKIM uses two CNAME owners, secureserver1._domainkey and secureserver2._domainkey, pointing to the exact targets issued for your account. Domains added from March 2026 are documented as receiving authentication records during initial setup; older domains have a retrieval-and-publication workflow. DomainFactory Professional E-Mail technical FAQ.

This guide covers that DomainFactory product, including its own DNS editor and publication at an external authoritative DNS provider. It does not apply to legacy ispgateway hosting mail, MyMail Starter/Individual/Team, Microsoft 365, cPanel mail or a self-managed server. Their account screens and sending infrastructure must be assessed separately.

Confirm the product, domain and setup cohort

Open the DomainFactory Kundenmenü and confirm the mailbox belongs to Professional E-Mail powered by Titan. Check the domain's actual mail service rather than choosing records from its registrar or from an older hosting tutorial.

The official Professional E-Mail FAQ distinguishes two cases:

• Domains added from March 2026: SPF, DKIM and DMARC are added by default during initial setup, according to the provider. Inspect the actual resulting records and message authentication before making any further change.
• Domains already used with Professional E-Mail before March 2026: retrieve the records in Email & Office and publish the needed updates using the procedure below.

This is a domain-setup distinction, not simply the date someone created a mailbox or read the article. If the account's history is uncertain, inspect its current setup screen and DNS instead of forcing it into a cohort.

Automatic setup also does not prove that an external DNS provider has received the records. The same official procedure explicitly tells customers whose DNS is elsewhere to update that provider. Verify the active authority and the records it serves before relying on automation.

Use your DomainFactory account for this workflow. Some GoDaddy products share the same backend and selector names, but a GoDaddy customer dashboard is not the DomainFactory control panel. For an account actually managed through GoDaddy, use the separate GoDaddy authentication guide.

Prepare access and preserve the working configuration

You need an existing Professional E-Mail mailbox and domain, authorized access to the DomainFactory Kundenmenü and access to the authoritative DNS zone. No separate DKIM plan restriction is stated in the reviewed procedure. Do not transfer a limitation for another feature, such as calendar synchronization, to DKIM.

Before editing:

• Record the intended visible From domain and the routes that send for it, including mailbox clients, webmail and applications.
• Save the existing SPF policy, both relevant selector owners, DMARC policy, TTLs and any _domainkey delegation.
• Identify other legitimate senders and any existing policy inherited by a sending subdomain.
• Retain the current MX, website, verification and unrelated authentication records.
• Arrange a controlled external mailbox where you can inspect newly delivered message source.

The Professional E-Mail FAQ specifies smtpout.secureserver.net on port 465 with SSL and the full email address as username. Use the account's current supported settings, not the server names for an older DomainFactory mail product. Do not change a working submission route or credentials as an incidental DNS repair. Professional E-Mail connection settings.

Retrieve the exact records from DomainFactory

For the documented existing-domain update:

1. Sign in to the DomainFactory Kundenmenü and open E-Mail und Office Übersicht.
2. Under Benutzer, choose Konfigurieren next to the relevant user.
3. Under Verwalten, choose E-Mail-Ziel festlegen. The provider also documents Hilf mir, das zu beheben in the banner as an entry point.
4. In Schritt 2, locate the two DKIM CNAME entries. The FAQ says each target contains dkim.
5. In Schritt 5, locate the SPF TXT and DMARC TXT details.
6. Copy the exact owners, types and complete values into a private change worksheet for the intended domain.

The two DKIM owners documented for this product are:

secureserver1._domainkey
secureserver2._domainkey

Both are CNAME records. Their destinations are account-generated hostnames, not universal values that can be constructed from the selector or a sample domain. Keep the complete targets from the account screen. Do not substitute a TXT public key, another customer's destination or values from a different Titan reseller. Record retrieval and DNS fields.

The workflow does not document a separate Microsoft-style “start signing” switch. Do not invent one. Correct publication and a completed setup screen are useful evidence, but the delivered-message test still determines whether the intended signature is actually used.

Configure SPF without dropping other senders

DomainFactory's Professional E-Mail example is:

v=spf1 include:secureserver.net -all

Publish this as TXT at the documented mail-domain apex only when it represents the intended policy. DomainFactory's Professional E-Mail DNS instructions use Name @ and the default TTL for this SPF entry.

If SPF already exists, update that one policy to include the required Professional E-Mail authorization while preserving other legitimate services. Retain the established terminal qualifier unless the owner deliberately changes it after reviewing all routes. Do not create a second policy, append another v=spf1 string or remove a legacy route that still sends business mail.

Do not replace this product's include with a generic Titan example such as spf.titan.email, or use an older DomainFactory SPF wizard output without confirming that it applies to the actual sender. The current Professional E-Mail instructions, not the shared backend's brand name, establish the documented value. Product-specific SPF.

Separate authorization from alignment

SPF normally checks the SMTP MAIL FROM domain, not the visible From address. A root policy does not automatically apply to a child envelope domain or to a provider-owned Return-Path. A null reverse path can cause the HELO identity to be evaluated. The reviewed DomainFactory instructions do not establish a configurable custom Return-Path or guarantee the normal envelope identity for every route. Inspect the trusted receiver's actual smtp.mailfrom. SPF identities.

Check the whole SPF evaluation against the ten DNS-lookup-causing term limit, including evaluated nested dependencies. Includes, a, mx, exists, ptr and redirect can contribute where evaluated; the rule is not ten includes in the top-level text. A duplicate policy, syntax error or exceeded lookup budget can produce permerror. An all mechanism makes redirect ineffective. -all returns fail for unmatched senders, but receiver handling remains a separate decision. Never repair a failure with +all. SPF evaluation limits.

Publish both DKIM CNAMEs at the active authority

Check the domain's delegated nameservers before selecting an editor. External authoritative DNS remains external even if DomainFactory registers the domain or provides the mailbox. Do not move nameservers to make the following UI available.

DomainFactory-managed DNS

The Professional E-Mail FAQ gives this path:

1. Open the DomainFactory Kundenmenü Domain-Portfolio.
2. Choose Nameservereinstellungen.
3. Select the correct domain and choose editieren.
4. Add or update only the approved records.
5. Choose Alle Einträge speichern after inspecting the changes.

The general Nameserver FAQ also describes Domain → Nameserver-Einstellungen → Editieren, sometimes after selecting the correct Auftragsverwaltung. Use the selected domain's actual record editor, not a nameserver-migration form. General DomainFactory DNS navigation.

For each DKIM entry, choose CNAME, enter its documented Name and paste the matching account-issued Wert/Ziel. The specified TTL is 1 Stunde. Publish both records even if a current message uses only one selector. Do not remove the second because it appears inactive.

An existing selector is not automatically safe to overwrite. Identify the service and key lifecycle that depend on it. If the current record belongs to another route or tenant, resolve that ownership before replacing it.

External DNS and full-owner mapping

The Professional E-Mail FAQ expressly supports publishing at your current DNS provider. Translate the same complete owners and destinations into that editor's fields; do not reproduce DomainFactory UI labels blindly.

For a mail domain of example.com, the complete owners are:

secureserver1._domainkey.example.com
secureserver2._domainkey.example.com

In an example.com zone whose editor appends the zone name, use secureserver1._domainkey and secureserver2._domainkey. If an issued owner includes a sending subdomain, such as secureserver1._domainkey.news.example.com, use secureserver1._domainkey.news in the parent zone, or secureserver1._domainkey in a separately delegated news.example.com zone.

An NS delegation for _domainkey.example.com changes where those selector records belong. In that delegated namespace, secureserver1 would be relative to _domainkey.example.com. Preserve the delegation and work with its administrator; adding an ineffective record at the parent or deleting the delegation can break other senders.

CNAME conflicts, proxying and flattening

Each selector must resolve through the exact issued CNAME destination. Do not put TXT, A, AAAA, MX or another conflicting CNAME at the same owner. The destination is a hostname, not an HTTPS URL or a page path.

If the DNS service offers HTTP proxying, use DNS-only for these mail-authentication aliases. If it supports CNAME flattening, verify that queries for the two selector owners still expose the required CNAME chain. Settings can differ by individual record, zone-wide policy, apex handling or same-zone behavior; an apex-only flattening feature is not automatically a problem for a non-apex selector.

Change only a relevant setting that is actually hiding the required aliases, and only after reviewing its effect. Do not globally disable flattening or change website records merely to follow generic advice. If the provider cannot serve the issued aliases as required, obtain its supported publication method before declaring success. CNAME constraints and DKIM key lookup.

Keep the established DMARC policy

Step 5 can show a proposed DMARC record, but that is not permission to overwrite an existing policy. Check the intended visible From domain and any applicable inherited policy first. Preserve existing enforcement, alignment settings and authorized reporting addresses, including records added during initial setup.

Only when no direct or applicable inherited policy exists, and the domain owner approves a monitored rollout, a first record could use this illustrative value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the mailbox with an approved working reporting destination. Use TXT at _dmarc.example.com, with relative Name _dmarc in the example.com zone. A policy at _dmarc.news.example.com maps to _dmarc.news in the parent zone or _dmarc in the delegated child zone. Do not publish at the apex or add a weaker child policy over an inherited enforcement policy. DMARC policy discovery and alignment.

If the aggregate-report destination has a different Organizational Domain from the domain where the DMARC policy was found, the report-sending receiver must verify destination DNS authorization for the reporting relationship. That external-authorization check is not required when they share the same Organizational Domain. Obtain the reporting provider's authorization instructions and exact address. External-destination authorization. Approve who receives the information and its access and retention controls. Aggregate reports expose sending infrastructure and authentication activity; failure reports can disclose additional message details. Do not copy a tutorial's reporting recipient or add failure reporting without a privacy decision. Aggregate reporting and failure reporting.

Verify both aliases and a newly delivered message

These commands illustrate checks only. Replace the example domain, nameserver, target and envelope owner with actual values. Query every authoritative server and follow any relevant delegation:

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example CNAME secureserver1._domainkey.example.com +noall +answer
dig @ns1.dns-host.example CNAME secureserver2._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT issued-dkim-target.example +noall +answer
dig @1.1.1.1 TXT actual-envelope.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Compare both CNAME targets with the account screen and query each actual target's TXT data, following any further aliases. Check recursive answers as well as authoritative answers. A saved UI row does not prove the active delegation serves it. DomainFactory estimates that many DNS changes become effective within an hour but can take up to 48 hours globally; a wrong owner or failed lookup needs investigation immediately.

Next, send a newly authorized message through the actual Professional E-Mail route to a controlled external mailbox. Inspect Authentication-Results generated inside that receiver's trusted processing boundary. Header order or an authserv-id string alone is not proof that a result was added by trusted infrastructure. Authentication-Results trust requirements.

The acceptance test for branded DKIM requires the intended visible From to remain unchanged, the intended provider signature's d= and s= to match the configured route, that signature to receive a trusted dkim=pass, and its signing domain to align with visible From under the applicable policy. Also require trusted dmarc=pass and identify which aligned path supplied it. A DMARC pass supplied only by SPF does not prove the DKIM configuration worked.

Relaxed alignment allows an organizational-domain match; strict alignment requires exact domain equality. This applies separately to DKIM's signing domain and SPF's MAIL FROM domain. A passing provider-domain signature may be unaligned, and a child envelope domain can pass relaxed SPF alignment while failing strict alignment.

Diagnose SPF independently even when aligned DKIM passes. Direct-route fail or softfail needs a sending-IP and envelope-policy comparison; permerror needs syntax, duplicate and lookup-budget checks; temperror needs DNS investigation. Do not broaden SPF without identifying the failed route.

Test forwarding separately

DomainFactory documents automatic Sender Rewriting Scheme support for forwarding. SRS changes the SMTP envelope sender; it does not by itself establish DMARC alignment with the original visible From or guarantee delivery. A forwarded message's evidence should therefore be evaluated separately from direct mailbox sending. Do not accept a rewritten provider From address as proof that your intended brand is authenticated.

Troubleshooting and safe reversal

The account screens do not match. Confirm the product is Professional E-Mail powered by Titan rather than MyMail, Microsoft 365 or legacy hosting mail. Use DomainFactory credentials and the correct user's configuration. Do not jump to another reseller's dashboard.

A CNAME is present but the receiver cannot retrieve a key. Check the full owner, exact target, public alias chain, conflicting data, DNS-only setting and relevant flattening behavior. Follow _domainkey delegation instead of editing the wrong authority.

Only one selector is visible on messages. Keep both required CNAME records. A single active selector is not evidence that the other record is unnecessary.

DMARC passes but the intended DKIM signature is absent. Inspect the passing mechanism and actual route. An SPF-supplied pass or unrelated provider signature does not close the DKIM task.

The update disrupts another sender. Compare the saved records with current values and check for concurrent edits. Restore only the faulty change. Coordinate selector changes with signing and queued mail; do not reset the zone, delete all authentication records or lower DMARC enforcement as the default response.

Documentation and testing limits

No customer account was accessed, DNS changed or message sent. This guide does not certify live account behavior, delivered-message authentication, CMS rendering, publication, indexing, rankings or inbox placement.