emBlue SPF, DKIM and DMARC setup, step by step

To authenticate emBlue campaign email, confirm your sender domain, add the required SPF authorization, publish the confirmed DKIM records and bounce CNAME, and check the domain in emBlue. Then verify a real message: a dashboard check or sender-address confirmation does not prove aligned SPF, DKIM or DMARC at the receiver. emBlue authentication guide

This guide concerns emBlue's documented email-campaign route. It does not configure your employee mailbox service, unrelated SMTP integrations or every product carrying the emBlue name. No customer account was changed, no DNS was published and no delivery test was performed.

For the distinct employee-mail route, see the Microsoft 365 authentication guide; its tenant settings do not activate emBlue campaign signing.

Prepare the sender and DNS access

Identify the exact From domain, reply address and account that will send campaigns. You need control of the domain's authoritative DNS and access to emBlue sender configuration. An address at a public mailbox provider does not give you DNS control of that provider's domain.

Save your current records, especially SPF, all DKIM selectors and DMARC. Make a list of legitimate sending services before merging any authorization. Keep a worksheet with each record's full owner, type, value, purpose, previous value and TTL.

The emBlue guide describes checking senders under Remitentes y dominios → Mis remitentes, with Ver detalle exposing additional status. It also links to a domain validator. Those checks help with setup but are not substitutes for a received-message test. emBlue sender and domain status

Confirm any account-specific or regional variation with emBlue before reusing public examples. The reviewed guide is not proof that every sending product or account uses an identical signing key.

To register a sender, open Remitentes y dominios → Agregar remitente, complete the sender details and select Guardar. Use Verificar este e-mail in the verification message sent to that mailbox. This establishes control of the address; domain DNS validation remains a separate task. Creating and verifying an emBlue sender

Know which documented values require confirmation

The official page describes this configuration:

These labels come from the current official configuration page. The page publishes a long public key, but this guide deliberately does not offer that key as a universal copy-and-paste value. Have emBlue confirm the selector, full key and applicable domain for your account. Do not generate your own key unless emBlue supplies a supported signing workflow for it.

The short _domainkey record is not a selector-specific DKIM public key. Its presence cannot establish that a modern DKIM signature passes. Validate the key at the selector actually used in the message. DKIM key lookup and signatures

Add SPF without replacing other senders

The provider's example includes a and a soft-fail ending. Do not copy that entire example over an established policy. Add the approved emBlue include to the existing policy at the correct owner, retaining other legitimate authorizations and the current terminal behavior. Do not add an a mechanism unless authorizing the domain's address records is intentional. emBlue SPF instructions

SPF checks the MAIL FROM identity, not merely the visible From or reply-to address. Record the intended owner during setup, then verify it against the receiver's smtp.mailfrom. A root-domain authorization does not automatically become an independent subdomain's SPF policy.

There must be only one v=spf1 TXT policy at the evaluated owner. An include after all cannot provide the expected authorization. Preserve a stronger existing -all rather than changing it to match a vendor example. Evaluate the full path, including nested includes and redirects, against the limit of ten evaluated DNS-lookup-causing terms. This is not a simple count of all DNS packets or just the visible includes. SPF rules

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

If you do not know which owner your account's envelope sender uses, resolve that question with emBlue instead of adding the same record to multiple domains and hoping one works.

Publish the confirmed DKIM and bounce records

Use the exact key confirmed for the account. Preserve the TXT content, including its complete p= value, without introducing spaces inside the encoded key. DNS editors may display a long TXT value in multiple quoted chunks; the relevant question is whether those chunks concatenate into the intended single value. Do not publish multiple competing keys at the same selector owner.

Check how your DNS editor treats names. A relative owner such as epexo._domainkey is appropriate only when the editor adds the intended zone. A duplicated domain suffix causes a lookup at the real selector to miss the record entirely.

Only if emBlue confirms this child sending domain is supported, apply the account-issued records as follows. For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

For the bounce CNAME, use the account-confirmed owner and destination. Do not place it over a hostname already used by another sender or alongside conflicting A, MX or TXT records. Keep it DNS-only and unflattened when the platform must read the CNAME. Cloudflare CNAME verification guidance

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

The bounce alias is not the DKIM selector. Do not infer that publishing it changes the signing domain or guarantees DMARC. The received MAIL FROM and DKIM-Signature are the evidence for which identities are actually used.

The official guide's root-domain validator guidance is specific to its described workflow. If you intend to send from a subdomain, ask emBlue to confirm support and exact records before adapting root-domain instructions. Do not remove other domains' records to make a validator indicator green.

Check DNS and emBlue status

Replace each uppercase placeholder with your confirmed complete domain or selector. These commands do not change DNS:

dig +short TXT SPF_OWNER
dig +short CNAME bounce.SENDER_DOMAIN
dig +short TXT epexo._domainkey.SENDER_DOMAIN
dig +short TXT _domainkey.SENDER_DOMAIN
dig +short TXT _dmarc.SENDER_DOMAIN

If emBlue confirms a different selector or bounce owner, query that value instead. Expect a single usable SPF policy at its owner, the agreed bounce target and a complete public key at the signing selector. Querying the short _domainkey TXT is a separate record check, not a DKIM-signature test.

If results are absent or stale, inspect the domain's authoritative nameservers and exact owner first. Compare their answers with recursive resolvers. An inactive zone at the registrar will not fix a domain delegated elsewhere. Existing TTLs and negative caching affect propagation, but waiting cannot correct a spelling error.

The official guide allows up to 24 hours for changes to appear and describes green checks in the sender panel. Recheck the sender details after DNS is visible, and contact emBlue if the account does not recognize correct records. Do not declare success solely because the waiting period has elapsed. Status and timing guidance

Verify the actual campaign message

Send an authorized test from the intended emBlue sender through the campaign route you will use. Inspect the original headers at a receiving mailbox without forwarding it first. Record the test timestamp, message identifier and receiver.

Use the receiver's own trusted Authentication-Results, not any similarly named header inserted outside its trust boundary. Authentication-results trust model

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For completion of this branded DKIM setup, require a passing aligned signature for the intended domain as well as a receiver DMARC pass. A DMARC pass obtained only through SPF does not prove the new DKIM setup works. Investigate SPF fail, permerror or temperror even when DKIM supplies DMARC success: inspect authorization, policy syntax or lookup limits, and transient DNS errors respectively.

DMARC requires either aligned SPF or aligned DKIM, not necessarily both. Strict alignment requires identical domains; relaxed alignment permits a shared organizational domain. A genuine provider-domain pass can still be unaligned with your From address. DMARC alignment

Authentication success is not an inbox guarantee. Check any rejection response and placement separately. Test materially different sender domains and campaign routes rather than generalizing from one sample.

Retain DMARC protection and reporting

The emBlue example uses p=none, but an existing enforcement policy should not be replaced by that example. Preserve applicable p=quarantine or p=reject settings and the approved report destinations. If no policy exists, agree on a monitored rollout after inventorying all legitimate senders.

First inspect the direct TXT policy at _dmarc.YOUR-FROM-DOMAIN and any applicable inherited policy; a missing child record does not mean no protection applies. Only when neither applies and the owner approves monitoring may a first record use the illustrative value v=DMARC1; p=none. This value alone requests no reports; add rua only with an authorized monitored destination. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

RFC 9989 is the current DMARC specification; the older pct tag has been removed. Do not rely on it for percentage-based enforcement. Aggregate reporting can help identify which emBlue and non-emBlue streams remain unaligned. Use authorized destinations and any required external reporting authorization. Aggregate reporting

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 that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Failure reports are optional and can expose personal data or message content. Do not enable them simply because a DNS example contains additional reporting tags. Failure-report privacy

Troubleshooting emBlue authentication

• SPF permerror after adding emBlue: check for duplicate SPF policies and excessive evaluated lookup terms. Preserve other senders when correcting the policy.
• The short TXT exists but DKIM fails: inspect the actual selector and complete public key. The short record cannot replace the signing-key record.
• Bounce CNAME exists but alignment fails: inspect MAIL FROM and the DKIM signer separately. The existence of a DNS alias does not prove which domain emBlue used.
• Sender confirmation succeeded but authentication is pending: sender ownership and domain authentication are separate checks. Inspect domain details and public DNS.
• Only some campaigns fail: compare selected From domains and account routes. Do not assume the sender selected in a previous campaign remains selected in every new one.
• A public example differs from account guidance: preserve existing records, collect both instructions and request a clear current mapping from emBlue before changing the key or target.