How to set up DMARC/DKIM/SPF for Flexmail
Published 27 Jun 2026
Updated 29 Oct 2026
13 min read
Summarize with
Updated on 29 Oct 2026: We updated Flexmail verification steps and clarified DMARC policy testing.
Flexmail authentication needs four pieces: a validated sender address, one SPF TXT record that includes Flexmail, one DKIM TXT record generated in Flexmail, and one DMARC policy that applies to the visible From domain. Start at p=none unless the domain already uses quarantine or reject, then verify with a live message before changing policy.
Flexmail starts in sender settings, where sender addresses are grouped by domain and the Set up authentication panel shows the DNS records. Its Flexmail authentication guide specifies relaxed SPF domain matching. Leave aspf unset, which defaults to relaxed matching, or use aspf=r.
Add and validate a sender
Flexmail does not start with a standalone domain wizard. Add and validate the sender address first, then Flexmail exposes the domain authentication panel for that sender's domain. Have access to your domain's DNS settings or an administrator who can publish the records.
Flexmail sender validation settings and domain authentication controls
- Open settings: Go to Settings, then Add or remove senders in your Flexmail account.
- Add sender: Click Add a new sender, enter a real inbox such as marketing@example.com, and click Request approval. For an existing unverified address, click Resend approval email.
- Verify inbox: Open the Flexmail approval email and click Verify my email address.
- Find domain: Return to sender settings; Flexmail groups validated senders by domain.
- Open auth: Click Set up authentication next to the domain you send from.
Use a real inbox
Flexmail sends approval to the actual sender inbox. A no-reply address with no mailbox blocks validation before SPF, DKIM, or DMARC can help.
Sender validation
- Scope: One sender email address at a time.
- Proof: The mailbox owner clicks a Flexmail approval link.
- Failure: Campaign sending can be blocked for that sender.
- Fix: Use a mailbox someone can open.
Domain authentication
- Scope: The domain shared by the sender addresses.
- Proof: DNS records prove Flexmail can send for the domain.
- Failure: Receivers can spam-folder or reject mail.
- Fix: Publish the generated SPF, DKIM, and DMARC records.
Once the authentication panel opens, generate the DKIM keys, then click Generate report to download the TXT file before editing DNS. The report contains your public DKIM key and the exact hostnames Flexmail expects; merge SPF and DMARC settings with existing records instead of overwriting them.
Set up SPF
Flexmail uses SPF to authorize its sending servers for the envelope sender. Add Flexmail to the existing SPF record for the domain shown in the authentication report, then verify that there is still only one SPF TXT record. The example below authorizes only Flexmail; preserve other approved senders and your existing final qualifier when merging records.
Flexmail-only SPF exampledns
v=spf1 include:spf.flexmail.eu -all
- Use one record: If the domain already has SPF, edit the existing TXT record instead of creating another one.
- Add Flexmail: Add the Flexmail include before the final all mechanism.
- Keep senders: Preserve any mailbox, CRM, support, or transactional senders already approved for the domain.
- Watch lookups: The SPF lookup limit is 10 evaluated DNS-lookup mechanisms and modifiers, including nested includes; exceeding it returns permerror.
- Check host: Publish at the domain in Flexmail's report. DNS panels often use @ for the zone apex, while a sending subdomain needs its own host value.
Broken SPF
Two TXT recordsdns
v=spf1 include:spf.flexmail.eu -all v=spf1 include:spf.mailhost.example -all
Merged SPF
One TXT recorddns
v=spf1 include:spf.flexmail.eu include:spf.mailhost.example -all
After DNS saves, check the public SPF result before sending a campaign. DNS caches can show an old value, so repeat the check after the record's TTL has expired. The merged example uses spf.mailhost.example as a placeholder for another sender; replace it with a real include or omit it.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If Flexmail's indicator stays red after the SPF check shows the Flexmail include, allow 24 to 48 hours for DNS propagation, then compare the authentication report with live DNS.
Set up DKIM
DKIM gives Flexmail a DMARC pass path that usually survives forwarding better than SPF. Generate a DKIM key in the Flexmail authentication popup and publish the TXT record exactly as shown.
Flexmail DKIM setup with the flexmail selector and generated TXT record
- Open panel: Go to Settings, Add or remove senders, then Set up authentication for the domain.
- Keep selector: Flexmail pre-fills flexmail; change it only if your DNS administrator requires a different selector.
- Generate key: Click Generate DKIM keys before copying the DNS value. Flexmail documents a 2048-bit RSA public key.
- Publish TXT: Add the TXT record at selector._domainkey.yourdomain.com using the host from Flexmail's report.
- Enter host once: If the DNS panel appends your domain automatically, enter only selector._domainkey to avoid duplicating the zone name.
- Keep value whole: Paste the full DKIM value. Long values can be split into quoted character strings within one TXT record; they are joined without added spaces. Do not create separate TXT records for key fragments.
- Check status: After DNS propagation, confirm Flexmail shows the DKIM record as active.
DKIM host pattern with a public-key placeholderdns
flexmail._domainkey.example.com. TXT v=DKIM1; k=rsa; p=PASTE_FLEXMAIL_PUBLIC_KEY
What to verify in a header
- DKIM result: The message header should show dkim=pass for the Flexmail-sent message.
- Signing domain: The d= domain must match the visible From domain exactly under strict matching, or share its organizational domain under relaxed matching.
- Selector: The s= value should match the Flexmail selector you published.
If DKIM fails while SPF passes, fix DKIM first. A Flexmail DKIM signature using your domain gives DMARC a more reliable pass path than SPF alone.
Set up DMARC
DMARC belongs at _dmarc.yourdomain.com, not inside Flexmail. For a domain with no DMARC record, start with p=none and a reporting address, then consider enforcement only after Flexmail and every other legitimate sender pass.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Record name: Publish one TXT record at _dmarc.example.com for mail sent from user@example.com. Edit an existing DMARC record instead of adding a second one.
- Policy start: Use p=none unless your domain already uses quarantine or reject; do not weaken an existing policy without reviewing its reports.
- Subdomain policy: For mail from newsletter.example.com, publish a record at _dmarc.newsletter.example.com or confirm that the organizational-domain policy and its sp setting provide the intended inherited policy.
- Report address: Replace dmarc@example.com with a mailbox or Suped reporting address that receives aggregate XML. An address outside your domain requires external report authorization; Suped handles that for its assigned addresses.
- Flexmail detail: Keep SPF domain matching relaxed with aspf=r or leave the tag unset. This lets a bounce subdomain match a From domain under the same organizational domain.
- Generator: Use the DMARC record generator if you want the record built with reporting and policy fields.
Check the DMARC record after publishing because parsers are strict. A missing semicolon, bad mailto value, or duplicate DMARC record can stop policy discovery and reporting before any Flexmail data appears.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A valid DMARC record does not mean Flexmail passes DMARC. It means receivers know which policy to evaluate. A real Flexmail test message still needs aligned DKIM or aligned SPF to pass.
|
|
|
|---|---|---|
p=none | Building baseline | Collect reports |
p=quarantine; t=y | Testing enforcement | Request none handling where t=y is supported |
p=quarantine | Legitimate sources pass | Treat failures as suspicious |
p=reject | Specialized domain only | Request rejection of failures |
Use DMARC policies only after Flexmail and other legitimate senders are authorized.
Use current DMARC policy tags
RFC 9989 marks pct historic because receivers handled percentage sampling inconsistently. Use t=y for testing instead of percentage-based rollout values.
- Remove percentage sampling: Do not publish new pct=10 or similar rollout values.
- Use testing deliberately: With p=quarantine; t=y, receivers implementing RFC 9989 apply none handling to failures. With p=reject; t=y, they apply quarantine handling. Remove t=y after reviewing results.
- Keep aggregate reporting: The rua tag remains active and lets you compare Flexmail results with other sources.
- Avoid historic tags: Do not add ri or rf to a new record; RFC 9989 also marked them historic.
RFC 9989 quarantine testdns
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
Testing depends on receiver support
Older DMARC implementations ignore an unknown t tag and apply the published p policy. Even when t=y is supported, receivers retain control of final delivery. Do not rely on testing mode to protect unauthenticated legitimate mail.
Check DMARC alignment in message headers
DMARC alignment compares the visible From domain with the authenticated SPF or DKIM domain. Flexmail's domain matching guidance explains why relaxed SPF matching is required. The Return-Path identifies the envelope sender; inspect smtp.mailfrom and header.d in the recipient's Authentication-Results to check the domains actually evaluated.
Illustrative results, actual Flexmail bounce domains varytext
From: Marketing <marketing@example.com> Return-Path: <bounce@bounce.example.com> Authentication-Results: mx.recipient.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=flexmail; dmarc=pass header.from=example.com
Here, bounce.example.com and example.com share an organizational domain, so SPF matches with aspf=r but not aspf=s. DKIM matches the From domain exactly. If SPF instead passes for an unrelated provider domain, it does not count toward DMARC; a matching DKIM pass still does.
Verify and troubleshoot
Verification has two layers: DNS visibility and actual message authentication. Check both, because green DNS indicators do not prove that a campaign passes DMARC. The visible From domain must match at least one passing authentication method under the applicable matching mode.
Flexmail SPF, DKIM, and DMARC authentication status indicators
- Allow propagation: Recheck after the DNS record's TTL. Flexmail advises allowing 24 to 48 hours for its authentication indicators to update.
- Refresh Flexmail: Return to Settings, Add or remove senders, then Set up authentication.
- Send test: Send a campaign or transactional test from the exact Flexmail sender address.
- Read headers: Open the recipient's full message headers or Show original view. Check its Authentication-Results for spf=pass and dkim=pass, then confirm dmarc=pass for the intended From domain.
- Use tester: Send a message to the test address below and inspect the SPF, DKIM, and DMARC diagnosis.
Flexmail's sender authentication manual distinguishes a red DKIM indicator with a green "authentication keys added correctly" badge from missing DNS. The green badge means DNS is detected but Flexmail is still installing the key. If the badge is red after 48 hours, compare the generated report with public DNS; contact Flexmail support if installation remains pending.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A DMARC pass does not guarantee inbox placement. Review authentication on a real Flexmail message before investigating delivery problems such as spam complaints or poor sending reputation.
Common Flexmail failures
- Sender unverified: Flexmail can block the sender before DNS matters.
- Duplicate SPF: Two SPF TXT records cause SPF permerror.
- Wrong DKIM host: The selector._domainkey host belongs in the DNS name field, not inside the TXT value.
- Strict SPF: aspf=s can fail if Flexmail uses a subdomain return path.
- DKIM installation: A green DNS badge with a red DKIM indicator means Flexmail is still processing the key; a red badge points to undetected DNS.
Policy decision checks
Use evidence about legitimate mail and indirect flows instead of a single pass-rate threshold.
Stay at none
Unresolved failures
Any legitimate source still fails.
Test quarantine
No known failures
Known sources pass and reports are stable.
Keep quarantine
General-purpose domain
The domain supports routine user mail or mailing lists.
Review reject
Specialized domain
The domain has a narrow sending purpose and aligned DKIM.
Monitor Flexmail authentication failures
Suped is our DMARC reporting and email authentication platform. Suped's DMARC monitoring turns aggregate reports into source-level authentication results and notifications so you can investigate Flexmail failures alongside other senders.
Notification settings page with DMARC alerts, weekly summary, toggles, and preview buttons
- Set alerts: Use threshold-based DMARC alerts for new failure spikes and source changes.
- Track source: Filter reported traffic to Flexmail and compare its SPF and DKIM results with the visible From domain.
- Review causes: Use source-level authentication results to distinguish SPF failures, DKIM failures, and domain mismatches.
- Cover clients: MSP and multi-tenant dashboards help agencies manage Flexmail across many domains.
- Watch reputation: Review blocklist (blacklist) alerts alongside bounce messages when investigating delivery failures.
What to monitor after launch
- Flexmail volume: Daily and weekly message count by domain.
- Pass rate: DMARC pass percentage for Flexmail traffic.
- New senders: Any source using the domain outside approved systems.
- DNS drift: SPF and DMARC record changes that break syntax or policy.
In Suped, review Flexmail results after each DNS change and investigate pass-rate drops before tightening policy. Aggregate reports cover traffic seen by reporting receivers; they are not a complete log of every message or immediate delivery alerts.
Choose DMARC enforcement safely
Use p=quarantine as the safer enforcement endpoint for a general-purpose domain. RFC 9989 says domains whose users post to Internet mailing lists should not publish p=reject because indirect flows can break authentication. Reserve reject for a narrowly used sending domain after aligned DKIM and indirect-flow testing.
General-purpose domain policy review
RFC 9989 recommends at least one calendar month at p=none and an equally long p=quarantine period for general-purpose domains evaluating p=reject. Observation must also cover normal sending cycles.
minimum observation period
- Inventory senders: Use DMARC reports to list Flexmail, mailbox, CRM, support, and transactional systems.
- Fix Flexmail: DKIM should pass with your domain, SPF should include Flexmail, and duplicate SPF should be removed.
- Hold none: Collect at least one month of aggregate reports and cover every normal send cycle.
- Move to quarantine: Remove all known legitimate failures, use t=y for a temporary test if needed, then observe full quarantine for at least one month.
- Review indirect mail: Test mailing lists and forwarding addresses because these paths can break SPF or DKIM.
- Choose endpoint: Keep quarantine for general-purpose mail. Consider reject only for a specialized domain with no routine mailing-list use and reliable aligned DKIM.
- Keep monitoring: New Flexmail senders, DNS edits, and staff changes can break authentication later.
Specialized-domain reject exampledns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r
Manual DNS edits
- Change risk: Each policy change touches DNS.
- Slow rollback: A bad enforcement change waits on DNS access.
- Low visibility: Reports sent to a mailbox need parsing to identify authentication failures.
Suped hosted DMARC
- Hosted policy: Suped's Hosted DMARC lets teams change policy without repeated DNS edits.
- Guided fixes: Suped shows source-level steps to fix before policy changes.
- Alerting: Alerts flag reported Flexmail authentication changes after enforcement.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
FAQ
Flexmail's public authentication guidance shows include:spf.flexmail.eu. Merge it into the existing SPF record for the domain specified in your authentication report; keep one SPF record per hostname.
No. RFC 9989 made pct historic because receivers applied percentage sampling inconsistently. Use full monitoring periods and t=y for temporary testing only after legitimate mail passes. Receivers that ignore the testing tag still apply the published policy.
Keep p=quarantine for a general-purpose domain used by people or mailing lists. A dedicated Flexmail sending subdomain can use p=reject after every approved sender passes DMARC and indirect mail paths have been reviewed. General-purpose domains evaluating reject should observe at least a month each at none and quarantine.
Set it up before production sending. Gmail's sender requirements require SPF or DKIM for all senders to personal Gmail accounts. Bulk senders need both SPF and DKIM plus DMARC, with p=none accepted. Its bulk-sender definition counts roughly 5,000 or more messages to personal Gmail accounts in 24 hours across a primary domain and its subdomains, rather than the size of your Flexmail contact list.
Configure both. SPF validates the envelope sender independently of the visible From domain; matching determines whether its pass counts for DMARC. A passing DKIM signature using your domain gives DMARC another pass path. Either method is sufficient when domain matching succeeds.
The public record often updates within its DNS TTL. Flexmail advises allowing 24 to 48 hours for verification. After 48 hours, compare the generated report with public DNS and distinguish missing records from pending Flexmail DKIM installation, then test a real message.
