rapidmail SPF, DKIM and DMARC setup, step by step

To authenticate rapidmail, use the DNS records shown for your sending domain, complete the applicable DKIM activation, and check a newly delivered message. Newsletter authentication, signup-form messages and transactional SMTP are distinct paths. A green newsletter status does not establish that your shop’s transactional mail is authenticated.

Native publisher dates are separate: Entri 11 November, manual SPF 10 November, manual DKIM and transactional project setup 12 November, DMARC 30 October, and transactional DKIM 18 September 2026. This is a documentary guide, not an account walkthrough or a completed DNS or delivery test. German source material has been synthesized in English. Account values and received-message results remain essential.

Choose the route before changing DNS

Start with a list of the messages you actually send: newsletter campaigns, signup or double-opt-in messages, and application-generated transactional messages. Record the visible From domain and the person responsible for each application. Include any separate domain or subdomain, not just your main website domain.

rapidmail documents both newsletter sending and transactional SMTP. Its current transactional setup guide creates projects under Transaktionsmails > Projekte verwalten > Neues Projekt anlegen. Editing the project exposes SMTP connection details for your shop, CRM or CMS. This is rapidmail delivery from an external application, not permission to assume that mail sent through another SMTP service uses rapidmail authentication.

Project settings offer preserve, override and relay Return-Path handling. Preserve retains the incoming Return-Path; override uses rapidmail’s Return-Path and bounce handling; relay also forwards bounce information to the original address. Inspect the actual delivered envelope identity for your chosen mode. A bounce destination and an SPF-aligned identity are related but not interchangeable evidence. Changing the mode affects bounce processing or forwarding: obtain the route owner’s approval for the destination and handling, rather than switching modes solely to imitate an example. Keep SMTP credentials out of DNS, screenshots and shared worksheets.

This guide applies where those controls are available in your account. The retrieved pricing page did not expose a usable plan-by-plan authentication matrix. Confirm transactional entitlement and your account permissions before planning that route; no particular paid tier or region is assumed here.

Prepare the domain and protect existing mail

You need rapidmail access for the intended domain, permission to change its authoritative DNS, and a controlled recipient mailbox for later testing. Use a domain your organization controls. A Gmail or Yahoo mailbox does not give you authority over that provider’s domain. An address-verification email is not a substitute for domain authentication.

Before editing, save the current DNS records and inventory other legitimate senders: staff mail, billing, support, website forms and other marketing tools. Establish which zone hosts each exact owner name. Your registrar and your authoritative DNS provider may be different companies.

Keep three identities separate:

• Visible From: the domain your reader sees, which DMARC protects.
• SMTP MAIL FROM: the envelope domain evaluated by SPF, commonly visible through the delivered Return-Path and the receiver’s smtp.mailfrom result. SPF uses HELO in applicable cases such as a null reverse path. SPF identities
• DKIM signing domain: the d= domain in a signature; s= identifies its selector.

Under RFC 9989, DMARC needs at least one authenticated, aligned path: SPF or DKIM. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. For example, visible From newsletter@example.com and a passing d=news.example.com DKIM signature align in relaxed mode, assuming the same Organizational Domain, but not strict mode; a passing intended d=example.com aligns in both. These are hypothetical identities, not observed account results. A provider-owned bounce domain can pass SPF without aligning with your From domain.

Start guided or manual authentication

The Entri workflow starts from the dashboard’s sender-domain task or Absender-Einstellungen > Absender-Authentifizierung in account settings. Select the intended domain and begin authentication. Entri detects supported DNS hosts and asks you to sign in so it can publish the proposed records. If the host is unsupported, use the manual setup link at the bottom of the provider list. The workflow also offers a link you can pass to your DNS administrator.

Only the authorized DNS owner should sign in or approve delegated access. Review the requested permissions and exact proposed records before granting access or applying changes; do not share host credentials with a tutorial or reviewer. Do not let an onboarding flow replace an established DMARC policy, erase another sender’s SPF authorization or reuse an occupied DNS owner. If the proposal is inconsistent with your existing configuration, stop and have the domain administrator reconcile it. Automatic publication does not remove the need for DNS and message verification.

Publish newsletter SPF and DKIM correctly

The manual SPF guide now uses an account-supplied CNAME, not a universal SPF TXT record to paste at your root domain. Copy the displayed owner and target exactly. Do not turn this into an apex CNAME or invent an include from an old guide. rapidmail explicitly cautions that its SPF status can detect an entry’s presence without proving its correctness.

The manual DKIM guide presents separate mailing and form-related DKIM rows. Publish the requested TXT record with the generated public value. Complete each applicable row rather than copying a sample key. Preserve the complete account-issued tagged TXT value, not only its p= data. The explanatory native text abbreviates the version tag; do not hand-build a key from that illustration. The guide distinguishes the mailing key from the form-related key and notes that a remaining form-record warning need not mean newsletter signing is incomplete. It also uses “transactional” for the second row; that wording does not replace the separate SMTP transactional-domain generation and activation instructions below. Verify the intended form and SMTP paths independently.

DNS entry rules apply to all of these records:

• If your DNS editor appends the zone name, enter only the relative owner portion. Check the resulting fully qualified name for a duplicated suffix.
• A CNAME owner must not also contain unrelated TXT, MX or address records. Choose a supported unused owner or ask rapidmail to resolve the collision. Do not delete existing service records blindly.
• Publish only public DKIM material. Do not put a private key or SMTP password in DNS.
• If TXT data is split into quoted strings, preserve character order and the complete value as one logical TXT record, not competing keys. The strings concatenate without inserted spaces. DKIM TXT representation

Map each actual owner to its authoritative zone. ISSUED_SELECTOR below is a placeholder, not a universal rapidmail selector:

Repeat for every mailing, form and transactional selector. A hypothetical SPF alias ISSUED_LABEL.news.example.com uses ISSUED_LABEL.news in the parent zone or ISSUED_LABEL in the delegated child, not in _domainkey. Preserve existing NS delegations and coordinate with their administrators. Do not change parent nameservers, MX, DNSSEC or website records merely to authenticate mail.

Keep authentication and bounce CNAMEs DNS-only and unflattened, returning the issued literal target. In Cloudflare, turn the affected record’s Flatten control off where available, and ensure applicable zone-wide settings do not suppress that alias. Flatten-all overrides the record-level choice; coordinate a supported setting with the DNS owner and assess shared dependencies before any change. Mandatory apex or same-zone flattening may have no off switch. If it prevents the required CNAME answer, stop and arrange a supported configuration rather than inventing a control or deleting a delegation. Cloudflare flattening controls and domain verification

Return to sender settings after DNS publication. The documented status refresh can take up to 48 hours. Check authoritative answers first rather than repeatedly replacing valid records while caches expire.

Configure transactional SMTP separately

The transactional DKIM instructions explicitly say newsletter DKIM does not automatically cover transactional mail. Go to Transaktionsmails > Absenderdomains verwalten, edit the relevant domain, generate a new DKIM key, and publish the generated TXT owner and public value. Then use Benutzerdefinierte DKIM Authentifizierung prüfen & aktivieren to verify and activate it. Before generating a replacement, establish whether the route already has an active key and agree a supported replacement plan with its owner. Repeated generation can change the expected DNS value during troubleshooting. Test through the actual application and project, not only a newsletter preview.

For transactional SPF, rapidmail’s manual SPF page documents include:spf.smtp.net. Merge that authorization into the existing SPF policy at the domain that your transactional envelope actually uses, when applicable. Preserve other legitimate senders and the established ending policy. Do not automatically change -all to ~all when a message fails; first identify the evaluated domain, authorization failure, lookup error or alignment mismatch.

SPF’s standard permits one v=spf1 record per owner name. Its limit is ten evaluated DNS-querying terms, including nested evaluation, not simply ten written includes. Multiple quoted strings within one TXT record are not multiple SPF policies. Do not add a second SPF record or manually freeze provider IP addresses as a quick repair. Any all mechanism makes redirect ignored, irrespective of qualifier. Preserve redirect-only control flow rather than appending all; merge only the approved mechanisms into one coherent policy. SPF precedence Qualifiers do not guarantee final receiver disposition.

Preserve DMARC or create a first policy deliberately

rapidmail’s manual DMARC procedure requires completed DKIM before its DMARC setup. Keep any applicable established DMARC policy, including policy inherited by a subdomain. Onboarding is not a reason to replace quarantine or reject with none.

Only when no direct or applicable inherited policy exists at all, including p=none, the domain owner may approve a monitoring plan after legitimate sending routes are inventoried and authentication is working. Publish the first policy only after that approval. For a fictional From domain example.com, create one TXT record at _dmarc.example.com with v=DMARC1; p=none. In a DNS editor for example.com that appends the suffix, the owner is _dmarc. For From news.example.com, the full local policy owner is _dmarc.news.example.com: use _dmarc.news in the parent example.com zone or _dmarc in the delegated news.example.com zone. It does not belong in a delegated _domainkey zone. These are example-domain mechanics, not records for your account.

That minimal policy requests no aggregate reports. To monitor reports, add a rua=mailto: URI supplied by an approved reporting mailbox or service, using its exact approved destination. When its Organizational Domain differs from the policy domain’s Organizational Domain, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; a different hostname alone does not make this necessary. Obtain the service’s issued authorization rather than guessing a record. RFC 9990 section 4 Protocol authorization is separate from the domain owner’s data-sharing decision; review the recipient, privacy, access and retention before sending aggregate reports. Do not copy someone else’s reporting address. RFC 9989 section 7.4 requires valid DKIM signatures for domains publishing p=reject and cautions about indirect-mail interoperability. One aligned SPF pass alone does not establish domain-wide readiness for reject. Enforcement interoperability Review legitimate sources and subdomains before moving to enforcement; p=none does not guarantee acceptance or inbox delivery. The current standard removes pct, so do not plan a percentage rollout with it. RFC 9990 covers aggregate reporting; RFC 9991 covers failure reports, whose potentially sensitive content needs separate privacy review.

Verify DNS and then test real messages

The following are read-only examples. Replace the fictional names with your authoritative nameserver, account-provided owner, actual selector and actual envelope domain:

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

Expect the CNAME to match rapidmail’s target, the relevant TXT lookup to resolve the intended SPF policy, the DKIM answer to contain the generated public key, and DMARC to show your approved policy. Query each account-issued owner, including both relevant newsletter/form DKIM rows and the separate transactional selector. An empty answer is not sufficient diagnosis: inspect full dig output for NXDOMAIN, NODATA, timeout or SERVFAIL. Compare authoritative results with a recursive resolver after TTL and negative-cache expiry.

Send harmless content through every route in use to controlled valid recipients: a newsletter, an owned test signup flow, and an authorized safe transactional trigger. Do not enroll real subscribers or create real customer orders solely to obtain headers. Inspect the trusted receiving system’s Authentication-Results under the RFC 8601 trust boundary, not a sender-supplied imitation. Establish the actual receiving processing boundary through provider documentation or the receiving administrator, including how externally supplied results are removed or isolated from trusted fields, or obtain an authenticated receiver trace. A matching authserv-id or header position alone is insufficient. Leave acceptance pending when provenance is unknown. Record the receiver identity, From, Return-Path, smtp.mailfrom, DKIM d= and s=, SPF result, DKIM result and DMARC result. Test direct delivery first, then any forwarding path separately.

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 authentication of the intended brand. 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.

Troubleshooting by symptom

Newsletter passes; order receipt fails: confirm the receipt uses the intended SMTP project, its transactional DKIM is activated, and the application’s envelope matches the Return-Path mode. Reusing newsletter DNS is not sufficient.

Four green checks but DMARC fails: compare the actual message’s identities. A visible From subdomain may not exactly match under strict alignment. A status screen cannot prove the signing domain used on that message.

Persistent dashboard warning: identify the exact outstanding row. Do not rotate a working newsletter key to repair a missing form record.

CNAME is missing publicly: confirm the authoritative zone, owner suffix and record type. DNS proxying intended for web traffic must not obscure an authentication CNAME.

SPF permerror: inspect duplicate policies and evaluated lookup terms. Preserve working senders while preparing one corrected policy; do not discard authorizations to meet a numeric target.

Authenticated mail still goes to spam: investigate consent, complaints, volume, reputation and message content. Authentication is necessary evidence, not an inbox guarantee.