Intermedia Exchange Email SPF, DKIM and DMARC setup, step by step

On this page: Scope · SPF · DKIM · Verification · FAQs

For eligible Intermedia Hosted Exchange sending through Email Protection, use the documented SPF authorization include:spf.intermedia.net, generate your domain's DKIM TXT record in HostPilot, publish it before enabling digital signing, and verify an aligned pass at an external receiver. Incoming filtering and outbound DMARC authentication are separate checks.

No customer account, DNS publication or delivered-message test was performed.

Confirm the Hosted Exchange route and Email Protection package

This procedure is scoped to North American Hosted Exchange deployments using the documented HostPilot Email Protection signing workflow. It does not claim that all other regions lack DKIM. The current DKIM article identifies the Email Protection package requirement, not a universal geographic entitlement rule. Check the account's actual controls and ask Intermedia about eligibility if they differ. Intermedia DKIM documentation

Do not apply this workflow to Microsoft 365 merely because it was purchased through Intermedia. Intermedia also documents Email Protection for Office 365 as a separate integration. Native Microsoft 365 signing, an Intermedia filtering route, an application relay and Hosted Exchange are different sending paths. Identify which system signs the final outbound message. Email Protection for Office 365

Before starting, obtain:

• HostPilot access for the intended domain and confirmation of its Email Protection package.
• The authoritative DNS provider and an authorized DNS administrator.
• A zone backup and the current SPF, DKIM and DMARC records.
• A list of direct third-party senders, gateways and devices, distinguishing those that submit through Intermedia from those that send directly.
• A recent external message's From domain, envelope domain and signature information.

A device submitting through Intermedia does not automatically require its own office IP in SPF: authorize the final outbound infrastructure, not every user's workstation. A different service sending directly to recipients may need its own authorization. Intermedia SPF guidance

Configure Intermedia SPF for the envelope domain

To inspect the account’s proposed records, open HostPilot → Services → Domains → your domain → DNS records. If Intermedia does not host the authoritative zone, Display DNS records shows the records it expects, not your live external DNS. Compare these with the actual route and publish through the authoritative provider. Intermedia now documents DNS hosting only for grandfathered domains; do not move nameservers, inbound MX or autodiscover to use this screen. Where Intermedia is authoritative, its system SPF field can be edited and saved after the sender-policy review below. HostPilot DNS management.

Intermedia's documented example for a domain sending only through Intermedia is:

v=spf1 include:spf.intermedia.net ~all

Use it only if that complete sender inventory is accurate and the owner approves its policy. For an existing record, add the include before the terminal all mechanism and retain other needed senders. Do not replace an existing -all with ~all merely to resemble the provider's example. The official guide specifies TXT at the domain's owner, often represented by @ in a DNS editor. An envelope subdomain needs its own matching owner. Official SPF setup

SPF checks the SMTP MAIL FROM domain (the envelope sender), not simply the visible From address. For an empty reverse path, SPF uses the HELO identity. A parent SPF record does not automatically authorize a subdomain. Identify the owner from the route and receiver evidence before editing DNS.

Publish only one SPF TXT policy at each owner. Merge authorized senders into that policy, preserve unrelated TXT records, and retain the existing terminal qualifier unless the domain owner separately approves a change. The limit is 10 evaluated DNS-query-causing terms, including nested includes and redirects, not ten visible services. Terms such as a, mx, include, exists and ptr consume the budget; ip4, ip6 and all do not. Evaluate the resulting policy, including nested dependencies, before publication. Do not replace a provider's managed include with a one-time snapshot of its IPs. RFC 7208

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

Some general explanations on the provider page need standards-level qualification. Publish SPF as TXT; the obsolete SPF resource-record type is not required by current SPF. The 255-octet boundary applies to an individual DNS TXT character-string, not necessarily the complete concatenated SPF policy. Do not split one policy into separate SPF records. Use a DNS editor's supported multi-string handling if needed. RFC 7208 record format

Likewise, use DMARC's published relaxed or strict alignment rules rather than treating a provider's simplified parent/child example as the full specification. Inspect the actual envelope domain. Do not assume every Hosted Exchange message has an unalignable provider return path, or that adding the include proves alignment.

Generate, publish and enable DKIM in that order

Intermedia's current instructions describe a 2048-bit DKIM TXT record and separate generation from activation. Follow the actual generated values, not the dated selector and sample public key shown in documentation. Official DKIM setup

1. Open HostPilot → Services → Email Protection → Settings → DKIM.
2. Select the domain, choose Configure → Generate keys, and copy the generated TXT owner and full public-key value.
3. If a third party hosts authoritative DNS, have that administrator publish the record there. If Intermedia is authoritative, contact Support for assistance as the current article instructs.
4. Query the generated owner and confirm that the correct public value resolves. The article also describes automatic DNS handling when Intermedia hosts the zone; do not interpret this as permission to skip verification or assume every account has already published it.
5. Only after publication is correct, return to the same DKIM screen and select Enable digital signing.
6. Send a fresh external message and confirm that the receiver reports a passing signature using the expected signing domain and selector.

Enabling signing first can cause delivery problems while recipients cannot retrieve the correct public key. A published TXT key alone does not enable signing. If your controls are missing, establish the package, domain and route with Support rather than searching for a Microsoft Defender equivalent.

The record owner has the structural form generated-selector._domainkey.your-domain; its value must be copied intact from HostPilot. Do not publish private key material or manually replace the generated public key with a generic key generator's output. The signing service must hold the matching private key. DKIM key discovery

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

Rotate keys without breaking the active signature

For a domain already signing, Intermedia documents Generate new keys followed by Switch to key. Publish the new TXT first, or coordinate the update before switching. Where the generated selector allows a separate owner, preparing that new record before activation avoids leaving receivers unable to find the new key. Do not overwrite an active selector blindly. Intermedia key rotation

Keep the old public key available while previously signed messages may still be in transit, following the provider's supported retirement procedure. Retest after switching and record which selector is active. If deliberately disabling signing, Intermedia specifies disabling digital signing before removing its TXT record. A routine delivery incident is not itself a reason to disable DKIM; investigate the failed route first.

Understand Intermedia's DMARC support wording

Intermedia says its environment does not perform the DMARC DNS-record check described in its outbound-filtering documentation, while explicitly explaining that customers can configure SPF and DKIM to pass DMARC at other providers. Do not read “DMARC is not supported” as “your outbound domain cannot pass DMARC.” Conversely, passing an external DMARC test does not prove that Intermedia's incoming filter enforces DMARC. Outbound filtering and DMARC note

Preserve or establish the applicable DMARC policy

DMARC succeeds when either SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Under relaxed alignment, the authenticated and visible From domains share an organizational domain; under strict aspf=s or adkim=s, they must match exactly. Reply-To, SMTP login and a link-tracking hostname are not substitutes for these identifiers. Current DMARC standard, RFC 9989

Before adding a record, inspect the visible From domain's DMARC policy and any applicable inherited policy. Preserve existing enforcement, alignment and reporting choices. Do not add a child p=none record merely to escape a parent's quarantine or reject policy.

Only if there is no established applicable DMARC policy, and the domain owner approves a monitored first deployment, create one TXT record at _dmarc.example.com for a From domain of example.com. For newsletter.example.com, the corresponding owner is _dmarc.newsletter.example.com. These are examples, not your account's names. After creating and approving a real reporting mailbox, a monitoring example is:

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

For a DNS editor opened on the example.com zone, the relative owner is _dmarc for the apex policy or _dmarc.newsletter for newsletter.example.com. If the editor is opened directly on the newsletter.example.com child zone, use _dmarc there. Confirm the resulting fully qualified name. Replace the reporting address with the approved destination. Check that it accepts reports and that your team can process them.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, 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. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Monitoring does not request quarantine or rejection of spoofed mail, and does not guarantee delivery. Assess every legitimate sender, including low-frequency billing and automated systems, before the owner approves stronger enforcement. Do not use the obsolete pct tag as a current percentage-rollout control. Failure reports are a separate, potentially sensitive data flow: omit ruf unless there is an approved need and privacy review. RFC 9989, Failure reporting, RFC 9991

Verify public DNS and a delivered message separately

Replace every example name below with the actual envelope domain, signing domain, selector and visible From domain. These commands read DNS; they do not activate signing or send mail.

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 server as well as a public recursive resolver. For example, replace ns1.example.net with a real authoritative nameserver and use dig @ns1.example.net TXT example.com. Compare with dig @1.1.1.1 TXT example.com. For a delegated subdomain, query its actual authority. Wait for relevant positive and negative cache lifetimes, then recheck discrepancies.

Acceptance requires one valid SPF policy at the envelope owner, the exact supplied DKIM public record at the message's selector owner, and the intended DMARC policy. TXT data may be divided into multiple quoted character strings within one record; that is different from publishing competing SPF records. DNS editors may append the zone automatically: check that a full owner did not become selector._domainkey.example.com.example.com. A CNAME cannot coexist with other ordinary record data at the same owner. Resolve a conflict with the administrator rather than deleting an unrelated record.

Next, send a fresh representative message through the actual production route to an independent mailbox you control. Open its raw source and use the Authentication-Results added by the trusted receiving system, not arbitrary header text supplied by a sender. RFC 8601

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For this branded DKIM setup, require the intended Intermedia signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Repeat for each real sender path, including aliases, applications and forwarded mail where relevant. Inspect delivery or bounce evidence separately: an authentication pass cannot guarantee inbox placement, and a successful SMTP submission only proves the server accepted the submission. Preserve redacted headers and timestamps for troubleshooting, without uploading private message content to a public analyzer.

Troubleshoot Intermedia Hosted Exchange authentication