easyDNS SPF, DKIM and DMARC setup, step by step

For easyMail hosted mail on easyDNS authoritative DNS, inspect existing signing first. The documented first-time workflow is EMAIL → EASYMAIL → the domain’s advanced settings, where easyMail can create SPF and generate DKIM. Its example SPF is v=spf1 include:easymail.ca ~all, and its generated DKIM TXT appears at easymail._domainkey.YOUR-DOMAIN. Do not run the setup over existing records without resolving its replacement warnings. easyMail SPF and DKIM instructions.

The provider’s setup screen warns that the SPF option removes the existing SPF record and that enabling DKIM removes existing DKIM keys and TXT records. The full affected owner scope is not established by the screenshot. This guide therefore covers verification of existing signing and a narrowly defined, safe first-time authentication state. It does not offer an automatic merge or key-rotation procedure.

Confirm that this is easyMail, not just easyDNS

Use this procedure only for an already-enabled easyMail custom-domain mailbox with its DNS hosted authoritatively by easyDNS. A domain registration or DNS subscription alone does not prove that easyMail sends the message.

The documented mailbox route uses mailout.easymail.ca for outgoing SMTP, authenticating with the full easyMail email address. The provider also documents easyMail webmail. Keep the existing encrypted client connection; adding SPF or DKIM does not require changing passwords or weakening transport security. easyMail settings and specifications.

These are separate cases:

• easySMTP/easyOutbound: a distinct outbound-mail service with its own activation controls. Its settings are not proof of the easyMail mailbox workflow.
• External DNS: easyMail documents mailbox MX use with another DNS host, but that alone does not establish a complete external-DNS DKIM activation procedure.
• External-domain send-as: additional authorization can require Support and account-specific verification.
• A self-managed server: publishing a key at easyDNS does not configure that server to sign.

The easyMail sending policy requires authorized domains and can reject attempts to send as an unrelated external address. Use an owned, authorized mailbox identity rather than treating any From address as permitted. easyMail outbound authorization policy and separate easySMTP instructions.

This is not a new-mailbox activation guide. The separate setup procedure includes controls that can change MX routing. Do not use QUICK ENABLE, change nameservers or migrate incoming mail merely to configure authentication. Separate easyMail setup procedure.

First check whether DKIM already works

easyDNS’s provider announcement says DKIM is enabled by default on easyMail. The support article also documents a manual enable workflow. Inspect the actual domain instead of assuming it needs regeneration. Provider announcement about default DKIM.

Before making changes:

1. Identify the exact mailbox domain and its authoritative DNS.
2. Save the complete relevant zone and current easyMail configuration.
3. Inspect the existing SPF, easymail._domainkey TXT, other selectors and any _domainkey delegation.
4. Inspect a newly received easyMail message, following the trusted-header checks below.
5. If the intended aligned easyMail signature already passes, leave its working key and signing state alone.

An ENABLED mailbox label is not proof of DKIM, and a public TXT key is not proof that the server used it. Equally, a working signature is not a reason to click Enable DKIM again. Keep signing verification and configuration changes separate.

Treat the replacement warning as a stop gate

The official advanced-settings screenshot shows two consequential controls:

• Create SPF record? replaces an existing SPF policy with the displayed easyMail policy.
• Enable DKIM? warns: “Existing DKIM keys and TXT records will be removed and a new key and TXT record will be created”.

The result screenshot shows the new SPF owner and easymail._domainkey TXT owner. It does not prove that deletion is restricted to those two names. Do not assume that unchecking another box preserves every old selector or unrelated TXT record.

When a first-time setup can proceed

Establish all of these conditions before using the creation controls:

• The easyMail mailbox service is already enabled for the intended domain.
• There is no existing SPF policy to replace at the domain being configured.
• There is no existing easyMail key or other DKIM signing configuration to overwrite.
• The complete DNS and account inventory establishes that there are no existing TXT records or keys exposed to the warned replacement.
• There is no unresolved _domainkey delegation, shared sender dependency or conflicting selector record.
• The domain owner has approved the precise first-time changes and a recovery plan.

A lookup for one selector is not a complete inventory. Existing DMARC, verification TXT records and other services’ selectors matter too. If any record could be affected, or the deletion scope cannot be established, stop before saving. Obtain a documented non-destructive procedure from easyDNS for that existing state.

For a mixed-sender domain, simply replacing SPF with the easyMail-only example would remove other authorizations. Likewise, a new DKIM key can invalidate mail signed with an old key that is still in transit. This guide does not claim the checkbox supports safe overlap rotation.

If another staff-mail service is also in use, its setup remains separate. For example, the Microsoft 365 authentication guide covers Exchange Online, not easyMail. Preserve that service’s configuration and resolve the mixed-domain change before using an easyMail replacement control.

Understand the SPF record before creating it

The easyMail authentication screenshot shows this new-policy value:

v=spf1 include:easymail.ca ~all

Its type is TXT, at the configured mailbox domain. The authorization mechanism is include:easymail.ca. This is an easyMail-only first-policy example, not a second record to add alongside an existing policy. Official easyMail record output.

SPF normally evaluates the SMTP MAIL FROM domain, commonly represented by Return-Path after delivery. It does not automatically evaluate the visible From. HELO can be evaluated in applicable cases. The reviewed easyMail instructions do not establish a universal envelope rewrite or a strict-alignment guarantee. Inspect the actual receiver-reported SPF identity. SPF identities.

Publish one v=spf1 policy per evaluated owner. Parent-domain SPF is not automatically inherited by a sending child domain. If existing mail uses a or mx, those mechanisms authorize address records or mail-exchanger addresses; they are not harmless decorations. Review which systems really send before removing or retaining authorizations as part of a separately planned reconciliation.

The ten-term SPF limit counts DNS-querying mechanisms and modifiers during evaluation, including nested processing. It is not ten top-level includes, and grouping services behind another include does not bypass it. SPF DNS lookup limits.

Also preserve the meaning of an existing redirect= policy: an all mechanism causes redirect to be ignored. Do not append the sample’s ~all to such a policy without deliberate review. SPF redirect behavior.

The example’s ~all produces softfail for an unmatched source. It does not mandate a particular inbox or rejection outcome. Do not change it to -all merely to improve a checker’s display.

Use the documented first-time easyMail controls

Proceed only after the safe first-time conditions above are established. If signing already works, skip creation and continue with verification.

1. Sign in to the easyDNS account for the domain.
2. Open EMAIL, then EASYMAIL.
3. Locate the domain’s host row and open ADVANCED SETTINGS.
4. Review the proposed SPF and DKIM creation options and their replacement warnings.
5. For the approved first-time configuration, select the required options, choose NEXT, inspect the confirmation and confirm only the intended changes.
6. Inspect the resulting TXT records in DNS Settings.

The support article calls the tab HOSTS, while its actual screenshot labels the tab ACTIVATE and the section EASYMAIL Hosts. Use the domain’s advanced-settings row, not a similarly named control for another service. Official workflow.

Leave Disable easyMAIL untouched. Do not select Enable Autoconfigure as an authentication fix: the screen says it creates SRV and URL-forwarding records. Those are additional changes, not DKIM prerequisites.

If the confirmation proposes removing unexpected data, cancel rather than assuming the change is harmless. Do not attempt to reconstruct unknown old keys after a destructive save.

Inspect the complete generated DKIM TXT

The provider’s illustrated result has this form:

• Type: TXT
• Full owner: easymail._domainkey.YOUR-MAILBOX-DOMAIN
• Value: the complete account-generated tagged public-key value beginning v=DKIM1; k=rsa; p=

There is no universal public key to copy. The screenshot key is truncated and belongs to an example domain. Use the complete current generated TXT output, preserving the tags and full public key. Never publish a private key. easyMail generated-record screenshot and DKIM key records.

For the fictional mailbox domain example.com, the full owner is easymail._domainkey.example.com. An editor that appends example.com would use the relative name easymail._domainkey; the SPF owner is the apex, often @.

For a fictional mailbox domain mail.example.com, the full owner would be easymail._domainkey.mail.example.com. In a parent example.com zone its relative name is easymail._domainkey.mail; in a separately delegated mail.example.com zone it is easymail._domainkey. These examples explain owner mapping, not permission to add an unapproved send-as domain.

Do not place a TXT key at an owner already occupied by a CNAME. Do not delete an existing _domainkey NS delegation to make the sample fit. Such existing states fall outside this first-time automatic workflow and require reconciliation with the responsible DNS/signing administrator.

A long TXT record may be displayed as multiple quoted strings belonging to one resource record. Preserve the complete concatenated value. Do not split one public key into competing TXT records or drop everything except the text after p=.

Check public DNS and then a real mailbox message

For a configured fictional domain example.com, these read-only examples inspect relevant records. Replace the domain with the one actually being configured:

dig TXT example.com
dig TXT easymail._domainkey.example.com
dig TXT _dmarc.example.com

Compare the public TXT value with the exact generated record in the account. Query the authoritative server when cached recursive answers differ. Record the change time and old TTL rather than repeatedly generating new keys while caches expire.

Then send a fresh, authorized message through the intended easyMail mailbox route to a controlled external mailbox. Save the raw received headers. A test from a different provider or a local mail program that uses another SMTP server does not validate easyMail.

Use Authentication-Results produced inside the actual receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results. Ignore untrusted fields supplied before that boundary. A familiar authserv-id or a high position in the header list is not proof of authenticity. If the boundary is unclear, have the recipient administrator identify the receiver’s assessment. Authentication-Results security considerations.

Acceptance for branded easyMail signing requires:

• The intended visible From remains unchanged.
• The intended easyMail DKIM signature passes, with the expected easymail selector and a signing domain aligned to that From.
• The trusted receiver reports dmarc=pass.
• The actual MAIL FROM, sending IP and SPF result are recorded separately.

DMARC can pass through aligned SPF or aligned DKIM. A pass carried only by SPF does not establish that the easyMail key change worked. A passing signature for an unrelated provider domain also does not establish brand alignment. DMARC alignment.

Relaxed alignment uses the same Organizational Domain; strict alignment requires identical domains. Do not assume that a child envelope domain is a strict match. Check d=, receiver-reported smtp.mailfrom and the actual policy modes.

Preserve DMARC instead of copying a default template

Before adding DMARC, inspect the exact visible From domain and any applicable inherited policy. Preserve current enforcement, alignment settings and approved reporting. A missing direct record does not necessarily mean the domain has no policy. DMARC policy discovery.

Only where no direct or applicable inherited policy exists, and the owner approves a monitored initial deployment, a minimal policy value is:

v=DMARC1; p=none

Use type TXT. For example.com, the full owner is _dmarc.example.com and the relative owner in that zone is _dmarc. For mail.example.com, the full owner is _dmarc.mail.example.com: use _dmarc.mail in the parent zone or _dmarc in a separately delegated child zone.

Create only one policy at the intended owner. This monitoring example requests neither quarantine/rejection nor reports. Do not use it to replace an existing policy or to hide a failing easyMail route.

If aggregate reports are wanted, add an approved functioning rua=mailto: destination and assign responsibility for reviewing them. Decide access, retention and permitted sharing because reports reveal sending activity.

A destination in a different Organizational Domain from the policy domain requires the report-generating receiver’s DNS authorization check. A destination within the same Organizational Domain is excepted. This check is separate from the domain owner’s permission to share the data. RFC 9990 section 4.

Do not copy a report recipient or enable failure reporting from a generic template. A provider’s default or suggested policy is not an approval to weaken existing protection.

Troubleshooting and safe recovery

The key exists, but DKIM is missing: confirm the mailbox really uses easyMail and the correct authorized domain. Do not regenerate keys as the first diagnostic step. Preserve the current configuration and ask the provider about the signing state if the documented route remains unsigned.

The key is truncated or the owner is wrong: compare full account output and authoritative DNS. Repeated domain suffixes, missing tags and competing TXT records need correction, not a generic waiting period.

A new key caused failures: stop further changes. DNS restoration alone may not restore the old private signing key. Coordinate recovery with the provider, preserve public keys still needed by delayed messages and retest the final route.

SPF permerror: inspect duplicate policies, syntax and evaluated nested lookup terms. SPF temperror: investigate temporary DNS resolution. SPF fail: compare the actual envelope domain and sending IP with the relevant policy. Resolve these independently even if aligned DKIM lets DMARC pass.

Send-as is rejected: check domain authorization. The provider’s external-domain procedure may require Support; do not bypass it by changing the visible From to an unapproved identity.

DKIM passes but DMARC fails: inspect the passing signature’s domain and the visible From. Correct the route or signing identity rather than downgrading DMARC.

Authentication passes but a recipient filters the message: investigate the SMTP response, reputation, content and recipient policy separately. Neither SPF nor DKIM guarantees inbox placement.

For handover, retain the original zone/account inventory, approved changes, generated public record, DNS results and redacted receiver evidence. Exclude credentials and private keys. Roll back only integration-owned changes after checking dependencies; do not undo MX or unrelated TXT records indiscriminately.

Documentation and testing limits

The easyMail instructions, decisive setup screenshots, settings, outbound policy and provider default-DKIM announcement were reviewed. No account changes, DNS publication, key generation or test email was performed.