MSP360 SPF, DKIM and DMARC setup, step by step

Scope: Managed Backup notifications using the native MSP360 email service. This is not a configuration guide for custom SMTP, customer-owned Amazon SES, standalone Backup agents or every product formerly branded CloudBerry. No customer account, DNS change or message test was performed.

Quick answer

Authenticate the approved sender in Managed Backup, publish its account-issued DKIM records, and validate a notification's intended signature and DMARC alignment. There is no universal DKIM selector to copy. MSP360 documents ip4:50.19.243.6 for its Managed Backup email service; that is not permission to replace your existing SPF policy or edit a domain that the actual sending route does not use.

SPF authorizes a sending server for an envelope domain. DKIM verifies a signature associated with a signing domain. DMARC checks whether a passing authentication domain aligns with the visible From domain. A successful DNS lookup is not proof that a notification passed these checks.

Confirm the service before changing anything

Use an existing authorized Managed Backup account and a sender mailbox at a domain you control. Confirm the active sending route with its administrator. Do not switch a working service merely to follow this page. MSP360's Email Service documentation separates native MSP360, custom SMTP and customer-owned Amazon SES; it warns that returning from custom SES to MSP360 requires support.

Backing up a Microsoft 365 mailbox does not make Managed Backup the sender of that mailbox's ordinary mail. For that separate route, see our Microsoft 365 DMARC guide. A corporate relationship or shared cloud backend does not establish interchangeable authentication records.

Before publication, obtain approval for the exact domain, sender, DNS owners, values and any policy change. Export the current zone and record any delegated child zones, _domainkey delegation, existing selectors, SPF policies and effective DMARC policy. The public instructions do not establish a universal subscription tier or role name; missing controls require account-specific clarification, not a guessed upgrade or route migration.

Obtain and publish the issued DKIM records

The native workflow in the official setup page is:

1. Open Settings → Email Service and confirm the approved MSP360 route and sender.
2. Choose Verify email. Complete the verification link in that mailbox, then Save changes.
3. Use Refresh to check requirements. If DKIM configuration required appears, copy every issued record's full type, name and value, or use Export to CSV.
4. Publish the exact packet in authoritative DNS. The illustrated configuration has three CNAMEs; use your account's complete packet, not the screenshot's truncated examples.
5. After verification and publication, Save changes and confirm the green checks, including DKIM is configured correctly.

Keep verification links private. A screenshot showing a third-party mailbox domain is not authority to edit that domain. Never reconstruct a truncated selector or CNAME target. Stop if the account packet conflicts with the approved sending domain, or if the complete records cannot be obtained.

Put each record in the authoritative zone

The DNS service hosting public authoritative answers may differ from your registrar. Follow existing delegations rather than deleting them. For an illustrative issued full owner SELECTOR._domainkey.news.example.com:

These are owner-mapping examples, not MSP360-issued selectors. Replace the example with the actual complete name. For a CNAME, put the exact destination in Target or Value, not in the owner field; for a TXT, preserve the entire supplied TXT value. Confirm whether your editor accepts full or relative names. Do not append the zone twice. DNS name rules and DKIM key lookup explain the distinction.

A CNAME cannot coexist with ordinary conflicting data at the same owner. Stop and investigate a conflict rather than deleting a working selector, TXT record or delegation. Preserve unrelated and standby selectors. An inactive-looking selector may be needed for rotation or queued mail.

Use DNS-only rather than HTTP-proxied records. Where a literal CNAME must remain visible, disable a relevant per-record flattening option if supported and examine zone-level behavior. Cloudflare's flattening documentation describes apex and same-zone behavior that may override a setting. Do not blindly turn off unrelated global features. If the required record cannot be published faithfully, request a supported configuration before proceeding.

Configure SPF only at the applicable envelope domain

MSP360's Managed Backup SPF article documents the mechanism:

ip4:50.19.243.6

It also lists different connection addresses for custom SMTP. Those addresses are not a substitute native-service SPF recipe. Do not infer an Amazon SES include from a backend reference or copy SPF from MSP360's corporate website.

First establish the actual SMTP MAIL FROM domain for this native route using reliable route documentation and, when available, an authorized representative message. Visible From alone does not identify the SPF owner. If the envelope domain is provider-owned, you cannot fix its SPF in your own zone; seek provider clarification. A null reverse-path is a separate SPF identity case requiring correct HELO interpretation, not guessing from the visible From.

If the documented mechanism applies to a customer-controlled envelope domain and is approved, merge it into that owner's one existing SPF TXT policy, preserving its legitimate senders and intentional final qualifier. Do not publish a second v=spf1 policy. If none exists, have the administrator inventory all senders and approve the initial complete policy rather than blindly deploying a one-sender example. Do not paste backticks or the word TXT into the TXT value. Do not copy a blanket ~all ending as a substitute for deciding policy.

Evaluate the full SPF policy, including nested includes, against the ten DNS-dependent-term limit. An ip4 mechanism itself does not consume that lookup budget. A redirect is ignored when an all mechanism is present; placing text after a matching all does not authorize the sender. Preserve functional policy structure, not just strings. SPF specification.

Preserve DMARC protection and reporting controls

Read the policy applicable to the visible From domain, including inheritance and alignment settings, before editing. Do not overwrite enforcement with monitoring to make this sender pass. Adding a child policy can change inherited protection, so it requires explicit review.

Only when no applicable policy exists and the domain owner approves an initial monitoring policy, an illustrative TXT value is:

v=DMARC1; p=none

For From domain example.com, publish at full owner _dmarc.example.com, or relative _dmarc in that zone. For news.example.com, the full owner is _dmarc.news.example.com: relative _dmarc.news in the parent zone, or _dmarc in a separately delegated child zone. Do not create a child monitoring exception to an existing protective parent. This example requests no reports and provides no enforcement.

If reporting is separately approved, confirm the destination and permission to disclose report data. External report authorization is a distinct protocol check: compare the report destination's Organizational Domain with the policy domain's Organizational Domain. If they differ, the receiver generating the report must check DNS authorization before sending it; if they are the same, that external-destination authorization check is excepted. RFC 9990 section 4 defines this rule. Where required, have the report destination operator provision the correct authorization record. A DNS authorization record is not the user's privacy approval.

Verify DNS, console status and a real notification separately

1. Public DNS

Query the exact owner at an authoritative server, then through a recursive resolver. The following are placeholders, not commands already run against your domain:

dig @AUTHORITATIVE_SERVER CNAME ISSUED_DKIM_OWNER
dig CNAME ISSUED_DKIM_OWNER
dig TXT CONFIRMED_ENVELOPE_DOMAIN
dig TXT EFFECTIVE_DMARC_POLICY_OWNER

Use TXT instead of CNAME if that is what the account issued. Repeat for every record. Compare complete values, not merely whether an answer exists. Confirm the alias chain reaches a valid key, the expected SPF policy is unique, and unrelated records remain unchanged. Cached old answers may need time; a wrong authoritative answer needs correction, not waiting.

2. Provider status

Check the intended sender's current native-service verification state against the same issued packet. A green console is useful configuration evidence, not delivered-message authentication evidence. Record the check time and distinguish stale results from a new failed verification.

3. Controlled message evidence

Use an authorized harmless notification in an isolated test context, following the provider's supported process. A native-service dedicated test button was not established by the reviewed material. Do not borrow custom SMTP's test controls, create a production backup failure, run a restore, or change customer notification preferences to manufacture a test. If no safe supported trigger is available, record message validation pending and ask support for an appropriate test path.

Inspect original headers at the controlled receiving mailbox, not a forwarded copy. Trust Authentication-Results only from the receiving service's established processing boundary and documented handling of externally supplied result fields. A familiar authentication-server identifier or header order alone is insufficient. Authentication-Results trust requirements.

Require the intended native-route DKIM signature to pass and its d= domain to align with the unchanged approved visible From, plus trusted dmarc=pass. SPF-only DMARC success does not validate DKIM. A rewritten provider-owned From is not success for the original branded address. Record the selector, signing domain, envelope domain, trusted results and route, without exposing message contents unnecessarily.

Under DMARC's alignment rules, relaxed alignment compares Organizational Domains; strict alignment requires an exact match. Evaluate DKIM under adkim and SPF under aspf separately. A child envelope domain can align under relaxed SPF without satisfying strict SPF alignment.

Troubleshooting and safe rollback

Investigate these SPF failures even when aligned DKIM allows DMARC to pass; that pass does not repair SPF.

The notification troubleshooting guide identifies global, company, plan and user settings as separate possible causes. Inspect only authorized settings; do not enable new recipients, unsuppress bounced recipients or alter operational events without approval.

Keep the original values, approved change list, timestamps, DNS results, console state and message evidence. Roll back only the erroneous approved change, preserving later dependencies and selectors needed for queued mail or rotation. Never change nameservers, mailbox MX records, credentials or unrelated delivery routes as speculative fixes.

Common questions

Are MSP360 SPF and DKIM settings the same for every product?

No. This page deliberately covers one Managed Backup sending route. Other routes need their own current provider instructions and verification.

Can I use one published DKIM value for every customer?

No. Use each account's issued public record set and approved domain. Never publish a private signing key or reconstruct a screenshot value.

Does DKIM verification guarantee notifications reach the inbox?

No. Authentication, notification generation, recipient acceptance and inbox placement are different stages. A provider status badge cannot prove a delivered message's alignment.

Is this a hands-on deployment test?

No. It is a documentary guide with explicit customer-specific acceptance checks. Actual account configuration, DNS publication and message validation remain separate work.