mailflatrate SPF, DKIM and DMARC setup, step by step

To authenticate native Mailflatrate campaigns, add your domain under Domains → Sending domains, save it, publish the SPF and DKIM TXT details issued for that domain, and return to Verify DNS records. Then check a newly delivered campaign for the intended aligned DKIM signature and DMARC pass. Do not copy the public tutorial’s example SPF policy or DKIM key. Mailflatrate setup instructions.

This is a documentary setup guide, not a test of your account, DNS or delivered mail. Authentication does not guarantee inbox placement.

Before you start

This guide covers Mailflatrate’s native campaign sending-domain workflow. It does not configure an unrelated SMTP server, a WordPress integration, employee mailboxes or every service sharing Mailflatrate’s infrastructure. You need access to sending-domain settings and permission to edit the domain’s authoritative DNS. The reviewed public instructions do not establish a particular paid plan, region or named administrator role for this feature; if the controls are missing, confirm your account’s eligibility rather than assuming an upgrade is required.

Identify the campaign’s intended visible From address and the domain you control. Keep a copy of existing SPF, DKIM, DMARC, MX and NS records, including TTLs and any delegated child zones. Identify other legitimate senders before changing SPF. If the same domain also sends staff mail through Microsoft 365, keep that authorization separate from Mailflatrate’s campaign setup; see EmailAuth’s Microsoft 365 authentication guide.

A registrar is not necessarily your DNS host. Make the change at the authoritative service, not merely wherever the domain was purchased. There is no need to move inbound mail, change nameservers or disable DNSSEC to add these authentication records.

Generate the correct Mailflatrate records

1. Sign in to your existing Mailflatrate account and open Domains → Sending domains.
2. Choose Create new domain and enter the domain, not a complete email address.
3. Save the domain. Retrieve its generated SPF and DKIM details, including every owner, record type and complete value.
4. Record which campaign identity will use this domain. The public setup page does not document an exact From-editor menu, so do not assume that adding a domain changes every existing campaign’s From address.

The English application guide uses the labels above. The German FAQ describes Mein Konto → Domains → Neu anlegen, followed by saving and DNS verification. These are documented interface variants, not two different authentication systems. Official setup guide, Mailflatrate FAQ.

The documented route uses TXT for both SPF and DKIM. Its illustration shows a mailer._domainkey selector owner, but that is not permission to reuse the screenshot key or assume that every future account uses the same selector. The current account-issued owner and full value are the inputs to your change.

Configure SPF without damaging existing senders

SPF authorizes the IP connecting to the receiver for the actual SMTP MAIL FROM identity, or HELO in applicable cases. That identity is not automatically the visible From address. Mailflatrate’s public pages do not establish a universal Return-Path domain or guarantee strict SPF alignment, so adding a TXT policy at your visible From domain alone does not prove the production message will use it. SPF specification.

Inspect the exact owner for which Mailflatrate supplied its policy:

• If no SPF policy exists there, assess the issued authorizations against your approved sending inventory before publishing one TXT policy.
• If a policy already exists, reconcile the required Mailflatrate authorizations into that single policy. Preserve other legitimate senders and the intended qualifiers. Do not publish a second v=spf1 record or paste two full policies together.
• If the existing policy uses redirect=, review its semantics before adding all: an all mechanism causes redirect to be ignored. This is not a harmless append operation.
• Check the SPF limit of ten evaluated DNS-dependent terms, including nested mechanisms and modifiers. It is not simply a limit of ten include entries. An excessive evaluation can produce permerror.

The old tutorial screenshot is not a deployable SPF recipe. It contains broad a/mx authorizations, ptr and a private-address example. The SPF standard says not to use ptr. Do not copy that example, turn a private address into a public authorization, or invent a generic Mailflatrate include. If your current account still generates questionable mechanisms or unexplained IP addresses, stop and obtain a corrected, justified packet from Mailflatrate before publication. First-party illustration, RFC 7208 section 5.5.

The provider’s verifier might compare an expected policy string rather than recognize a carefully merged policy. If existing senders and the issued packet cannot be reconciled safely, resolve that discrepancy with the provider. Do not break working staff mail merely to satisfy a badge.

Publish the complete DKIM TXT record

Create the exact TXT record supplied for your domain. Preserve the complete tag/value sequence, including the whole p= public key. Never upload a private key or create an unrelated key pair in a generic generator: Mailflatrate must sign with the corresponding private key.

For illustration only, if the issued full owner were mailer._domainkey.example.com, a DNS editor for the example.com zone would commonly use mailer._domainkey in its relative Name field. If the signing domain were news.example.com, the owner might instead be SELECTOR._domainkey.news.example.com; in the parent zone its relative name is SELECTOR._domainkey.news, while inside a separately delegated news.example.com zone it is SELECTOR._domainkey. Substitute the actual selector, not the word SELECTOR.

A separately delegated _domainkey namespace must be edited at its own authoritative service. Do not delete NS delegations to force a TXT record into the parent zone. Check how your DNS editor handles fully qualified names so it does not create example.com.example.com. At an owner already occupied by a CNAME, do not add a conflicting TXT record; establish which sender owns it before changing anything.

For the full issued owner SELECTOR._domainkey.news.example.com at an existing separately delegated _domainkey.news.example.com authority, enter relative owner SELECTOR. Substitute the actual issued selector, preserve that namespace’s NS delegation and other selectors, and publish the issued TXT value at that authority. DNS relative names.

Mailflatrate’s FAQ discusses 2048-bit keys and DNS editors with apparent 255-character limits. That limit applies to an individual TXT character-string, not necessarily the complete logical record. Use the DNS host’s supported way to store multiple adjacent strings in one TXT record, preserving the complete logical value and inserting no extra spaces into the key. Do not split it into unrelated TXT records, truncate it, downgrade the key or migrate your domain as a first response. Mailflatrate FAQ, DKIM key-record specification.

Verify DNS in Mailflatrate

Query the authoritative DNS service and a recursive resolver, then compare the complete answers with the approved packet. These commands are templates, not results from a customer domain. Replace the uppercase placeholders and the example domain before use:

dig @AUTHORITATIVE_NAMESERVER TXT example.com
dig TXT example.com
dig @AUTHORITATIVE_NAMESERVER TXT SELECTOR._domainkey.example.com
dig TXT SELECTOR._domainkey.example.com

The SPF owner in these commands must be changed if the packet uses a child domain. Expect one SPF policy at that owner and the full issued DKIM TXT at its exact selector owner. Multiple unrelated TXT records at the SPF owner are not themselves an error; multiple SPF policies are.

Return to the domain in Mailflatrate and select Verify DNS records. The first-party screenshot and FAQ allow up to 48 hours for DNS changes to become visible. Check authoritative correctness first rather than waiting two days for a misspelled owner to fix itself. Resolver caching, including negative caching, can delay visibility after a correction. Verification illustration, FAQ.

The reviewed instructions do not establish an additional DKIM signing toggle. Do not invent one. Successful DNS verification completes the documented account verification step, not the delivered-message acceptance test.

Preserve DMARC and verify reporting authority

Keep any existing direct or applicable inherited DMARC policy, alignment settings and authorized reporting destinations. Do not downgrade enforcement to p=none, add a duplicate policy or use obsolete percentage-based rollout advice just to onboard Mailflatrate. Policy discovery and organizational-domain relationships matter when the visible From uses a subdomain. Current DMARC specification.

Only if no direct or applicable inherited policy exists, and the domain owner approves a monitored first-policy rollout, a minimal starting example is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;

This is an example for the chosen policy domain, not an instruction to replace an existing policy. In the example.com zone the relative owner is _dmarc. For a deliberately chosen child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in the delegated child zone. Monitoring needs an approved report destination or another defined monitoring arrangement; the example intentionally does not invent a recipient.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If these Organizational Domains 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 owner’s approval to share report data with that recipient. RFC 9990 section 4.

Prove that the actual campaign is authenticated

Use a controlled, valid recipient you are authorized to test, through the actual Mailflatrate campaign path and intended From identity. A message from your normal mailbox is not a substitute. No test messages were sent in preparing this guide.

Open the received message’s original source using the receiving service’s documented tools. Establish which Authentication-Results fields were produced inside that service’s known processing boundary and how it removes or treats externally supplied result fields. If you cannot establish that boundary, ask the receiving administrator before relying on the fields. Familiar authserv-id text or a header’s position alone is not proof; ignore attacker-supplied or otherwise untrusted results. Authentication-Results security requirements.

Record the visible From, actual envelope identity reported by the receiver, DKIM d= signing domain, s= selector, and individual authentication results. Acceptance requires:

• The visible From remains the intended branded identity, not a rewritten provider address.
• The intended Mailflatrate signature passes DKIM and its d= aligns with that From domain under the effective DMARC policy.
• The trusted receiving system reports dmarc=pass for the intended From domain. A pass achieved only through SPF does not prove this DKIM deployment works.
• SPF is assessed independently. Investigate fail and softfail, temporary DNS temperror and permanent evaluation permerror even if aligned DKIM already gives a DMARC pass.

Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. A child envelope domain may satisfy relaxed SPF alignment but fail strict alignment with a parent From. Do not guess Mailflatrate’s envelope behavior from the DNS screen. DMARC identifier alignment.

Troubleshooting and safe rollback

DNS verification fails: compare the full owners, record types and values with the current account packet. Check authoritative delegation, auto-appended suffixes, duplicate SPF policies and key truncation. If DNS is correct but the account rejects a merged SPF policy, resolve the verifier’s expectation with Mailflatrate without deleting legitimate senders.

DNS verifies but DKIM is missing or fails: confirm the campaign used the verified domain. Inspect its actual selector and signing domain, not just the one you expected. Re-query that owner and check for a stale or replaced key. If the intended signature is absent, escalate with the domain, verification state, timestamp and appropriately redacted headers; do not regenerate keys indiscriminately.

DKIM passes but DMARC fails: compare d= against the visible From and the policy’s alignment mode. A valid provider-domain signature can be unaligned. Do not relax a working DMARC policy to disguise the mismatch.

Everything authenticates but delivery is poor: investigate recipient consent, bounce responses, complaint rates, content and sender reputation separately. Authentication is not an inbox guarantee.

Before rollback, pause affected campaigns through your normal authorized process. Restore only the records changed in this deployment from the saved baseline, preserving changes made by other administrators. Keep an old DKIM selector available while legitimate queued or recently sent mail may still need it, and coordinate retirement with Mailflatrate. Do not remove a shared selector, delegation, staff-mail authorization or DMARC policy as a blanket reset. Retest the restored sending route before resuming.

Sources and maintenance

The primary setup guide and FAQ did not expose a reliable publication/update date in the reviewed material. Their documentary check date is not a vendor release date. This guide uses the full official sending-domain instructions, their verification screenshot, and the FAQ, with protocol safeguards linked at the relevant steps. Recheck the account packet when changing domains, selectors or sending routes, and repeat message acceptance after material changes.