adRom SPF, DKIM and DMARC setup, step by step

In the adRom Marketing Portal (AMP), open Unternehmens-Profil → Meine Domains, add your sending domain, then select Authentifizieren to obtain its DNS records. Publish the approved records at your authoritative DNS provider and run Authentifizieren again. The domain’s completed authentication status is the platform check; a newly delivered campaign message is still needed to prove DKIM signing and alignment.

This guide covers AMP’s native campaign sending-domain workflow. It does not configure a separate SMTP application, migrate a business mailbox or assume that every other adRom service uses the same records. Optional tracking and image/CDN domains are separate from the basic sending identity.

Copy records from your own AMP account. The public documentation contains a sample selector, a shortened DKIM key and example DNS values. They explain the record structure, not a reusable account configuration. The authoritative starting point is adRom’s Meine Domains guide.

Before you change anything

Confirm the intended visible From address, approved sending domain, AMP account and DNS administrator. A dedicated sending subdomain can help separate services, but choosing one and assigning its mail routes is an owner-approved design decision, not a mandatory name from a tutorial.

You also need:

• An authorized role that can manage Unternehmens-Profil, not just create campaigns.
• Control of the domain’s authoritative DNS zone, including any separately delegated child or _domainkey zone.
• A saved inventory of existing SPF, DKIM, DMARC, MX and relevant tracking records.
• Agreement about any proposed inbound-mail or bounce route and the people allowed to receive reports or replies.
• Controlled test recipients and a receiving system whose authentication results can be interpreted reliably.

The roles guide says the default Admin role can access all settings. Default Staff cannot view or change the company profile; custom roles can have different permissions. Do not broaden somebody’s account access merely to complete this checklist. Ask an appropriately authorized administrator to perform the change instead.

The public procedure does not establish a universal plan or regional entitlement. If your account lacks these controls, confirm the applicable product and permissions with adRom rather than substituting another vendor’s procedure.

1. Add the domain and open its authentication records

The current official instructions use German interface labels:

1. Open the name menu at the upper left and go to Unternehmens-Profil.
2. Select Meine Domains.
3. Click Eine Domain hinzufügen und verifizieren.
4. Enter the exact approved domain and click Fortfahren.
5. On that domain’s card, click Authentifizieren. The right-hand panel shows the required DNS records.

Adding a domain is not the same as completing branded authentication. The official screenshots distinguish Verifiziert, meaning the domain can be used for campaigns, from Authentifiziert, the separate authentication state. A card can show the first as complete while the second remains incomplete. Do not treat the first checkmark as proof of a working branded DKIM signature.

Capture the full account-issued record names, types and values. If a value is clipped in the interface, use the complete copyable value or obtain it from adRom. Do not transcribe only the visible start of a key.

2. Understand the records without copying the sample

The official page illustrates these functions:

The public example DKIM key is abbreviated and must not be deployed. Do not copy the example’s DMARC reporting recipient or enforcement policy. A public screenshot is not permission to send reports to an outside organization.

The sample MX line also does not justify replacing a working business mailbox route. If your account packet requires MX but omits a necessary detail such as priority or the relationship to existing mail, obtain that detail from adRom before making the change. Do not silently skip a required record and call the domain authenticated.

SPF: handle the redirect deliberately

For recognition only, adRom’s public example is:

v=spf1 redirect=spf.emailsocket.com

This is not a universal instruction to replace your current SPF. Confirm the policy in your own authentication panel and the domain where it belongs.

SPF evaluates the actual SMTP envelope sender, normally reported as smtp.mailfrom, not automatically the address in the visible From header. Do not add authorization at the root merely because the campaign’s From address uses a child domain, or vice versa.

At any evaluated owner, keep one TXT policy beginning v=spf1. Preserve all legitimate sending services. If an existing policy and the new packet conflict, have the mail/DNS administrator and adRom agree the combined policy or an isolated sending-domain design.

In particular:

• Do not publish two SPF policies at the same owner.
• Do not append this redirect to a policy containing all; all causes the redirect modifier to be ignored.
• Do not append ~all or -all to a redirect-only policy simply because another guide uses it.
• Do not mechanically convert the redirect to an include. They have different evaluation behavior.
• Preserve approved qualifiers on existing mechanisms. A qualifier’s result is not a guarantee of delivery or rejection.
• Check the limit of 10 evaluated DNS-dependent terms, including nested evaluation. It is not simply a limit of ten visible includes.

See RFC 7208 for the evaluation rules. The account packet identifies the requested service authorization; it does not automatically resolve a shared-domain conflict.

DKIM: publish the public key, not a sample or private key

Retain the entire issued TXT value, including its tags and complete p= data. The private signing key is not a DNS record and should not be included in a public file or ordinary support message.

A DNS editor may represent a long TXT value as multiple quoted character strings inside one record. Those strings must concatenate to the issued value. Do not create separate competing TXT records for fragments of the same key or add whitespace within the key material. Follow the DNS host’s documented editor format and verify the resulting answer. The key-record rules are described in RFC 6376.

Keep existing selectors used by other mail services. If the issued owner is occupied by another key or CNAME, ask for a supported resolution rather than overwriting it.

3. Map the full names into the authoritative zone

Work where the nameservers actually serve the domain. Editing an inactive registrar zone does not publish the records, regardless of how long you wait.

Use the account’s full owner names as the source of truth. The examples below are only a naming map. SELECTOR is a placeholder for the issued selector, not an instruction to use that literal text or the documentation’s sample smtp.

If the editor expects a fully qualified name, use that convention instead. Confirm the published result to catch an accidentally doubled suffix.

Do not remove existing NS delegations to make the parent zone accept a record. The owner may belong in a delegated _domainkey or child zone. Coordinate with that zone’s administrator and preserve other services’ dependencies.

Review MX and other routing consequences separately

Compare every requested MX target with the approved inbound/bounce-handling design. A domain used for existing staff mail is not interchangeable with a dedicated campaign subdomain. Do not replace its MX, create an unapproved forwarding destination or change parent nameservers merely to satisfy a screenshot.

If the packet’s required records conflict with current operations, stop before publishing and resolve the domain choice or supported configuration with adRom. This is safer than weakening authentication, skipping records or breaking incoming mail.

4. Recheck the records in AMP

After publication, open Meine Domains and select Authentifizieren for the intended domain again. adRom checks the DNS entries. Its procedure says incorrect or not-yet-ready entries are marked red; when the required entries are correct and replicated, the domain displays its green completed authentication indication.

The provider says replication can take up to 48 hours. That is documented propagation guidance, not a promise that every setup will activate within a fixed service-level window. An incorrect owner, missing delegation or truncated key will not repair itself by waiting.

Check the authoritative answers as well as a separate public resolver. These read-only examples use placeholders:

dig @AUTHORITATIVE_NAMESERVER TXT SPF_OWNER_FQDN
dig @AUTHORITATIVE_NAMESERVER TXT DKIM_OWNER_FQDN
dig @AUTHORITATIVE_NAMESERVER MX APPROVED_MAIL_OWNER_FQDN
dig @PUBLIC_RESOLVER TXT DKIM_OWNER_FQDN

Compare answers with the entire issued packet, including the exact public key. Querying the approved MX owner is inspection, not permission to change it.

A green AMP authentication state is the service’s configuration checkpoint. The documented workflow does not establish an additional hidden Enable DKIM switch, so do not invent one. Continue with a controlled native campaign message before approving production use.

Optional tracking and CDN domains

Under Erweiterte Optionen, adRom allows separate tracking and CDN domains. Tracking links redirect through its infrastructure; the CDN name serves uploaded images. These are not the DKIM signing identity or an automatic reason to change mail authentication records.

The guide illustrates t and i subdomains and CNAME targets. Choose only approved names and copy the actual account-issued targets. Do not overwrite an existing website or other service at those names. If you do not need custom tracking or image domains, leave that separate project alone.

If you do configure them, retain a single CNAME with no conflicting TXT, A, AAAA, MX or second CNAME at the same owner. Use the service’s required DNS-only configuration rather than assuming an HTTP proxy is compatible. Where validation requires the literal CNAME answer, turn a relevant per-record Flatten control off when available and ensure applicable whole-zone settings do not suppress the alias. Coordinate shared changes instead of globally disabling behavior without review.

Cloudflare has mandatory apex and same-zone-target behavior as well as per-record and zone-wide controls. If the required answer cannot be preserved, stop and agree a supported configuration with adRom and the DNS administrator. Do not remove delegations or invent a setting. See Cloudflare’s actual flattening instructions and proxy-status documentation.

adRom’s page describes generating SSL for those additional domains within an hour. Treat this as its documented process, not a measured guarantee for your account. Check the actual custom-domain and SSL state. An SSL-generated label is not evidence that campaign mail has a passing aligned DKIM signature.

5. Test the actual campaign sender

Use a controlled AMP campaign, not a message sent from your mailbox’s webmail or an unrelated SMTP service.

The official first-campaign procedure identifies Kampagnen → Kampagne Erstellen, then the normal Kampagne option. For authentication testing, restrict the selected groups/segments to authorized test recipients only. Do not select a customer audience or an A/B test that could send a winning variant to additional recipients.

The final campaign step contains the subject, sender name, sender email, reply address, scheduling and test controls. Use the approved From address on the authenticated domain and a working, approved reply destination. Review the final recipient list and schedule, and leave automatic resending to non-openers off for the test. Check the actual campaign settings rather than assuming a template’s previous sender is correct. Select Sende Kampagne only after the controlled recipients, content and start time have been approved; an immediate start is not a harmless preview.

The template preview guidance also offers Vorschau and Test Versenden, with a prefilled recipient address and the ability to add others. Review every destination before an authorized test. Previewing appearance or merge tags is not itself a message-authentication check. If preview mail does not use the intended campaign identity/route, use an approved tiny native campaign to controlled recipients for final acceptance.

The separate Spam Test feature can send campaign content to provider test facilities. Do not use it as an unapproved data-sharing shortcut. adRom itself warns its result may not fully match actual sending. A favorable spam-test score cannot replace raw message authentication evidence.

What a successful check must show

Keep DNS, the AMP state and receiver results separate. For the intended native route, require:

1. Public records matching the approved account packet at the correct owners.
2. The intended domain’s completed Authentifiziert state, not only Verifiziert.
3. A newly delivered message retaining the approved visible From address.
4. The intended adRom DKIM signature passing, with its actual d= signing domain aligned to that From domain and its s= selector matching the intended configuration.
5. The trusted receiver reporting dmarc=pass for that unchanged From domain.
6. An understood SPF result for the actual smtp.mailfrom, plus working approved reply handling.

Trust only results produced within the receiving service’s known processing boundary, with its documented removal or treatment of externally supplied Authentication-Results. A matching authserv-id or a header near the top is not enough. Ask the receiving administrator to identify its own evaluation if needed; ignore attacker-inserted results. See RFC 8601 section 7.1.

A DMARC pass supplied solely by aligned SPF does not prove this DKIM setup works. Likewise, a valid signature for an unrelated vendor domain is not branded DKIM success. EmailAuth’s raw versus aligned DKIM explanation helps interpret those mixed results.

Under relaxed alignment, the authenticated and visible domains can share the relevant Organizational Domain. Strict alignment requires an exact domain match. A child envelope domain can satisfy relaxed SPF alignment without satisfying strict SPF alignment. The public AMP procedure does not establish a universal Return-Path or guarantee strict alignment; inspect the actual message and applicable policy. See RFC 9989.

DMARC: do not deploy the sample policy blindly

The adRom example includes p=reject and a reporting address. Neither is a default instruction for your domain. Preserve any existing direct or applicable inherited DMARC policy, its approved destinations and its enforcement. Do not weaken it to p=none, duplicate it or silently redirect its reports.

Only where no direct or applicable inherited policy exists, the owner approves and a monitoring plan is ready, a first monitoring TXT value can be:

v=DMARC1; p=none

This value alone does not request aggregate reports. Add a real authorized rua destination only after agreeing who receives that information and who reviews it.

When a report destination is in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check its DNS authorization. A destination within that same Organizational Domain is excepted; differing hostnames alone do not decide this. This protocol authorization is separate from the owner’s privacy and data-sharing approval. See RFC 9990 section 4.

Do not tighten enforcement based on one successful campaign. Check other legitimate senders and accumulated report evidence before approving a policy change.

Troubleshooting the AMP workflow

Rollback, rotation and removal

Before publication, retain the original record values and the issued packet. If the route fails acceptance, pause affected campaigns and coordinate correction with adRom and the DNS owner. Restore only changes attributable to this setup after reviewing shared dependencies; do not delete the whole SPF policy or another sender’s key.

The public domain article shows removal controls but does not document a safe key-rotation sequence. Do not delete and recreate a production domain to force a new key. Agree the signing transition, queued-mail implications and old-key retention with adRom first.

Tracking and CDN names may remain embedded in already delivered messages. Do not remove them just because future sending has stopped. Establish what still depends on them before retiring records.

After a domain, signer, DNS provider or campaign sender change, repeat the affected DNS, AMP and real-message checks. Preserve the result with the account, domain, selector, sending route and check time so a later problem can be compared accurately.

Sources and review date

Primary sources: Meine Domains, Rollen / Rechte, first campaign, template preview and Spam Test. The served pages do not expose a reliable article publication/update date in the inspected bodies. Image upload paths and the site copyright year are not substituted for those dates. This is documentary guidance, not a test of a customer’s account, DNS or delivered mail.