Superlogica SPF, DKIM and DMARC setup, step by step

Quick answer: For Superlógica's real-estate product, add include:_spf.superlogica.com to the appropriate existing SPF policy and obtain the domain's DKIM records through the email-history screen. Publish the actual issued records, run the platform's validation, then prove the intended signature passes and aligns in a delivered message. Do not copy another tenant's targets or treat a green configuration indicator as a delivery guarantee.

This guide covers Superlógica para imobiliárias, not Assinaturas, Condomínios or every service in the Superlógica group. No customer account, DNS change or test send was performed.

Before starting: identify the actual sending route

Confirm the product, tenant, intended visible From address and domain, and the person authorized to administer both the application and its DNS. Free-mail addresses do not give you authority to publish records for Gmail or Yahoo. Use a domain you control; changing a visible sender is a separate business decision, not an automatic workaround.

Inventory existing SPF policies, DKIM selectors, relevant direct or inherited DMARC policy, and DNS delegations. Keep a dated copy of the configuration. Determine which production workflows use this route rather than assuming every notification shares the same identity.

SPF authenticates SMTP MAIL FROM, or HELO in applicable empty-envelope cases. It does not inherently check the visible From. Confirm the evaluated domain with Superlógica and later with a trusted receiver's message evidence. If it is provider-owned, editing your apex cannot change that provider's SPF policy. Do not invent a custom Return-Path setup that the account does not offer.

Step 1: add the documented SPF authorization safely

The official Imobiliárias SPF instructions, specify this mechanism:

include:_spf.superlogica.com

At the applicable evaluated owner, inspect TXT records for v=spf1. If one exists, retain other legitimate senders and insert the approved mechanism before final all. Do not create a second SPF policy or replace corporate-mail authorizations. If policies are duplicated, consolidate only after the administrator inventories every legitimate sender.

For a genuinely new policy, after that inventory confirms no other authorizations are required, the provider's example is:

v=spf1 include:_spf.superlogica.com ~all

This is not a replacement template for an existing policy. Preserve its qualifiers unless a separately approved review changes them. Neither ~all nor -all guarantees how a receiver delivers a message. An existing redirect is ignored when all is present; do not accidentally disable an intentional redirect design.

SPF has a budget of ten evaluated DNS-dependent terms across nested evaluation, not ten visible includes. Assess dependencies before adding another sender. Do not freeze a provider's current IPs into a static replacement without a supported maintenance plan. If corporate mail uses Microsoft 365, preserve that separate configuration; the Microsoft 365 authentication guide is not a substitute for this application's authorization.

The provider locates its SPF indicator in email history, under Monitoramento de entregabilidade. Green means the platform recognized configuration; red requires checking publication and caches. Its guidance allows 24–48 hours or longer and recommends escalation if still unrecognized after 48 hours. Authoritative DNS and actual message results remain separate checks.

Step 2: obtain the tenant's DKIM packet

Follow the official Imobiliárias DKIM procedure:

1. Open Usuários > Histórico de e-mails enviados.
2. In the DKIM area, select Gerar chave.
3. Preserve the complete issued names, types and values for your approved domain.
4. Publish the records at their authoritative DNS owners.
5. Return and use Validar chave; check the resulting configuration status.

Important source discrepancy: The prose refers to four records and normally TXT. Its linked generation demonstration instead displays three CNAME entries, labelled Mail Server, DKIM 1 and DKIM 2. Do not invent a fourth record, convert CNAME to TXT, or borrow the demonstration's SendGrid targets. Use the exact current account-issued packet; if its count, types or purpose are unclear, obtain Superlógica confirmation before publishing. The demonstration also shows Configurei o DNS, an acknowledgment, not evidence that DNS changed automatically.

Private signing keys must remain with the signing service. Only public records belong in DNS. Record-generation controls may affect existing signing configuration: do not repeatedly regenerate keys to resolve a propagation delay or overwrite active selectors without a supported rotation plan.

Step 3: place each record in the correct DNS zone

A registrar and authoritative DNS host need not be the same company. Follow actual delegation, not the logo on a domain invoice. Illustrative mapping below uses placeholders, not issued Superlógica values:

Replace every example with the actual issued name. Check the final fully qualified owner because some DNS interfaces append the zone automatically. An @ host means the current zone's apex, not necessarily the organization's main domain. Keep existing NS delegations and shared dependencies intact.

For an issued CNAME, retain its entire target. Do not add competing TXT, A, AAAA, MX or another CNAME at that owner. A Mail Server label does not authorize replacing your inbound MX. Verify the record's envelope/routing purpose with the provider rather than inferring it from the label.

CNAME authentication aliases must not be HTTP-proxied. Where literal CNAME answers are required, turn off an applicable per-record flatten control when available and ensure zone-wide, apex or same-zone behavior does not conceal the issued alias. Use only supported settings for the affected record. If mandatory flattening cannot preserve the required response, stop and coordinate a supported configuration; do not disable a shared global feature blindly.

For an issued TXT entry, keep the complete public tagged value. Do not paste a private key, screenshot value, ellipsis or shortened key. Check every record, including any non-DKIM entry in the packet. Additional A/MX, forwarding or delegation instructions require comparison with the approved routing plan before acceptance. Do not change MX, nameservers, DNSSEC, credentials or recipients just to make a tutorial example fit.

Step 4: separate DNS, platform validation and delivered proof

Query each owner at its authoritative server and an independent resolver. Confirm exact types and values, single-policy SPF, and required literal aliases. A short blank answer is not proof of absence: examine DNS status and errors. Allow applicable TTL caches to expire rather than repeatedly editing correct records.

Run the documented validation only after publication. A positive platform result establishes its configuration check, not every application's actual signing behavior or alignment. If it still cannot find records, compare the account packet with DNS before regenerating anything. Provide support only necessary public record details and redacted diagnostics, never credentials or message bodies containing personal data.

Next send an approved, non-sensitive test through the actual intended production workflow to a controlled valid recipient. Do not trigger financial, tenancy or customer notifications merely to manufacture a test. Arrange a safe representative message with the application owner.

Obtain Authentication-Results generated inside the actual receiving service's known processing boundary, using its documented treatment of externally supplied result headers. Header position or a familiar authserv-id string alone is not a trust guarantee. Ignore attacker-supplied results.

Record the intended visible From, SMTP MAIL FROM, DKIM d= and s=, and trusted results. Accept the new branded DKIM route only when the intended provider signature passes, its signing domain aligns with the unchanged approved From under effective adkim, and trusted receiver results show dmarc=pass. A DMARC pass through SPF alone does not demonstrate working DKIM; a rewritten provider From does not establish your brand's authentication.

Under current DMARC rules, relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. Evaluate SPF with effective aspf separately. A child envelope domain does not promise strict SPF alignment. Repeat checks for materially different workflows; successful authentication does not guarantee inbox placement.

Troubleshooting without weakening protection

Fix SPF faults even if aligned DKIM currently produces DMARC pass. Keep configuration evidence separate from message evidence. If a change must be reversed, restore only the erroneous approved portion while preserving subsequent legitimate changes and keys needed by queued messages.

Keep DMARC policy and reporting intentional

This guide checks compatibility with existing DMARC; it does not prescribe creating a new policy. Preserve direct and applicable inherited policies and authorized report recipients. If no applicable policy exists, establish a separate approved monitoring/enforcement plan rather than copying a permissive child-domain exception.

For aggregate reporting, compare the destination's Organizational Domain with the policy domain's Organizational Domain. If different, the report-generating receiver must check DNS authorization; destinations within the same Organizational Domain are excepted. RFC 9990 section 4 defines this distinction. Authorization in DNS does not replace the owner's permission to share report data.