Melbourne IT SPF, DKIM & DMARC Setup: Step-by-Step Guide

No customer account, DNS change or message-sending test was performed.

Use Melbourne IT's DNS editor only when it manages the authoritative zone for your domain. Obtain SPF and DKIM records from the service that actually sends your email, then publish them in the correct Melbourne IT editor. Domain-only accounts use the portal's DNS tab; cPanel or WordPress hosting customers use their hosting service's DNS controls. This guide covers DNS publication, not generating keys or enabling signing inside an email product.

There is no universal Melbourne IT SPF include or DKIM selector to add merely because Melbourne IT registered your domain. Microsoft 365, a marketing platform and a hosted mailbox can require different records. Identify each legitimate sender before changing anything.

Choose the correct Melbourne IT editor

Melbourne IT's current migration guidance distinguishes domain-only DNS from DNS managed through cPanel, WordPress hosting or a server. Registration, DNS, websites and email can be supplied by different companies. Check the public authoritative nameservers and the actual zone that contains the owner you intend to edit. A record visible in your account is not proof that the internet uses that copy.

Domain-only portal DNS: use the DNS tab and select the domain. The current client-area guide documents adding records and locating an existing record to edit.
cPanel or WordPress hosting: Melbourne IT documents cPanel's Zone Editor, with separate Add, Edit and Delete actions.
An external DNS host or delegated child zone: publish at that authoritative service instead. Do not move nameservers simply to match a tutorial.

Do not change MX records, nameservers, DNSSEC or mail forwarding as a side effect of SPF, DKIM or DMARC work. Those changes can redirect inbound email or affect other services. If the required zone is missing or your account cannot edit it, ask the authorized administrator or Melbourne IT support to confirm the service and access rather than creating a competing zone.

Prepare the sender's record packet

For every actual sending route, obtain the provider's current instructions and complete public records for your account, product, region and domain. Record the type, full owner name, value or target, requested TTL, and any verification or activation step. DKIM may use a TXT public key or one or more CNAME aliases. Preserve the supplied type; do not convert one into the other.

Copy account-issued selectors and targets, not another customer's screenshot. Never place a DKIM private key in DNS. A public TXT key may be long: preserve the complete tagged value as one logical record. If the editor cannot accept it, confirm its supported long-TXT input format with support instead of truncating the key or creating separate competing records.

Before editing, save the existing values, TTLs and affected owners. Agree the exact proposed change and a rollback plan with the domain owner. Preserve existing verification tokens, legitimate SPF authorizations, DKIM selectors and DMARC protection. A mail provider's template does not authorize removing another provider.

Publish through the domain-only DNS tab

Follow Melbourne IT's current client-area DNS guide, rather than old instructions for a different console.

Sign in to the Melbourne IT portal and open DNS.
Select the domain whose authoritative zone you have confirmed.
To add a new record, use the + or Add New Record control. To change an existing record, locate that record and use its edit action rather than adding a duplicate.
Select the required Type and enter the Name and Content for that record.
Review the TTL and full resulting owner before committing. The official TXT screenshot shows Create for a new record. For an existing record, follow the edit dialog's confirmation and verify the saved row; the documented screenshot does not establish an exact save-button label for that dialog.

The official portal screenshot displays the selected zone as a suffix below Name and says to leave Name blank for the root. For example, in the example.com zone, blank identifies example.com, while _dmarc identifies _dmarc.example.com. Do not paste example.com again into a relative-name field that already appends it. The screenshot's demonstration TTL is not a recommendation for every deployment; use the approved TTL appropriate to your provider and change plan.

The screenshot also shows a plus control beside TXT Content. Do not use this to make a second SPF policy. Confirm the editor's handling of additional values or long TXT strings before using it for an issued record.

Publish through the cPanel Zone Editor

For supported hosting accounts, Melbourne IT's cPanel DNS instructions give this route:

From the hosting Overview page, select Manage, then Logins → cPanel Login.
In cPanel, open Domains → Zone Editor.
Select Manage beside the correct domain.
Use + Add Record for a genuinely new owner/type, or Edit for an existing record being changed.
Select Type, enter the valid zone name in Name, and supply the value in Record.
Review the complete owner and value, then select Save Record.

The cPanel source documents adding, editing and deleting records. Deletion is not the normal way to merge SPF or repair a typo. Preserve the other records and use the narrow authorized edit. Unlike the portal's illustrated relative-name form, the cPanel instructions describe a valid zone name: check the completed name displayed by your editor, rather than assuming that blank or @ has identical meaning in both interfaces.

Map parent, child and delegated names correctly

The authoritative zone determines the relative name, not the visible From address alone. These are illustrative owner mappings, not records to copy without your provider's packet:

In zone example.com, the full DKIM owner s1._domainkey.example.com has relative name s1._domainkey.
If mail.example.com is separately delegated, s1._domainkey.mail.example.com belongs in that child zone with relative name s1._domainkey, not in an inactive parent-zone copy.
If _domainkey.example.com itself is delegated, s1._domainkey.example.com belongs in that namespace with relative name s1. Preserve the existing delegation.
_dmarc.mail.example.com is relative _dmarc.mail in the parent zone, but _dmarc in a separately managed mail.example.com zone.

A provider-specified envelope sender can also be a subdomain. Publish its SPF authorization at the evaluated envelope domain, not automatically at the apex. Confirm the delegation and fully qualified output with an authoritative DNS query before assuming a green account status proves correctness.

Add SPF without breaking other senders

SPF evaluates the SMTP envelope sender domain, or the HELO identity in applicable cases. It does not directly authenticate the visible From address. Use a TXT record containing the authorized SPF policy; do not select an obsolete separate SPF record type based on older terminology.

There must be only one v=spf1 policy at an evaluated owner. If one exists, assess and merge the necessary authorization into that single policy while preserving legitimate sources and the approved final qualifier. Do not replace the policy with a marketing provider's single-sender example or append a second v=spf1 string.

Check the complete policy's DNS-dependent evaluation budget. The limit is ten evaluated terms that cause the relevant DNS processing, including nested include and redirect paths, not merely ten textual includes. An all mechanism also makes redirect ineffective. A longer or duplicated record can create permerror instead of authorizing the new source. See RFC 7208 for SPF evaluation rules.

A qualifier such as ~all or -all expresses an SPF result; it does not guarantee inbox delivery or rejection by every receiver. Do not change that qualifier without an approved reason.

Publish DKIM and finish setup at the sender

For TXT-based DKIM, use the complete issued public value at the supplied selector owner. For CNAME-based DKIM, use each issued alias target exactly. A CNAME owner must not also hold conflicting TXT, A, AAAA, MX or another CNAME data value. Investigate a collision before replacing anything, especially a selector shared with an older active sender.

Melbourne IT documents CNAME as a supported DNS record type, but the inspected portal image illustrates TXT. Select the actual required type and follow its displayed fields. If the CNAME form or existing-record control differs from the documented workflow, have support confirm the input format before saving; do not guess a TXT representation of a CNAME.

Where an intermediary DNS service offers HTTP proxying or CNAME flattening, make authentication aliases DNS-only and preserve literal CNAME answers if the sender requires them. Inspect applicable per-record, zone-wide, apex and same-zone behavior. Turn off a relevant per-record flattening control only where supported and appropriate; do not disable unrelated global features. If mandatory flattening prevents the issued answer, stop for a supported design. This is a conditional DNS check, not a claim that Melbourne IT exposes a particular proxy or flattening switch.

After DNS is correct, return to the email provider, run its domain verification and complete its documented signing activation. Publishing a key in Melbourne IT does not itself make Microsoft 365 or another sender sign mail. Obtain a supported activation procedure for that product; do not assume signing is automatic. The Microsoft 365 sender guide covers that separate sending-platform task.

Preserve DMARC policy and reporting permissions

Check both direct and applicable inherited DMARC policy before creating anything. Do not replace an existing enforced policy with p=none just because a generic setup guide recommends it. Preserve approved reporting destinations and alignment settings.

Only if there is no applicable policy, the domain owner approves monitoring and there is an agreed review plan, a first policy could be a single TXT at _dmarc.example.com containing:

v=DMARC1; p=none;

This conditional example requests monitoring without asking for enforcement. It is not a rollback instruction or a universal policy recommendation, and it does not enable DKIM. Do not add it alongside an existing DMARC record.

If aggregate reporting is wanted, obtain an approved destination and configure it intentionally. When that destination is in a different Organizational Domain from the policy domain, report-generating receivers check DNS authorization; a destination within the same Organizational Domain is excepted. This is not a rule about every different hostname. The DNS authorization check does not replace the owner's approval to share report data. See RFC 9990, section 4. Policy and alignment behavior are specified by RFC 9989.

Verify DNS and an actual message separately

Use read-only queries against the authoritative service and a normal recursive resolver. Identify the actual authoritative nameservers for the relevant zone through its NS delegation, including any separately delegated child or _domainkey namespace; confirm them with the DNS administrator if unclear. Query one of those authoritative servers directly, not an unrelated hosting server. Replace every angle-bracket placeholder below with the actual nameserver and full record owner before running the command:

dig @<authoritative-nameserver> TXT <actual-owner>

Use CNAME instead of TXT for an issued CNAME alias. Compare that authoritative result with ordinary recursive queries such as the following; replace the documentation domain and selector:

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT s1._domainkey.example.com
dig CNAME s1._domainkey.example.com

Query TXT or CNAME according to the provider-issued type; do not expect both at one owner. Check the full result, not merely that some text exists. Allow for the previous TTL and negative caching. If the authoritative answer is wrong, waiting for cache expiry will not repair it.

Then send a controlled message through the real intended sender to a valid test recipient. Inspect results produced inside that receiving service's known processing boundary, using its documented handling of externally supplied Authentication-Results. A familiar authserv-id string or a field near the top of the header is not proof of trust; ignore untrusted sender-inserted results.

Require the intended provider's DKIM signature to pass and align with the intended visible From domain, together with trusted dmarc=pass. A DMARC pass through SPF alone does not prove that the new DKIM route works. Under relaxed adkim, the signing domain and visible From share an Organizational Domain; strict adkim=s requires an exact domain match. SPF has its own aspf alignment setting: strict SPF requires the evaluated envelope domain to exactly match From, so a child Return-Path is not automatically strictly aligned.

Investigate SPF fail, temporary DNS failure (temperror) and invalid evaluation (permerror) separately even if DKIM allows DMARC to pass. Preserve the actual envelope domain, signing d= domain and selector in your diagnostic notes. No customer message or DNS change was tested while preparing this guide.

Common Melbourne IT questions

Why is my record absent after I saved it?

Check whether you edited the domain-only portal or a hosting zone that is not authoritative. Then inspect delegated subdomains, duplicated domain suffixes and the full owner. A successful save in an unused zone does not change public DNS.

Where do I get Melbourne IT DKIM values?

Get the public records and signing instructions from the actual email product, even if Melbourne IT sells that service. This DNS guide does not establish a universal key, selector or activation method for Melbourne IT's different mailbox products.

Should I replace existing SPF with the new provider's example?

No. Determine the actual evaluated owner, preserve existing legitimate senders, and maintain one valid policy within the evaluation limit. If you cannot safely reconcile the authorizations, pause and obtain a reviewed record rather than experimenting on live email.

What if a change causes problems?

Compare the saved before-and-after record and trusted message evidence. Use the pre-approved rollback through the correct editor, preserving unrelated records and existing DMARC protection. A rollback may take time to become visible through caches. Do not delete active selectors, change mail routing or downgrade enforcement as an improvised workaround.

Melbourne IT SPF, DKIM and DMARC setup, step by step