How to set up DMARC/DKIM/SPF for Selzy
Published 10 Aug 2026
Updated 18 Oct 2026
12 min read
Summarize with
Updated on 18 Oct 2026: We revised Selzy verification and DMARC rollout steps to cover From address replacement and remove outdated percentage-based enforcement.
To authenticate Selzy, confirm a sender address on the business domain, add that domain under Settings > Domain Authentication, and publish the SPF and DKIM TXT values Selzy generates. Then publish one DMARC TXT record at _dmarc, test a real campaign, and move to p=reject only after every approved sender passes aligned SPF or DKIM.
What successful authentication looks like
A Selzy message passes DMARC when at least one authenticated domain has alignment with the visible From domain: SPF through the return-path domain or DKIM through the signing domain. Keep both paths working where supported, but DMARC needs only one aligned pass.
Add and confirm your Selzy sender domain
Selzy will not create domain authentication settings until a sender address on that domain has been confirmed. Use a monitored mailbox on a domain you control and complete these steps before editing DNS. Publish the records at the authoritative DNS provider identified by the domain's nameservers; this is not always the registrar or website host.
- Open account settings. In Selzy, go to Account > Settings > Account setup > Confirmed emails.
- Confirm the sender. Click Add, enter the business email address and sender name, click Confirm, then use the confirmation button delivered to that mailbox.
- Create the domain. Go to Settings > Domain Authentication, click Create, enter the bare domain without https:// or a path, and click Obtain Settings.
- Save the generated values. Keep the Selzy window open. The DKIM value is unique to the domain, so copy it from the account rather than from an example.
Selzy Confirmed emails settings for confirming a business-domain sender address
The domain in the confirmed address must exactly match the domain added for authentication. Selzy documents this prerequisite and the current menu path in its Selzy setup instructions.
Selzy Domain Authentication settings for obtaining SPF and DKIM DNS records
|
|
|
|---|---|---|
Confirm sender | Confirmed emails | Address confirmed |
Create domain | Domain Authentication | Settings displayed |
Publish DNS and refresh Selzy | DNS provider, then Domain Authentication | Records resolve publicly; Selzy shows Enabled |
Selzy setup checkpoints
Set up SPF
Selzy's documented SPF mechanism is include:spf.selzy.com. Add it at the host specified in the account, while preserving every legitimate sender already present in that host's single SPF record. In the root-domain examples below, @ means example.com. A sending subdomain needs records at its own DNS names; SPF is not inherited from its parent.
- Inspect the sending domain. Check whether the domain already has a TXT value beginning with v=spf1.
- Create or merge. If no SPF record exists, publish Selzy's record. If one exists, insert include:spf.selzy.com before its final all mechanism, preserving the existing qualifier such as -all or ~all.
- Keep one record. Never publish a second SPF TXT record. Multiple SPF records cause a permanent evaluation error.
- Count lookups. Keep SPF evaluation within the limit of ten DNS-querying terms, including nested include mechanisms and redirect modifiers. The limit is not simply ten include entries.
SPF record for a domain that sends only through SelzyDNS
Host: @ Type: TXT Value: v=spf1 include:spf.selzy.com ~all
Merged SPF pattern when another sender already existsDNS
Host: @ Type: TXT Value: v=spf1 include:spf.selzy.com include:_spf.example.net ~all
The second record is a pattern. Replace the example include with the mechanism already authorized for the domain and retain the existing final all qualifier. If the record uses redirect= instead of all, add Selzy's include while preserving that delegation; adding all would disable redirect. Confirm there is still only one SPF record at that host.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The checker should return one syntactically valid record and no lookup-limit error. SPF checks the SMTP MAIL FROM domain, usually shown in Return-Path, rather than the visible From address. Compare those domains in a delivered Selzy message to evaluate SPF alignment. SPF evaluation rules are defined in RFC 7208.
Do not assume the Selzy return-path uses your domain. Publishing an SPF record on your From domain does not change the return-path Selzy uses. If that domain is unrelated to your From domain, rely on aligned DKIM for DMARC and ask Selzy whether the account supports a custom return-path.
Do not copy an include from a lookup database
An SPF include can identify a service without proving that the service currently requires it for your account. Selzy's public instructions specify include:spf.selzy.com. Compare it with the value displayed in the Selzy Domain Authentication panel before publishing.
Set up DKIM
Selzy generates the DKIM public key for each authenticated domain. Its public example uses the selector us. Copy the exact host and full TXT value shown in the account because the key belongs to that domain.
- Copy the host. In Settings > Domain Authentication, copy the selector host. Selzy commonly displays us._domainkey.
- Copy the key. Copy the complete TXT value beginning with v=DKIM1. Do not copy the shortened key shown in documentation.
- Publish one TXT record. Add the host and value at the authoritative DNS provider. Leave TTL at the provider default. A long key split into quoted strings within one TXT record is valid when the strings concatenate to the complete value.
- Avoid a doubled domain. If the DNS panel automatically appends the zone name, enter only the relative host. The final name must resolve once, not as us._domainkey.example.com.example.com.
Selzy DKIM TXT settings showing the us._domainkey selector and authentication status
DKIM record structureDNS
Host: us._domainkey Type: TXT Value: Copy the complete unique value shown in Selzy
Use DKIM for DMARC alignment
Prioritize aligned DKIM because forwarding often breaks SPF. Under relaxed alignment, the DKIM d= domain and visible From domain must share an organizational domain; strict alignment requires identical domains. A cryptographic DKIM pass with an unrelated signing domain does not satisfy DMARC. DKIM survives forwarding only if the signed content remains valid. DMARC alignment is defined in RFC 9989; DKIM signing and verification are defined in RFC 6376.
Set up DMARC
For From addresses at example.com, publish DMARC at _dmarc.example.com. For a From subdomain, check _dmarc on that subdomain and its inherited policy before adding a record. If no policy applies, start with p=none so reporting begins without requesting enforcement. Preserve an existing p=quarantine or p=reject policy while authenticating Selzy.
Starting DMARC recordDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
Replace dmarc@example.com with a mailbox or reporting address that processes aggregate XML reports. The DMARC record generator builds the TXT value for reporting, subdomain policy, and alignment controls. An explicit DMARC record on a sending subdomain overrides the inherited policy, so check its effect before publishing. Policy discovery is specified in RFC 9989.
- Check for an existing record. Query _dmarc.example.com, or _dmarc on the actual From subdomain, before publishing. Keep only one DMARC policy record at each name.
- Publish at _dmarc. Create a TXT record using the starter value and replace the report address.
- Keep the current policy. Do not change quarantine or reject back to none merely to add Selzy. Authenticate Selzy first and preserve enforcement.
- Read alignment results. Confirm that Selzy traffic passes DMARC through aligned DKIM, aligned SPF, or both.
DNS syntax and discovery should be checked independently of Selzy's status. This catches a misplaced host, duplicate TXT record, malformed tag, or stale value before a campaign depends on it.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker should find the applicable DMARC policy and parse the version, policy, and aggregate reporting address. Correct DNS errors before judging message-level authentication.
A valid p=none record collects evidence but does not tell receivers to block impersonation. It is the observation stage, not the end state.
If rua points outside your organizational domain, the report destination must authorize external reporting in DNS. Use the address supplied by Suped for your domain and verify authorization if reports are missing. Aggregate reporting and external destination checks are specified in RFC 9990.
Verify and troubleshoot
Verify DNS first, refresh Selzy second, and inspect a delivered message last. Selzy says its authentication status often takes 30 minutes to a couple of hours to update, so an immediate Created or Disabled status does not prove the DNS records are wrong. Cached answers can persist until their previous TTL expires.
- Resolve the records. Confirm the SPF TXT record at the configured host, the Selzy DKIM selector, and the applicable _dmarc record through public DNS.
- Refresh Selzy. Open Settings > Domain Authentication and click the circular arrows icon beside the domain status.
- Send a real test. Use the same From domain and sending route planned for campaigns. A DNS lookup alone cannot confirm alignment.
- Inspect authentication results. Read the receiving mailbox's Authentication-Results header. Check spf=pass, dkim=pass, dmarc=pass, smtp.mailfrom, header.d, and header.from. In DKIM-Signature, use d= for the signing domain and s= for the selector.
Use Suped's email tester to generate a test address. Send one Selzy campaign to it, then review DNS, authentication, alignment, and message construction in the resulting diagnosis.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the test passes DKIM with alignment but fails SPF alignment, DMARC passes through DKIM. Check the actual From and return-path domains before changing DNS, and leave the working DKIM record untouched.
If Selzy still shows Disabled after public DNS resolves correctly, check for a doubled DNS suffix, literal quotation marks pasted into the value, a key at the wrong selector, duplicate SPF records, or changes made at a non-authoritative provider. Quotation marks used by DNS tools to display TXT strings are normal.
DNS looks wrong
- Missing selector. Publish the DKIM TXT record at the exact host shown by Selzy.
- Multiple SPF records. Merge all authorized mechanisms into one SPF TXT record at the affected host.
- No DMARC result. Check that the host resolves as _dmarc.example.com.
DNS looks correct
- Selzy status lags. Wait for DNS caching, then use the refresh icon.
- DKIM fails in mail. Compare the message's DKIM d= and s= values with the published key, and check whether signed content changed after signing.
- DMARC fails. Compare the From domain with SPF and DKIM identity domains.
For a wider DNS review, Suped's domain health checker checks the domain-level authentication records together. Use the email test for message-level alignment because that result depends on the actual Selzy message.
Check for Selzy From address replacement
Selzy can replace the From domain with a shared domain such as sendwithselzy.com when DKIM is not Enabled or the sender uses a freemail address. A DMARC pass for that replacement domain does not verify authentication for your business domain. Selzy documents this behavior in its email setup instructions.
Inspect the delivered From address, complete business-domain authentication, wait for Enabled, and send another campaign test. Check Reply-To separately: Selzy retains an existing Reply-To or uses the original From address when none was set.
Monitor Selzy authentication and alerts
A one-time pass does not catch a later DNS edit or a new sending source. Suped's DMARC monitoring is our product for turning aggregate reports into source-level authentication results. Use it to review Selzy traffic and investigate new sources or authentication failures.
- Monitor Selzy traffic. Identify Selzy volume and confirm aligned SPF or DKIM continues to pass.
- Alert on regressions. Notify the domain owner when authentication failures rise or the DMARC policy changes.
- Review unknown sources. Classify each source before authorizing it, fixing it, or treating it as unauthorized.
- Watch related controls. Review domain or IP blocklist (blacklist) listings alongside authentication failures.
Aggregate reports normally cover a day of traffic and arrive after that reporting period. Report-based alerts depend on report receipt, so they do not provide an immediate result for every message. Reporting periods are defined in RFC 9990.
Route alerts for new sources and meaningful pass-rate shifts to the people who can change DNS or Selzy settings. Keep an owner for each approved sending source.
Move safely to p=reject
Move to p=reject after DMARC reports show that every approved sender has a stable aligned pass and unknown traffic has been classified. Leave aggregate reporting enabled after enforcement so future changes remain visible.
- Build the source inventory. Use DMARC data to identify Selzy and every other approved sender that uses the From domain.
- Fix alignment first. Require each approved source to pass aligned DKIM or SPF. For Selzy, keep DKIM enabled even when SPF also aligns.
- Observe complete cycles. Cover regular campaigns plus less frequent automated sends before enforcing policy.
- Stage enforcement. Move to quarantine after validating approved senders, review fresh reports, then replace quarantine with reject. Treat each policy change as applying to all DMARC-failing mail.
- Keep monitoring. Watch for new sources, DNS drift, and Selzy authentication changes after enforcement.
Example enforcement stagesDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
These are successive replacement values, never simultaneous records. Replace the report address and review fresh data before advancing. RFC 9989 removed pct and marks it historic, so percentage-based staging is not a reliable safety control. Receiving systems retain discretion over final message handling.
Ready to enforce
- Known sources. Every approved sender has an owner and purpose.
- Stable alignment. Approved mail passes aligned SPF or DKIM consistently.
- Reporting active. Aggregate data reaches a monitored destination.
Pause the rollout
- Unexplained volume. Classify the source before enforcement.
- Legitimate failures. Correct alignment without weakening working senders.
- Missing cycles. Wait for scheduled and low-frequency mail to appear.
Never weaken an enforced domain for Selzy
If the domain already uses p=quarantine or p=reject, keep that policy. Add Selzy's SPF and DKIM records, send controlled tests, and confirm aligned authentication before using Selzy for production campaigns.
Frequently asked questions
Yes. Publish both records generated for the domain. DMARC passes when either SPF or DKIM passes with alignment to the visible From domain, but keeping both working adds resilience. DKIM is especially important because forwarding often breaks SPF.
The include:spf.selzy.com mechanism is associated with Selzy. Do not publish it solely because a database links it to Selzy. Confirm the current SPF value in the Selzy Domain Authentication panel and current Selzy instructions for your account, then merge it into the domain's single SPF record.
No. Keep one SPF record per host. Add include:spf.selzy.com before the existing record's final all mechanism, preserve its qualifier and every other approved sender, and check the ten-lookup limit. For a redirect-based record, preserve the delegation instead of adding all.
DMARC uses OR logic. An aligned DKIM pass is enough even when SPF fails or uses an unrelated return-path domain. Keep DKIM passing with alignment and inspect the actual return-path before changing SPF. A DNS edit on the From domain does not change Selzy's envelope sender.
Selzy documents a delay of about 30 minutes to a couple of hours for the status to update. Confirm the records resolve publicly, then use the circular refresh icon in Settings > Domain Authentication.
Start a new DMARC deployment at p=none, collect reports, validate every approved sender, and then stage enforcement. If the domain already has p=quarantine or p=reject, keep it and authenticate Selzy before production use.
