Robly SPF, DKIM and DMARC setup, step by step

To set up Robly authentication, create a brand, publish the DNS records Robly generates, verify every record, and select that brand in the campaign’s From settings. Review the documented SPF authorization without replacing other senders. Finish by confirming the intended branded DKIM signature passes and aligns, checking SPF independently, and verifying a trusted receiver’s DMARC pass.

The retrieved support bodies did not expose a publisher update date. No Robly account was configured, no customer DNS was queried or changed, and no campaign was sent for this guide. The steps below describe documented behavior and the evidence you should collect.

What this guide covers

This is the Robly-managed marketing campaign workflow. Robly’s pricing page lists Custom Branding among email features; the authentication instructions do not establish a separate authentication tier requirement. Confirm your own account’s permissions and available Branding controls before scheduling a migration. Pricing, legacy account terms and feature access can change.

Robly also links to transactional developer documentation. The transactional page linked from pricing could not be retrieved during this review, so this guide does not claim its campaign settings configure every transactional API or custom SMTP route. For application mail, first establish which service actually transmits it and obtain the route’s current authentication instructions. An API integration alone does not prove which brand, envelope domain or DKIM key the message uses.

Use a domain you own and can manage. Robly’s Branding instructions exclude freemail domains such as Gmail, Yahoo and AOL from custom Branding. If using a subdomain, confirm the exact accepted From-domain configuration in your account rather than assuming authentication of a parent automatically covers it.

Prerequisites and a safe DNS inventory

Have access to Robly’s account settings, the authoritative DNS zone, and a controlled receiving mailbox. The person who owns the domain policy should approve any DNS changes. Record existing SPF, DKIM and DMARC data first, including other tools sending as the same domain.

Choose an unused link subdomain. A name already serving a website, redirect or another platform may conflict with the CNAME Robly needs. Do not remove the existing service merely to clear a validation error. DNS changes belong at the authoritative provider, which is not necessarily your registrar or website host.

Capture these identities before and after setup:

• Visible From domain, which DMARC evaluates.
• Envelope MAIL FROM domain, normally reflected in Return-Path and the trusted receiver’s smtp.mailfrom field.
• DKIM signing domain d= and selector s=.
• Branded link hostname, which serves a different purpose from message authentication.

A branded URL can be working while DKIM is wrong. Conversely, a correctly signed message does not prove every tracking link works.

Create the Robly brand and retrieve its records

In My Account > Settings > Branding, choose Add New Brand. Enter the brand label, From domain and link subdomain, then save. The official workflow generates four DNS rows: three CNAME records and one TXT record. Copy only the actual rows for your account. If the current UI supplies a materially different set, stop and confirm its scope with Robly rather than forcing a tutorial pattern. Do not copy another organization’s target or selector.

For each row, record its exact type, full owner, TTL and complete target or tagged TXT value, alongside the brand identifier and issue date. Publish only the public values Robly provides. A generated public DKIM record is appropriate for DNS; a private key or account credential is not. Repeat setup for each brand rather than assuming that one brand’s DNS authenticates a different domain.

Map the account’s full owners to the authoritative zone. The documented screenshot uses a TXT for DKIM and CNAMEs for other brand records; preserve the actual issued type. The following table is illustrative; replace ISSUED_SELECTOR with each actual selector, not a guessed universal Robly label.

For a hypothetical link or bounce owner ISSUED_LABEL.news.example.com, use ISSUED_LABEL.news in the parent zone or ISSUED_LABEL in the delegated child, not the _domainkey zone. Preserve NS delegations and contact their operators rather than removing them. Check the final saved name for duplicated suffixes. A CNAME cannot share its owner with ordinary TXT, MX, A/AAAA or a second CNAME. Do not change inbound MX, parent nameservers, DNSSEC or unrelated website records merely to complete Branding.

Keep required authentication aliases and issued link-branding aliases where Robly verification requires literal CNAME answers DNS-only and unflattened, returning the account’s literal CNAME target. In Cloudflare, turn the affected record’s Flatten option off where available and ensure applicable zone-wide settings do not conceal these aliases. Flatten-all overrides the record-level choice, so coordinate any relevant zone change and assess shared dependencies. Do not independently alter supported website or HTTPS configuration. Mandatory apex or same-zone flattening may have no off switch; if the required answer cannot be preserved, stop and arrange a supported configuration with the DNS operator and Robly. Cloudflare flattening controls and domain-verification guidance

Verify the brand, then select it for the campaign

After publication, select I’ve added these records and click Verify. Every generated row should reach Valid. If a row fails, use Debug Validation, select I’ve added these records, and run Debug to inspect the row-specific explanation. Allow for DNS caching, but investigate a wrong authoritative answer immediately rather than merely waiting.

Then open Email > Campaigns, choose the campaign, and go to the builder’s Settings step. Edit From under Content, select the intended Brand, and save with Save From. Robly says the From and Reply-to addresses must match the selected brand domain. Review any prefilled values and fill blank fields with approved addresses. Selecting No branding restores the original From, Reply-to and link settings. These are explicit parts of Robly’s documented campaign workflow.

Robly’s Options > Edit changes the brand name, not its From domain or link subdomain. Plan a supported replacement if those need to change; do not delete a working brand or aliases used by old campaign links without reviewing dependencies. A default brand is convenient but not evidence that an existing or duplicated campaign has the correct selection. Check the campaign you will actually send. A domain can be valid in account settings while a campaign still uses a different configuration.

Review SPF without replacing your other senders

Robly’s SPF instructions document include:_spf.robly.com. If applicable to your sending configuration, insert this mechanism into the existing SPF policy before its final all mechanism. Keep legitimate authorizations for staff mail and other services. Do not add unnecessary a or mx mechanisms just because a tutorial includes them, and do not replace an established hard-fail or soft-fail ending without a separate decision.

SPF evaluates the envelope identity, not the visible From address; HELO applies in cases such as a null reverse path. SPF identities If the delivered campaign uses a Robly-controlled MAIL FROM domain, editing your root-domain SPF does not by itself create SPF alignment. Check whether aligned DKIM supplies DMARC. Ask Robly to clarify an unexpected envelope domain rather than inventing a custom return-path setup from its link-branding fields.

Apply RFC 7208 when interpreting older SPF tutorials:

• Publish one v=spf1 policy per owner name, not one policy per sending service.
• The limit is ten evaluated DNS-querying terms, including nested includes and applicable a, mx, exists, ptr and redirect evaluation. It is not merely ten include strings.
• A DNS TXT character-string is limited to 255 octets, but one TXT record can contain multiple strings. Splitting a long policy into separate SPF records is invalid.
• Any all mechanism makes redirect ignored, irrespective of qualifier. Preserve redirect-only control flow; do not append all or concatenate whole policies when merging an authorized sender. SPF precedence Qualifiers do not guarantee the receiver’s final disposition.
• A public DNS syntax check cannot prove that a particular connecting IP was authorized for a particular received message.

If no SPF policy exists, inventory all legitimate senders before creating one. A Robly-only example may omit your normal mailbox provider. Avoid unmanaged flattening that freezes provider IP ranges and goes stale.

Keep DMARC aligned and preserve established policy

DMARC’s current standard, RFC 9989, requires at least one passing authentication identity aligned with the visible From domain. DKIM uses the signature’s d= domain; SPF uses the authenticated MAIL FROM domain. Under relaxed alignment, domains can share the same organizational domain. Under strict adkim=s or aspf=s, the relevant domain must match exactly. For example, visible From news@example.com and a passing intended DKIM signature with d=mail.example.com align in relaxed mode (assuming the same Organizational Domain), but not strict mode. A passing d=example.com aligns under either mode. These are hypothetical identities, not observed Robly results.

Keep any existing applicable policy, including inherited subdomain policy. Do not replace p=reject or p=quarantine with p=none to make a campaign send. Fix the brand, signing or envelope configuration instead.

Only if there is no direct or applicable inherited DMARC policy at all, including p=none, a first-policy rollout with the domain owner’s explicit approval of the monitoring plan can begin after authentication and the legitimate-sender inventory are ready. For a fictional From domain example.com, publish one TXT record at _dmarc.example.com with v=DMARC1; p=none. In a zone editor that appends example.com, use _dmarc as the host. For From news.example.com, the local full owner is _dmarc.news.example.com: use _dmarc.news in the parent example.com zone or _dmarc in the delegated news.example.com zone, not a _domainkey zone. Never copy the example domain literally.

That minimal value does not request reports. For aggregate monitoring, add the exact rua=mailto: destination from your approved reporting service or mailbox. When the report destination has a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not trigger this requirement. Use the report service’s issued authorization rather than guessing it. RFC 9990 section 4 This protocol check does not replace the domain owner’s data-sharing approval. Review recipient, privacy, access, retention and responsibility for report analysis. Do not send reports to a copied address. Review all legitimate routes and subdomains before enforcement. RFC 9989 section 7.4 requires valid DKIM signatures for domains publishing p=reject; assess indirect-route interoperability rather than treating a successful direct campaign as evidence for every path. Interoperability requirements p=none requests no DMARC-specific disposition, but receivers may still reject mail for other reasons.

pct is obsolete under the current standard and should not be used as an enforcement rollout plan. RFC 9990 specifies aggregate reporting. RFC 9991 covers failure reporting; use that only after reviewing potential disclosure of message and recipient information.

Validate public DNS and a delivered campaign

Replace the fictional names below with the exact owners generated for your brand, your actual authoritative server and the envelope domain found in received mail. These commands only read DNS:

dig @ns1.example.net TXT selector._domainkey.example.com +noall +answer
dig CNAME ISSUED_SPF_ALIAS_OWNER +noall +answer
dig TXT selector._domainkey.example.com +noall +answer
dig CNAME links.example.com +noall +answer
dig TXT example.com +noall +answer
dig TXT _dmarc.example.com +noall +answer

Query all four generated rows with their correct record types, not only the illustrative selector above. Confirm CNAME targets exactly match Robly’s values and resolve to the expected records. Compare the complete generated TXT row with DNS. Multiple component strings of one TXT record concatenate without inserted spaces and are not independent keys; preserve the full tagged value and character order. DKIM TXT representation Check the SPF owner actually used by the message and confirm there is one policy. An empty answer requires examining full query output for DNS status and errors; it is not automatically proof that the record does not exist.

After Robly validation and campaign selection, send to a controlled recipient through the real campaign path. Inspect the receiving service’s Authentication-Results within the RFC 8601 trust boundary; an arbitrary header inserted earlier in transit is not reliable evidence. Establish the actual receiving processing boundary through provider documentation or the receiving administrator, including how external Authentication-Results are removed or isolated from trusted fields, or obtain an authenticated receiver trace. A familiar authserv-id or position near the top alone proves nothing. Leave acceptance pending if provenance is unresolved. Record the receiver identity, intended From domain, DKIM header.d and selector, and the SPF result with smtp.mailfrom.

For completion of this DKIM setup, require the intended custom-domain DKIM signature to pass and align with the visible From domain under the published alignment mode, as well as a trusted receiver’s dmarc=pass. A rewritten provider From does not count as successful authentication of the intended brand. Robly documents send-robly.com alias handling for freemail senders; inspect the actual received identity rather than treating that fallback as branded-domain success. Robly freemail handling SPF-only DMARC success is valid protocol behavior but does not prove that the DKIM work succeeded. Investigate any SPF fail, permerror or temperror independently even when aligned DKIM carries DMARC; record the cause and repair the applicable route before treating SPF as complete.

Keep a small acceptance worksheet for each brand and route: campaign name, selected brand, visible From, Return-Path, DKIM domain and selector, SPF result, DKIM result, DMARC result, DNS check time and receiver. Mark a route accepted only after the identities and results agree. Check branded links separately. A receiver’s SMTP acceptance, Robly’s Valid status and inbox placement are different outcomes.

Troubleshooting common Robly problems

Brand is Valid but the campaign looks unbranded: inspect the campaign’s Brand dropdown. Check for No branding, stale settings or the wrong brand on a copied campaign.

From or Reply-to is blank after selecting a brand: use an approved address matching that domain. Do not fill the field with a personal mailbox on a different domain to bypass the mismatch.

One generated record is invalid: use Debug Validation, then check its full DNS owner, type and target. Look for a duplicate suffix, CNAME conflict or truncated TXT value before regenerating anything.

SPF passes but DMARC fails: compare the MAIL FROM domain with From and inspect DKIM independently. A pass for a provider domain is not an aligned SPF pass for your brand.

DKIM is absent or uses an unexpected domain: confirm the actual selected brand and route; compare the signature’s selector with the account-generated DNS. Revalidate and send a fresh sample after fixing the specific issue.

Everything passes but mail lands in spam: review consent, complaints, list quality, content and sending patterns. Do not weaken authentication or promise inbox placement as a DNS outcome.