One.com SPF, DKIM and DMARC setup, step by step

On this page: Choose your setup · SPF · DKIM and migration · DMARC · Verification · Troubleshooting · FAQs

For one.com-hosted email, first check the standard SPF setting and existing DNS policies. DKIM is automatic when the domain uses one.com’s mail servers and nameservers. With external DNS, get the exact DKIM CNAMEs from one.com support: the current dedicated DKIM guide distinguishes four records for non-migrated domains from two for migrated domains. Then verify public DNS and a real received message.

This guide concerns one.com’s hosted-mail service, including its documented migrated and non-migrated branches. Registration or website hosting at one.com alone does not make one.com your outbound mail service. No customer account, DNS settings or delivered messages were tested.

Choose the correct mail and DNS branch

Confirm nameserver delegation rather than relying on where the domain was purchased. one.com explicitly says external-nameserver users must manage the records at that external host. There is no requirement to migrate nameservers merely to keep using hosted mail. one.com external-DNS guidance

For website messages, the WordPress application-mail route guide helps distinguish the application from its outbound SMTP or API service.

Before editing, save the current zone and identify all active senders. Record each route’s visible From domain, MAIL FROM/Return-Path domain, DKIM d= domain and selector when available. Check aliases and subdomains too. Access to the mailbox alone may not provide permission to edit the authoritative DNS zone.

Do not use Reset DNS records as a quick fix. one.com documents that this removes personal DNS settings and restores defaults. That can affect the website, verification records and other mail services. Make the smallest reviewed change instead. one.com DNS settings

Configure SPF without creating duplicate policies

When one.com hosts DNS

The current official SPF guide says newer domains have the standard record enabled automatically. In the Control Panel, go to Domains → DNS settings → Standard DNS settings, locate the domain’s TXT entry above the _dmarc entry, and inspect its toggle. Enable it only after checking that the standard policy is appropriate and will not conflict with an existing custom policy. The guide allows up to 90 minutes for the change. Current one.com SPF workflow

If several providers send for the same envelope domain, use a reviewed custom policy rather than assuming the standard one covers them. In one.com’s DNS editor, a root-domain hostname can be left empty; @ is treated as empty. Its general DNS guidance says conflicting custom records disable standard settings. Inspect the effective public result after making a custom change rather than relying solely on a toggle. one.com DNS record behavior

When another provider hosts DNS

one.com publishes this SPF TXT value for its hosted mail with external DNS:

v=spf1 include:_custspf.one.com ~all

Use it as a standalone policy only when there is no existing SPF policy at the appropriate owner and it covers your actual sending requirements. If other services already send, merge include:_custspf.one.com into their shared policy instead of replacing them. Official external-DNS SPF value

Keep the existing final ~all or -all choice unless an intentional review changes it. The example’s softfail ending is not a reason to weaken a working hardfail policy. Never paste two v=spf1 strings together or publish a second policy at the same owner.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Make sure SPF is being checked at that name

SPF evaluates the SMTP MAIL FROM domain, not the recipient-visible From address. If the reverse path is empty, a HELO-derived identity is used. A record for example.com does not automatically apply to bounce.example.com. Use a real message to establish which domain is evaluated before changing DNS. SPF identity and selection

Review nested SPF processing after every merge. The limit is 10 evaluated DNS-query-causing terms, including includes and redirects encountered recursively. More than one matching SPF policy or excessive lookup terms can produce permerror. Preserve unrelated TXT records and do not replace missing sender knowledge with +all. SPF lookup limits

Enable DKIM using the domain’s actual migration status

one.com mail and one.com nameservers

The dedicated DKIM guide says signing is activated automatically for this combination. Do not generate or upload a replacement private key just because another tutorial mentions a DKIM generator. Verify the signature on a real message before deciding that any repair is needed. one.com DKIM behavior

one.com mail and external nameservers

Obtain the exact CNAME hostnames and targets from support for your domain. Confirm whether the domain has been migrated and ask for the complete current record set:

• Non-migrated domain: four CNAME records.
• Migrated domain: two CNAME records.

Publish the provided names and targets at the external authoritative DNS host. The dedicated DKIM article gives an expected propagation period of up to 240 minutes. Do not invent missing selectors or reuse another customer’s targets. one.com’s migration-aware DKIM instructions

Why some instructions say four records for everyone

one.com’s broader external-nameserver article still describes four DKIM records, while its dedicated DKIM article distinguishes migrated domains. Follow the domain-specific set supplied by support, not a fixed record count taken out of context. Keep existing working records until support confirms the migration and retirement plan. External-DNS article, dedicated DKIM article

Publish CNAMEs, not invented TXT keys

For each requested record, save its full owner name, type and exact target. In the DNS editor:

1. Choose CNAME where one.com requests CNAME.
2. Enter the owner in the relative or full-name form the editor expects.
3. Enter the target hostname exactly, not a URL or IP address.
4. Check that automatic suffixing has not duplicated your domain.
5. Verify no conflicting TXT, A or other ordinary record already occupies that CNAME owner.

A CNAME owner cannot also carry other ordinary data. Resolve a conflict with the service that owns the existing record instead of deleting it blindly. DKIM delegation is DNS, not web forwarding. DNS alias requirements

Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

The receiving server follows the DKIM signature’s selector s= and signing domain d= to discover the public key. Publishing a self-generated TXT key will not make it match one.com’s private signing key. Leave key management to the supported provider workflow. DKIM key discovery

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Keep MX changes separate

MX controls incoming delivery, not DKIM signing. one.com also documents migration-dependent MX formats, with a domain-specific cluster for migrated domains. Do not change incoming routing or remove existing gateways merely to solve an outgoing authentication problem. If a mail migration is actually intended, obtain the precise MX and DKIM sets together and preserve a rollback record of the prior zone.

Only for an independently approved incoming-mail migration, obtain separate routing-owner approval of the full MX owner, numeric priorities and complete target set. Compare every approved tuple with authoritative and recursive DNS before activation. Stop on missing, extra or mismatched routes and preserve unrelated services; receiving a support packet alone does not authorize rerouting.

Preserve or intentionally configure DMARC

DMARC passes when either SPF authenticates an aligned MAIL FROM domain or DKIM authenticates an aligned signing domain. Relaxed alignment requires the same organizational domain; strict alignment requires the exact domain. A passing result for an unrelated provider domain is not an aligned pass for your visible From address. RFC 9989 DMARC

one.com enables a standard DMARC record for newer domains. The current Control Panel path is Domains → DNS settings → DNS records → Standard DNS settings → Show all, then the _dmarc TXT toggle. Inspect the record and any custom policy before enabling or replacing it. Do not assume what enforcement value the standard toggle represents for your domain. one.com DMARC settings

For a custom policy, the documented route is Create new record → TXT, with _dmarc as the hostname and your reviewed policy as the value. one.com says creating a custom DMARC record disables its standard DMARC record automatically; verify that only the intended policy remains publicly visible.

If no applicable policy exists and you are beginning a monitored rollout, an illustrative first-time record is:

Hostname: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example mailbox before publication. Do not use this template to downgrade an established p=quarantine or p=reject policy. Check any applicable parent-domain policy before deciding that a subdomain has no protection.

Before publishing a first policy, obtain the domain owner’s explicit approval of the monitoring rollout and provision the actual replacement rua destination. Confirm that the owner approves that recipient and that someone will monitor and review its reports. Do not publish an unprovisioned example mailbox or replace a direct or inherited policy.

Put DMARC at the intended DNS owner

For a policy directly on example.com, the full owner is _dmarc.example.com; a relative-name editor for the example.com zone normally needs _dmarc. For a deliberate policy directly on billing.example.com, the full owner is _dmarc.billing.example.com: enter _dmarc.billing in the parent example.com zone, or _dmarc in a separately delegated billing.example.com zone. These are naming examples, not a recommendation to override an existing parent policy. Check the published full name and applicable policy before changing it.

Use aggregate reports to identify other senders and alignment failures over time. An external report destination may need authorization at the destination. External-destination authorization Failure reports can expose headers or message content, so make a deliberate privacy decision before adding ruf. Aggregate reporting, failure reporting

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

Move toward enforcement after legitimate routes have been checked and failures resolved. RFC 9989 supersedes RFC 7489 and removes pct, so do not rely on an older percentage-based rollout recipe. Authentication is one part of delivery quality, not an inbox-placement guarantee.

Verify the published records and a received message

1. Establish DNS authority and effective policies

Use your real domain in these read-only command examples:

dig +short NS example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Expect the authoritative delegation you intend, one SPF policy at the evaluated envelope domain, and one deliberate DMARC policy at its owner. Inspect a subdomain separately when the actual MAIL FROM identity uses one. Preserve unrelated verification TXT records.

2. Check every supplied DKIM CNAME

Replace both example names below with a support-issued owner and target. Repeat for all required records, not just the first one:

dig +short CNAME selector1._domainkey.example.com
dig +short TXT dkim-target.provider.example

The first answer should match the exact target provided by one.com. The delegated target must ultimately resolve to the public DKIM key. Also check the selector actually used in a received signature; a record for a different selector does not validate that message.

If the answer is missing or stale, compare the authoritative nameserver and a recursive resolver:

dig @ns1.dns-provider.example CNAME selector1._domainkey.example.com
dig @1.1.1.1 CNAME selector1._domainkey.example.com

Replace the example nameserver with one from the domain’s NS answer. Correct authoritative data with stale recursive data can require TTL or negative-cache expiry. Wrong authoritative data, SERVFAIL or a doubled suffix needs correction or DNS support, not merely more waiting.

3. Verify the real mail route

After setup, send representative messages from one.com webmail and your configured mail client to an external mailbox you control. Test website and third-party application mail separately. Read the receiver’s authentication results, not an arbitrary header supplied by the sender. Authentication-Results trust considerations

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For each message, check:

• SPF result and the exact smtp.mailfrom domain.
• DKIM result, header.d signing domain and signature selector s=.
• DMARC result for the visible From domain.
• Whether at least one passing method aligns under the applicable policy.

To verify one.com DKIM, require dkim=pass for the expected support-issued or automatically provisioned selector, with d= aligned to the final visible From domain. A pass only for an unrelated provider domain does not verify this setup. Also investigate SPF fail, softfail or temperror at the actual envelope domain even if aligned DKIM makes DMARC pass; a DMARC pass does not erase a separate authorization or DNS fault.

For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment.

Keep the timestamp, recipient provider, message ID and failure text if anything is wrong. A successful DNS lookup confirms publication; a received message demonstrates how one specific route actually authenticated. Recheck after migration, nameserver changes or a new application sender.

Common one.com authentication problems

When contacting support, include the domain, current nameservers, migration information, requested CNAMEs, affected route and redacted received-header evidence. Do not share passwords or private signing keys.