How to set up DMARC/DKIM/SPF for Spectrum Networks
Published 30 Oct 2026
Updated 30 Oct 2026
13 min read
Summarize with
For email sent through Spectrum Networks, publish the SPF authorization supplied for your account, ask Spectrum to enable DKIM signing with your domain, and publish a DMARC TXT record at _dmarc on your domain. DMARC passes when SPF or DKIM passes with a domain that matches the visible From domain under your DMARC alignment settings.
I start with p=none for a domain without an enforcement policy, then verify messages sent through the actual Spectrum mail service. Keep p=quarantine or p=reject if either is already working. I could not verify a public Spectrum Networks SPF include, DKIM selector, or authentication setup screen, so the account-specific values must come from Spectrum support.
Add your domain
For a custom sending domain, have Spectrum confirm that the domain is provisioned on your email service and that your account is authorized to send with it. Access to Spectrum internet or DNS hosting alone does not establish which service sends your email.
- Confirm DNS access: Identify the authoritative DNS host for your domain and obtain permission to edit its records. If Spectrum manages the zone, request the DNS changes through its support team.
- Request provisioning: Send Spectrum your account identifier and the custom domain you want to send from. Ask it to confirm the outbound SMTP service, permitted From addresses, custom Return-Path setup, and availability of DKIM signing with your domain.
- Verify ownership: Complete the domain ownership check Spectrum specifies for your account. If it supplies a DNS verification record, publish the exact name, type, and value, then ask Spectrum to confirm verification.
- Confirm activation: Have Spectrum confirm that the domain is active for outgoing mail. Use its supplied SMTP settings to send a message with your custom domain in the From address.
The Spectrum Networks website lists support@spectrum.com.au and 1300 133 299. Use those contacts to request the records for your service; a domain used by another customer is not a configuration source for your account.
Keep existing MX records unless Spectrum is also changing your inbound mail service. SPF and DMARC TXT records do not require moving your incoming email.
Illustrative Spectrum Networks website view highlighting its public support contacts.
Request the complete outbound authorization details before editing SPF. For DKIM, request the signing domain, selector, DNS record type, and full public record value.
Set up SPF
SPF checks the domain in the SMTP MAIL FROM address, normally visible in the delivered message's Return-Path header. I check that domain first, because adding Spectrum to the visible From domain's SPF record only helps when that is the domain SPF actually checks.
For a custom Return-Path such as bounce.example.com and a From domain of example.com, relaxed SPF alignment accepts the shared organizational domain. An existing aspf=s setting requires an exact domain match.
- Capture the envelope domain: Send a message through Spectrum and inspect its Return-Path and the receiving server's smtp.mailfrom result. Confirm that Spectrum is using the custom envelope domain configured for your account.
- Obtain authorization: Ask Spectrum for its supported SPF include hostname or the complete outbound IPv4 and IPv6 ranges for your service. Do not guess an include using spectrum.com.au or authorize a server solely because it receives your incoming mail.
- Merge one record: At the envelope domain, edit the existing TXT record beginning v=spf1. Add Spectrum's confirmed authorization before the final all mechanism and preserve other legitimate senders. Publish only one SPF record at that name.
- Check lookup limits: Keep SPF evaluation within the limit of 10 DNS-querying mechanisms and modifiers, including nested includes. A record that exceeds this limit produces permerror.
- Check the result: Use the checker below on the actual envelope domain, then send another message. Require spf=pass and the expected smtp.mailfrom domain in the receiver's authentication results.
Inspect your DNS, replacing the example namesbash
dig +short NS example.com dig +short TXT example.com dig +short TXT bounce.example.com
Replace example.com and bounce.example.com with your actual domains. These commands inspect existing records; they do not supply Spectrum's outbound authorization.
The SPF checker validates the published policy and its lookup behavior. Query the custom Return-Path domain as well as the root domain when they differ.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After DNS caches expire, test the real sending route again. Avoid +all, which authorizes every IP address. Use an ending such as ~all during an intentional SPF rollout, then consider -all once the complete sender inventory is confirmed.
If Spectrum confirms that your particular service uses a Spectrum-owned Return-Path instead, adding Spectrum to your own SPF record is unnecessary for that stream. Expect SPF alignment failures in that case. DMARC still passes when DKIM passes and its signing domain meets your DMARC alignment requirements.
Set up DKIM
Spectrum must sign outgoing messages with a private key whose public key is available through your domain's DNS. Publishing a DKIM record alone does not enable signing. I verify both the DNS record and a newly delivered message.
- Confirm signing support: Ask Spectrum to enable DKIM for your custom domain on the outbound service your account uses. If that service does not support custom-domain signing, obtain an account-specific alternative before treating DKIM as configured.
- Get the exact records: Obtain the signing domain, selector, and TXT value or CNAME target from Spectrum. Do not assume that selectors such as default or s1 apply to its service.
- Publish the public record: Create the supplied record at the selector's _domainkey name in the correct DNS zone. Enter the name in the format your DNS host expects, avoiding a duplicated domain suffix. Publish only the public key or supplied CNAME target.
- Activate signing: After the record resolves, ask Spectrum to confirm DKIM signing is enabled for your domain. If it supplied a CNAME, verify that the target resolves to the intended public key.
- Verify a message: Send a fresh message and require dkim=pass. Check the DKIM signature's d= signing domain against the visible From domain, and record its s= selector for future troubleshooting.
In the commands below, s1 is an illustrative selector, not a Spectrum Networks default. Replace it with the s= value supplied by Spectrum or observed in a genuine message.
With relaxed DKIM alignment, the signing domain and From domain share an organizational domain. With adkim=s, they must match exactly. A valid signature using only Spectrum's own domain does not authenticate your custom From domain for DMARC.
Inspect the actual DKIM selectorbash
dig +short TXT s1._domainkey.example.com dig +short CNAME s1._domainkey.example.com
Keep old selectors published during a key rotation until messages signed with the old key have cleared delivery queues. Have Spectrum coordinate the signing change and confirm that new messages use the new selector.
Retest after an outbound service change even when the DNS record stays the same. The receiving server's result establishes whether the message was signed correctly on that route.
Record published
The selector resolves to a public key. This confirms DNS publication but does not establish which domain or key Spectrum uses to sign an outgoing message.
Message verified
The receiver reports dkim=pass using your signing domain and expected selector. Check that domain against your From domain to establish whether the signature satisfies DMARC.
Set up DMARC
Publish DMARC on the domain used in your visible From address. For a domain starting without enforcement, use p=none while you identify legitimate senders. If p=quarantine or p=reject is already deployed, keep that policy and repair Spectrum's authentication without weakening it.
Use the DMARC record generator to prepare the policy and reporting address. The example below uses a placeholder mailbox that you must replace.
- Inspect the current policy: Look up the TXT records at _dmarc.example.com, substituting your own domain. Update the existing DMARC record instead of creating a second policy record at the same name.
- Choose report delivery: Use a reporting mailbox you control or the exact address supplied by your reporting platform. For a report destination outside your domain, complete the reporting authorization required by that destination.
- Publish the record: Create a TXT record with host _dmarc in your domain's DNS zone. Use the value below for a new monitoring policy, replacing the example reporting address.
- Verify publication: After the previous DNS TTL has expired, check that the correct owner name returns one valid DMARC policy. Test your From domain with the checker below.
Example DMARC TXT value at _dmarc.example.comtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DNS name is _dmarc.example.com for a From domain of example.com. Many DNS editors append the zone name automatically, so entering only _dmarc is correct in those editors. Do not enter the full name twice.
Replace dmarc@example.com with your actual report destination before publishing. The DMARC checker validates the DNS policy; a sent-message test is still required to verify how Spectrum authenticates your email.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Check the returned policy and reporting destination after saving. If your DNS is managed by Spectrum, request confirmation of the exact published record and check the public result yourself.
A p=none policy requests monitoring without requesting quarantine or rejection for DMARC failures. Keep reports flowing while you verify Spectrum and every other legitimate sender using the domain.
Verify and troubleshoot
I test messages sent through the same Spectrum account and SMTP route used in production. A DNS lookup cannot prove that the outgoing server signs messages or uses the intended Return-Path.
The email tester below is the quickest configuration check. It prompts you to send a message to a generated test address and returns a diagnosis. Send the message directly through Spectrum rather than forwarding an existing email.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Read the receiving server's Authentication-Results header. Require dmarc=pass and check which passing method provides the matching domain. SPF and DKIM do not both have to pass for DMARC to pass.
Save the test result alongside the DNS changes. Repeat the test for each distinct sending route, including applications that submit mail differently from a user's mailbox.
|
|
|
|---|---|---|
SPF | Authorized IP | Confirm relay pool |
SPF domain | Matching domain | Check Return-Path |
DKIM | Valid signature | Check selector |
DKIM domain | Matching domain | Confirm signing domain |
DMARC | One matching pass | Compare identifiers |
Domain matching follows the relaxed or strict settings in your DMARC policy.
Resolve a failure at its source before changing DMARC enforcement. These are the checks I use to distinguish a DNS problem from an outbound service configuration problem.
- SPF permerror: Remove duplicate SPF records or reduce excessive DNS lookups. Preserve legitimate authorizations when consolidating records.
- SPF fail: Compare the receiver-observed source IP with Spectrum's complete authorized relay set. An inbound MX address is not proof of an outbound IP.
- DKIM none: Ask Spectrum to enable signing on the actual outbound route. A published public key does not cause a server to add a signature.
- DKIM fail: Check the selector, signing domain, and published key. A body hash mismatch requires investigation of message changes after signing, such as an added footer.
- DMARC fail: Compare smtp.mailfrom and the passing DKIM d= domain with the From domain. Raw SPF or DKIM success using an unrelated domain does not satisfy DMARC.
- Missing reports: Confirm rua and any external reporting authorization. Send to receivers that provide aggregate reports and allow roughly 24-48 hours for initial reports; reporting is not universal.
Get alerted when it breaks
Suped is our DMARC and email authentication platform. Its DMARC monitoring turns receiver reports into source-level authentication results and detected issues, so your team can investigate a Spectrum failure without manually reviewing aggregate XML files.
Use Suped's failure alerts and summary emails for ongoing oversight after the initial Spectrum message test. Keep Spectrum support responsible for changes to its signing service or outbound relay configuration.
- Verify the source: In Suped's source table, compare the Spectrum source with your test message, source IP, and account details before marking it verified. A familiar rDNS suffix alone is insufficient.
- Enable notifications: Open Suped's notification settings and enable DMARC failure alerts and summary emails for the team responsible for the domain.
- Investigate failures: Open the affected source and inspect individual records in the detail view. Compare SPF results, DKIM results, and the domains used by the message.
- Trace the change: Review Suped's DNS history for recent authentication record changes. Give Spectrum the affected IP, selector, and a fresh failing message when its service needs correction.
- Confirm recovery: Repeat the direct message test after the fix, then confirm that subsequent receiver reports show the expected DMARC results.
Suped combines issue detection with steps to fix the underlying configuration. This is useful when Spectrum changes a relay pool or a DKIM key rotation leaves an incorrect DNS value.
Report-based alerts depend on receivers submitting their reports. Use direct message tests after configuration changes to get immediate evidence about the tested route.
Understand alert timing
DMARC aggregate reports normally arrive on a daily reporting cycle. Suped processes incoming reports and alerts on detected failures; this is not an instant notification for every individual email.
Secure your domain with p=reject
For a domain starting at p=none, I move to enforcement after every legitimate sending route has a reliable DMARC pass. A high overall pass rate is insufficient if a low-volume billing system still fails. Keep an existing working quarantine or reject policy in place.
Suped's Hosted DMARC is our policy-management option for making staged changes through the dashboard after its DNS delegation is configured. Use the source results and issue diagnostics to decide when the domain is ready.
- Inventory all senders: Review Spectrum alongside every other legitimate source using your From domain. Verify ownership of each source rather than approving it solely because authentication passes.
- Require reliable authentication: Confirm Spectrum's custom-domain DKIM signing and its SPF setup for the actual Return-Path. Test important forwarded routes because forwarding often breaks SPF and makes valid DKIM especially valuable.
- Observe normal operations: Review enough report history to cover your sending cycle, including infrequent jobs. In Suped, resolve failures for verified sources before increasing enforcement.
- Stage enforcement: For a new rollout, change to p=quarantine, inspect subsequent reports and message tests, then change to p=reject after legitimate failures are resolved. Base each change on observed source readiness.
- Review subdomains: Check explicit DMARC records on sending subdomains and the parent policy's sp setting. A parent reject policy can affect subdomains without their own policy.
- Keep monitoring: Leave aggregate reporting enabled after rejection is requested. Use Suped alerts to investigate new failures and restore the previous proven policy if a change disrupts legitimate mail.
The value below is the final enforcement example for the same _dmarc name. Replace the example report address, and update the existing record rather than publishing another DMARC record.
Keep the current reporting destination when changing policy. With Hosted DMARC, make the policy change in Suped after its delegation is active, rather than adding a competing TXT record at the delegated name.
Final DMARC TXT value after legitimate senders passtext
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Check the effective policy after the change, then send another Spectrum message and confirm dmarc=pass. Continue reviewing reports for failures on legitimate sources.
A p=reject policy requests rejection of messages that fail DMARC; receivers make the final handling decision. Passing authentication does not guarantee inbox placement or prevent misuse of an already compromised authorized account.
Frequently asked questions
Use the include hostname or outbound IP ranges Spectrum confirms for your specific email service. A public, universal include was not verified. Do not assume that include:spectrum.com.au is valid, and do not copy another customer's SPF policy.
Automatic custom-domain signing was not verified in public instructions. Ask Spectrum to confirm support for your account and supply the signing domain, selector, and DNS record. A delivered message with dkim=pass and the required domain match is the verification that matters.
Yes. DMARC passes when a valid DKIM signature has a signing domain that meets the policy's domain-matching requirements, even if SPF fails or its domain does not match. If your Spectrum service uses a provider-owned Return-Path, check custom-domain DKIM before attempting to fix SPF alignment through your own DNS.
An rDNS hostname ending in .spectrum.com.au is a clue to Spectrum Networks infrastructure. The suffix alone does not identify the customer or prove that mail is authorized. Confirm the connecting IP's ownership, inspect the receiving server's headers, and ask Spectrum to verify the sending route before approving it.
Only the operator controlling spectrum.com.au DNS can change its SPF, DKIM DNS records, or DMARC policy. If you use a mailbox on Spectrum's domain, ask its support team about authentication. Use a custom domain you control to manage your own authentication policy.
Use source readiness rather than a fixed number of days. Verify every legitimate sender and cover a normal sending cycle, including infrequent applications. Initial aggregate reports commonly take 24-48 hours to appear, and those first reports alone are insufficient evidence for enforcement.
