MasterBase SPF, DKIM and DMARC setup, step by step

To add an authenticated sender domain in MasterBase, request it through customer_service@masterbase.com. Its official onboarding guide requires at least one MX record, an SPF policy containing include:spf.masterbase.com, and valid DMARC; MasterBase then supplies the corresponding DKIM configuration. Obtain that issued record set rather than copying a fixed public key from another customer. MasterBase sender-domain onboarding

This guide covers MasterBase's documented support-provisioned sender-domain flow. Confirm its application to your current MB3, Relay or other account workflow with the provider. The exact DKIM material and any bounce-domain feature remain account-specific. Do not launch a new sending identity until the provider's records, signing activation and real-message checks are complete.

Keep employee mailbox authentication separate. If Microsoft 365 sends that traffic, use the Microsoft 365 guide; its tenant settings are not MasterBase records.

No MasterBase account, customer DNS records or delivered-message results were tested here.

Identify whether MB3 or Relay is sending

MasterBase offers more than one email workflow. MB3 Email Marketing supports campaign sending and sender configuration. MasterBase Relay supports one-to-one transactional communication from existing systems through SMTP or an API. Establish which product and workflow you use; do not assume a successful marketing test validates a transactional application. MB3 overview and Relay product documentation

For each route, record:

• Account and product, including the responsible administrator or partner.
• Visible From address and intended Reply-To address.
• Campaign, automation or application that submits the message.
• Expected envelope/Return-Path domain, if the provider has confirmed it.
• Intended DKIM signing domain, selector and activation status.
• DNS owner, authoritative zone and existing DMARC/reporting policy.

An API credential or a successful SMTP login proves access to a submission service, not that the resulting message uses a branded, aligned identity. Keep authentication evidence separate from integration-connectivity evidence.

Add the sender domain through MasterBase support

1. Identify the desired From domain, account and sending product. Ask Customer Service to add that domain for a new sender.
2. Have the DNS administrator confirm that the domain has an MX record. Preserve working inbound routing; the prerequisite does not instruct you to point corporate mail at MasterBase. If a send-only subdomain has no MX, ask MasterBase for its supported design before adding one.
3. Add the confirmed MasterBase SPF permission to the domain's existing policy without removing other senders. Check the effective DMARC policy rather than replacing it with a starter.
4. Obtain the DKIM configuration supplied for the domain, publish exactly those public records, and complete the provider's validation and activation instructions.
5. Ask for confirmation that the sender is enabled and the intended branded key is active on the actual sending route. Verify a received message before production use. Official domain-addition requirements

Keep the domain-addition request and the DNS handoff together so support can identify the account, owner names and completed changes. You can also use your Customer Success Manager, as MasterBase's authentication article recommends. The public help center does not supply a universal self-service DKIM activation button.

Request the complete account-specific record set

MasterBase's authentication article says customers should contact their Customer Success Manager for detailed setup instructions. Use that established account channel and identify the exact From domain and sending product. The request below is a preparation checklist, not a message already sent. Official setup contact route

Ask for one unambiguous set of owner, type, value and purpose rows. If a supplied template uses another customer's domain, an unexplained selector or a truncated key, resolve that before publication. Do not generate a replacement key unless MasterBase specifically supports that workflow and explains how the corresponding private key will be installed securely.

Public product pages describe capabilities, not the exact values issued to your account. Likewise, an old setup document hosted by another organization cannot establish the current DKIM or bounce configuration for MB3 and Relay. Use the first-party SPF permission below and resolve any account-specific differences with MasterBase.

Handle SPF as an envelope policy, not a From-address badge

SPF checks whether the connecting server may use the domain in the SMTP MAIL FROM identity for ordinary messages. That identity usually appears in Return-Path and in the receiver's smtp.mailfrom result. It need not be the domain recipients see in From. SPF identity

MasterBase's official SPF help page documents include:spf.masterbase.com. Its full example is shown below for reference, not as a replacement for an existing policy:

v=spf1 a mx include:spf.masterbase.com ~all

The a and mx mechanisms authorize additional addresses. Check their need rather than adding them blindly. Retain the existing qualifier unless the domain owner approves a separate change. MasterBase SPF configuration

For the supported account-domain flow:

1. Read the record at the exact specified owner, not automatically the root domain.
2. Inventory every legitimate sender already authorized there.
3. Merge the confirmed mechanism into one valid v=spf1 TXT policy before the terminal all mechanism.
4. Preserve required authorizations, unrelated TXT records and the deliberately chosen final qualifier.
5. Validate the complete nested dependency chain before sending.

Do not create a second SPF policy. Subdomains do not inherit root-domain SPF. The limit is ten evaluated DNS-query-causing terms, including nested includes and redirects, rather than ten visible includes. ~all yields softfail for an unmatched sender, not pass; a fixed waiting period cannot repair invalid syntax or duplicate policies. SPF evaluation and limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

If MasterBase supplies a bounce-domain CNAME, do not put an additional SPF TXT record at the same owner. Preserve the exact issued alias and inspect its resolved SPF behavior. Do not invent a bounce hostname or copy one from another account. A passing SPF result for a provider-owned envelope domain can remain unaligned even when the From domain has a valid SPF record.

Publish only the issued DKIM public record

DKIM uses the signing domain in d= and the selector in s= to find a public key at SELECTOR._domainkey.SIGNING-DOMAIN. The public record verifies a signature made with a private key on the sending system. A record's existence does not prove that the correct private key is active. DKIM selectors and signing

For MasterBase, obtain the actual selector, type and complete value before using this naming pattern. It is not a claim that the literal selector is SELECTOR, nor a recommendation for a particular provider selector.

• If the issued type is TXT, publish the full public-key value without truncation or guessed repairs.
• If it is CNAME, publish the exact target hostname. Do not add a TXT key at the alias owner.
• Preserve other senders' selectors. Resolve an occupied owner with the provider rather than deleting an unfamiliar record.
• Confirm the provider's activation and validation steps before testing the production route.

A long TXT value can be split into quoted character strings inside one DNS record; DKIM concatenates those strings. Multiple separate competing key records are different. Do not publish a private key, credential or password in DNS. DKIM key representation

Map the full DNS owner to the right zone

The following examples explain DNS placement only. They are not a MasterBase record set.

If your panel expects full names, enter them in that form and inspect the saved owner for a duplicated suffix. @ refers to the currently open zone's apex. Publish below a child-zone delegation at the child's authoritative nameservers, preserving the parent NS records. DNS authority

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

Do not create a normal CNAME at a zone apex or at an owner already carrying A, AAAA, MX or TXT data. A website or mailbox record is not safe to remove merely to accommodate a new alias. Choose a provider-supported unused name or plan a deliberate migration. DNS alias constraints

Where an issued CNAME must remain visible for authentication, avoid proxying and flattening it. Cloudflare can flatten a DNS-only CNAME too; check its per-record and zone-wide options with the DNS administrator. Cloudflare CNAME verification

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. 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 DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Preserve DMARC and arrange approved reporting

DMARC passes when at least one authenticated path passes and aligns: SPF with the envelope domain, or DKIM with the signing domain. Relaxed alignment permits the appropriate organizational-domain match. Strict aspf=s or adkim=s requires the relevant authenticated domain to match the visible From domain exactly. A branded tracking link and Reply-To do not enter this comparison. DMARC alignment

Inspect the effective policy for the exact From domain, including applicable parent policy. Keep existing enforcement and reporting. Do not replace quarantine or reject with none, or introduce a weaker child policy, simply to accommodate a new service. Do not remove strict alignment without reviewing the actual message identities and the effect on other senders. DMARC discovery

Only where no established applicable policy exists, an approved monitoring rollout could use this example after replacing the destination:

For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The report destination must be real and managed. A minimal p=none without rua does not request aggregate reports. An external report processor may need to authorize receiving reports for your domain. Review privacy and access before adding any external or forensic-report destination. Use reports to identify legitimate sources and fix failures before an enforcement decision. Aggregate reporting

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Verify the configuration after MasterBase supplies it

DNS acceptance

Replace uppercase placeholders with confirmed values. Run only the queries relevant to the issued record types; these are diagnostic examples, not measured results.

dig NS ZONE +short
dig @AUTHORITATIVE-NS SENDER-DOMAIN MX +noall +answer
dig @RECURSIVE-RESOLVER SENDER-DOMAIN MX +noall +answer
dig @AUTHORITATIVE-NS SPF-OWNER TXT +noall +answer
dig @AUTHORITATIVE-NS SELECTOR._domainkey.SIGNING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS SELECTOR._domainkey.SIGNING-DOMAIN CNAME +noall +answer
dig @RECURSIVE-RESOLVER SELECTOR._domainkey.SIGNING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS _dmarc.FROM-DOMAIN TXT +noall +answer
dig @RECURSIVE-RESOLVER ACTUAL-MAIL-FROM-DOMAIN TXT +noall +answer

For the required MX check, SENDER-DOMAIN is the exact domain being added, not automatically the organizational root. Require an MX answer at that owner whose preference/priority number and target hostname match the DNS administrator's approved inbound configuration; compare both authoritative and recursive answers. Preserve working corporate routing. A missing or unexpected MX answer requires resolution with the DNS owner and MasterBase, not an invented provider MX or a change to existing mail routing. MasterBase sender-domain prerequisites

Compare the complete MX priority/target set at that exact owner with the separately approved inbound-routing plan, not merely any nonempty MX answer. Resolve extra, missing or unexpected entries before accepting the configuration. An account packet is not authorization to redirect incoming mail.

Require exact issued owners and values, one valid SPF policy where required, a usable DKIM key and the intended DMARC policy. Check authoritative answers and then relevant recursive caches. If output is blank, query again without shortening options to distinguish no data, NXDOMAIN, timeout and SERVFAIL. Follow child-zone or selector delegation to the real authority.

Delivered-message acceptance

After provider activation, send harmless content through the actual MB3 campaign or Relay application to controlled external recipients. Save the original received message and inspect the trusted receiver-added Authentication-Results. A familiar authserv-id or a header's position is not proof of origin: both can be forged. Use only results your receiving system or administrator confirms were added inside its trusted boundary, with untrusted look-alike fields removed. Authentication-Results trust boundary

Require all of the following:

• The expected visible From domain, not an unexpected fallback identity.
• The intended branded DKIM signature passes and aligns under the applicable alignment mode, with its actual d= and s= recorded.
• The actual SPF identity, connecting IP and result are recorded, including whether a pass aligns.
• DMARC passes for the intended From domain through an identified aligned passing path.
• Any promised custom Return-Path is actually used on that route.
• Replies and other enabled message functions behave as intended.

A DMARC pass on SPF does not demonstrate working branded DKIM. A vendor-domain DKIM pass is not a substitute for the intended signature. A genuine SPF error also needs attention even when DKIM makes DMARC pass. DMARC authentication requirements

For SPF fail, softfail, neutral, none, temperror or permerror, investigate the exact envelope owner and authorization/DNS chain. Do not dismiss those results as “unaligned.” For provider-controlled DNS, retain the timestamp, connecting IP and receiver result for MasterBase. Compare a direct message with any forwarded sample before broadening the origin policy.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Troubleshooting and questions to resolve

Do not weaken domain-wide protection or remove working keys as a shortcut. Keep old records until the provider's rotation or retirement process confirms that they are no longer needed.