beMail SPF, DKIM and DMARC setup, step by step

To authenticate a sending domain in beMail, obtain the domain-specific DNS instructions from beMail, publish the supplied SPF authorization and DKIM public records without disrupting existing mail, and have beMail verify the DNS. Authentication is built into the platform, not a separate switch you need to discover. Finish by checking a delivered native campaign for the intended branded DKIM signature and DMARC alignment. beMail’s authentication guide and deliverability documentation describe this provider-assisted arrangement.

This guide covers beMail, the Italian platform operated by Ketchup Adv, sending native marketing campaigns. It does not cover beMail.ro, another product with a similar name, or configuration of beMail’s separate transactional SMTP/API flow. Connecting Shopify or another website is also outside this authentication procedure.

These are documentary instructions, not a claim that a customer account, DNS zone or campaign has been tested.

On this page

• What settings does beMail provide?
• 1. Prepare the domain and request the complete packet
• 2. Map each record to authoritative DNS
• 3. Reconcile SPF and publish the issued DKIM records
• 4. Preserve DMARC and authorize reporting
• 5. Have beMail verify the domain
• 6. Test a real campaign and its identities
• Troubleshooting
• Rollback and ongoing changes
• Frequently asked questions
• Sources and verification limits

What settings does beMail provide?

beMail says it generates DKIM keys for your domain, supplies the SPF include and a recommended DMARC record, and checks that the DNS records are published correctly. Obtain those instructions through your existing beMail service contact or onboarding process. The public pages do not establish a self-service domain-authentication menu, a universal selector, a fixed record count or a customer-independent SPF include. Source: beMail authentication.

The roles are different:

• SPF authorizes sending infrastructure for the SMTP envelope domain. It does not sign a message or directly authenticate the visible From address.
• DKIM signs message content and selected headers. beMail holds the signing key; you publish the supplied public verification record or supported delegation.
• DMARC checks whether a passing SPF or DKIM identity aligns with the visible From domain and expresses the domain owner’s policy.

Some beMail marketing copy describes all three as signatures. Only DKIM is a cryptographic signature. A DNS configuration can also be correct while a particular message uses a different identity, so publication and delivered-message acceptance are separate checks. SPF specification, DKIM specification, DMARC alignment.

1. Prepare the domain and request the complete packet

You need an existing beMail account/service arrangement, permission to use the intended campaign From domain, and access to its authoritative DNS or the person who manages it. beMail lists Admin, DPO and trafficker roles, but its public documentation does not assign domain-authentication privileges to a particular role. Do not assume a menu is missing because you need a specific upgrade. Source: beMail platform.

Before changing anything, save the current DNS records and TTLs, identify other legitimate senders, and record any _domainkey delegation and direct or inherited DMARC policy. Decide the intended visible From address with the campaign owner.

Ask beMail to provide or confirm:

• The exact domain and account covered, including whether a proposed sending subdomain is supported.
• Every record’s complete DNS owner, type, full value or target, and any required TTL.
• The SPF authorization and the precise domain on which SPF will be evaluated. Do not assume it is the website’s apex.
• The expected DKIM signing domain and selectors, including rotation or coexistence requirements.
• The supported campaign From identity, the envelope-domain relationship, and how beMail will confirm publication.
• Any reporting destination it recommends, so the owner can approve that data sharing separately.

Pause if the packet is incomplete or conflicts with an existing sender. The October 2026 educational article explicitly labels its domains and IP address as fictional; its shortened DKIM key is not publishable. Neither that example nor an infrastructure IP list replaces your customer packet. Never request or publish beMail’s private signing key.

2. Map each record to authoritative DNS

Make changes where the relevant DNS zone is actually hosted, which may differ from the domain registrar or website host. Work from each full owner name, then translate it into the DNS editor’s Host/Name format. Editors that append the zone name can otherwise create a doubled suffix.

For illustration only, suppose beMail issues a DKIM owner of assigned-selector._domainkey.news.example.com:

• In the parent example.com zone, a relative-name editor needs assigned-selector._domainkey.news.
• If news.example.com is separately delegated, its authoritative zone needs assigned-selector._domainkey.
• If _domainkey.news.example.com itself is delegated, the responsible child zone needs assigned-selector.

These are naming examples, not a beMail selector recommendation. Use the actual packet and preserve existing NS delegations. Adding a record to the parent does not bypass a child zone’s authority. If an occupied owner belongs to another sender, resolve the collision with that service and beMail rather than replacing it.

Do not change inbound MX routing, parent nameservers, DNSSEC, website addresses or credentials merely to reproduce an authentication example. If a packet unexpectedly requests a routing or delegation change, obtain an explanation and an approved change plan before proceeding.

Only if beMail issues a CNAME

Publish the exact alias target, with no conflicting TXT, A, AAAA, MX or second CNAME at that owner. Use DNS-only rather than an HTTP proxy. Where the DNS host offers per-record flattening, set Flatten off for the issued alias. Check applicable whole-zone, apex and same-zone flattening rules too: they must not suppress the CNAME that beMail expects to verify. Do not disable unrelated global features blindly; coordinate shared changes or ask for a supported alternative while preserving existing delegations. CNAME rules, Cloudflare proxy behavior, flattening behavior.

A CNAME is only a conditional branch here. The public beMail instructions do not establish that every customer receives CNAMEs.

3. Reconcile SPF and publish the issued DKIM records

SPF: preserve the existing sending inventory

At the SPF owner confirmed by beMail, inspect the existing TXT records. There must be only one record beginning v=spf1 at that owner. Add the beMail authorization to that policy through the DNS owner’s normal change process; do not add a second SPF policy or replace mail-provider, CRM and other legitimate authorizations with a beMail-only example.

Preserve the intended qualifiers and termination behavior. An all mechanism makes redirect ineffective, so appending -all to an existing redirect-based policy can silently remove the authorizations supplied through that redirect. Have the administrator reconcile the complete policy rather than mechanically concatenating two records. If no SPF policy exists, obtain the complete intended policy and confirm that it covers all legitimate senders using that owner. SPF publication and evaluation.

Check the evaluated DNS-dependent term budget after the change. The limit is ten across include, a, mx, ptr, exists and redirect, including nested evaluation, not ten visible includes in the top-level string. Exceeding it produces permerror. Neither -all nor ~all guarantees how a receiver delivers or rejects mail. RFC 7208 section 4.6.4.

DKIM: publish the complete public value

Use the type and full value beMail supplies. For a TXT key, retain all supplied tags and the complete p= value. A DNS editor may represent a long TXT record as several quoted strings within one record; those strings are concatenated. Do not split the key into separate competing TXT records, paste an ellipsis, or substitute an independently generated key. DKIM key publication.

Keep other services’ selectors intact. For an existing beMail selector, ask whether the instruction is initial setup, a correction or coordinated rotation before overwriting it.

4. Preserve DMARC and authorize reporting

Inspect _dmarc for the intended visible From domain and determine whether an applicable policy is inherited. Retain existing protection, alignment settings and authorized report destinations. beMail’s recommended record is an input for review, not permission to replace a working p=quarantine or p=reject policy with p=none. Do not publish duplicate DMARC records. DMARC policy discovery.

Only if there is no direct or applicable inherited DMARC policy, and the domain owner approves a monitored first policy, this is an illustrative starting shape for a From domain of example.com:

Type: TXT
Full owner: _dmarc.example.com
Relative host in the example.com zone: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox with the approved real values. Create the reporting mailbox or service arrangement first. For news.example.com, the full direct-policy owner would be _dmarc.news.example.com: enter _dmarc.news in the parent zone or _dmarc in a delegated news.example.com zone. Do not add that child policy casually if a parent policy already applies. Monitoring does not itself request enforcement against unauthenticated mail; stronger policy is a separate decision after all legitimate sending paths are accounted for.

When a report destination’s Organizational Domain differs from that of the domain where the policy was found, the report-generating receiver must check external-destination DNS authorization. A destination within the same Organizational Domain is excepted, even if its hostname differs. The reporting service publishes the applicable authorization, not an arbitrary TXT record at your sending domain. RFC 9990 section 4.

That protocol check does not replace privacy approval. Aggregate reports expose sending-source and authentication information. Confirm the recipient, access, retention and permitted use before adding beMail’s proposed reporting mailbox or another processor. Never copy a reporting address from an example or send message samples containing customer data without authorization. Aggregate-report privacy.

5. Have beMail verify the domain

After publication, check both the authoritative answer and a recursive resolver. These commands are templates: replace every uppercase placeholder with the exact packet value or a resolver you administer/trust. Run only the query type actually issued.

dig @AUTHORITATIVE_NAMESERVER SPF_OWNER_FROM_BEMAIL TXT +noall +answer
dig @RECURSIVE_RESOLVER SPF_OWNER_FROM_BEMAIL TXT +noall +answer
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FROM_BEMAIL TXT +noall +answer
dig @RECURSIVE_RESOLVER DKIM_OWNER_FROM_BEMAIL TXT +noall +answer

For an issued CNAME, use CNAME instead of TXT to inspect the alias, then check that its target resolves to the expected verification data. Compare the complete owner, type and value with the packet, not merely whether an answer exists. For TXT, account for normal string concatenation. Empty answers, SERVFAIL, stale values or an unexpected target are not successful verification.

Tell your beMail service contact that publication is ready for its check, and have beMail confirm the intended domain’s DNS. The provider says it verifies records and describes authentication as always enabled. There is no documented extra self-service signing toggle to invent. Allow for actual TTL/cache behavior and use beMail’s current guidance if verification remains pending; the public procedure does not promise a fixed completion time. Sources: authentication, always-on protections.

6. Test a real campaign and its identities

Once beMail confirms setup, send a small, authorized native campaign through the intended account and From configuration to controlled valid recipients. A preview or test-send function is useful, but if it uses a different route, also test the actual campaign path. Do not send to a customer list merely to test authentication.

At the receiving service, use its receiver-controlled authentication diagnostics, or have its administrator establish the actual trusted processing boundary and confirm that externally supplied Authentication-Results fields are stripped or reliably distinguished. Ignore untrusted results. A familiar authserv-id, a header’s position or a sender-inserted dkim=pass is not sufficient provenance. RFC 8601 section 7.1.

Keep the original received message and verify:

1. Visible From: the intended brand address remains intact, rather than being replaced with a provider-domain address.
2. Intended DKIM: identify beMail’s expected signature, keeping its d= signing domain and s= selector together. The receiver must report dkim=pass for that signature, and its domain must align with the intended From under the current adkim policy.
3. DMARC: the trusted receiver reports dmarc=pass for that visible From. A pass obtained only through SPF does not prove the newly configured branded DKIM route works.
4. SPF independently: record the actual SMTP MAIL FROM domain and its SPF result. Investigate fail, temperror or permerror even if aligned DKIM allows DMARC to pass.

For selector extraction and the matching DNS lookup, see EmailAuth’s guide to finding the DKIM selector in a received message.

Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. For example, d=news.example.com can align with From: offers@example.com under relaxed DKIM alignment but not strict alignment. Apply the published adkim and aspf settings, not an assumption about subdomains. Alignment rules.

beMail’s antispam policy describes a customer envelope sender associated with a DKIM signature on the same domain and says the customer cannot replace that domain. It does not publish your literal Return-Path or prove strict alignment with your chosen From. If the observed identities do not meet the existing policy, take the evidence to beMail rather than weakening DMARC or inventing a custom envelope setting. Source: beMail antispam policy.

Troubleshooting

beMail cannot verify a record

Compare the full packet against authoritative DNS first. Check the selected zone, automatically appended suffix, existing delegation, omitted TXT characters and stale caches. For a CNAME only, check proxying, applicable flattening and alias conflicts. Send beMail the public record details and lookup timing through the existing support channel; no password or private key is needed.

DNS is correct, but branded DKIM is absent or fails

Confirm that the message came through the intended native campaign account, and compare its actual d=/s= pair with the packet. A missing signature differs from a failed signature. Ask beMail to investigate account/domain association or key rotation; if a signature exists but fails, include the receiving error and consider whether a downstream gateway altered signed content. Do not generate a replacement key yourself.

SPF fails while DMARC passes

Aligned DKIM may be carrying DMARC. Check SPF against the actual envelope owner, not automatically the From domain. permerror calls for policy syntax, duplicate-policy and lookup-budget checks; temperror calls for DNS availability investigation; fail calls for checking authorization of the actual sending path. An unaligned SPF pass is a different condition and does not establish branded SPF alignment.

Everything passes, but the campaign lands in spam

Authentication does not guarantee inbox placement. Review permission-based list quality, complaints, sending consistency and content with beMail. Its delivery statistics describe the platform’s reported performance, not a guarantee for your campaign. Its current documentation distinguishes shared Pro infrastructure from dedicated Enterprise infrastructure; a dedicated IP is not an authentication prerequisite or automatic remedy. Source: deliverability and IP choices.

Rollback and ongoing changes

If a new setup fails, pause affected campaigns rather than lowering DMARC protection. Preserve the failed-message evidence and ask beMail to identify the mismatch. Restore only the specific authorized DNS change from your saved baseline, after checking whether another sender or newly switched selector now depends on it.

During migration or key rotation, retain old working records until the responsible provider confirms that signing has switched and delayed messages no longer require them. Do not remove another platform’s selectors just because beMail is being added. Recheck a controlled campaign after a From-domain change, DNS migration, packet update or sending-route change.

On offboarding, coordinate the end of beMail sending, removal of only its no-longer-needed authorizations, and any reporting arrangement. Keep the rest of the domain’s SPF, DKIM and DMARC intact.

Sources and verification limits

The provider workflow comes from beMail’s SPF/DKIM/DMARC article, deliverability page, antispam policy, platform overview and [pricing](https://www.bemail. Protocol references above govern the distinctions between publication, signatures, alignment and trusted receiver results.

No customer-specific DNS packet, account entitlement, live DNS configuration or delivered campaign was tested for this guide. Those checks remain necessary before treating a particular beMail setup as working.