How to set up DMARC/DKIM/SPF for Enudge
To authenticate Enudge, add include:spf.enudge.com.au to the one SPF record on your sending domain, publish the Enudge-supplied DKIM public key at enudge._domainkey, and publish one DMARC TXT record at _dmarc. I start DMARC at p=none, confirm that Enudge passes with SPF or DKIM aligned to the visible From domain, then move to p=reject after every legitimate sender has been identified.
Enudge supports custom return-path alignment, so configure SPF as well as DKIM. Its current public guidance uses include:spf.enudge.com.au, while Enterprise accounts can receive a dedicated IP value. Enudge's sender guidance also confirms that SPF, DKIM and DMARC need correct configuration for bulk sending.
Add your domain
Use the exact organizational domain that appears after the @ in your Enudge From address. Authentication records belong in that domain's DNS, not in the DNS for enudge.com.au.
- Choose the domain. Use example.com when campaigns send as news@example.com. Use a subdomain only when the visible From address also uses that subdomain.
- Open domain settings. Sign in to Enudge, open the account or domain settings area, and add the sending domain if it is not already listed.
- Confirm ownership. Complete any TXT verification Enudge displays. Copy the host and value exactly, but let the DNS provider append the domain when its form does that automatically.
- Request the certificate. Locate the DKIM certificate sent when the account was created. If it is missing, email support@enudge.com.au with the sending domain and request a new certificate.
Enudge domain settings with authentication status controls
Account differences
Enudge account screens differ by plan. If no domain verification controls appear, the supported path is to send the domain to Enudge support and use the returned DNS values. Do not invent a DKIM key or reuse one from another domain.Set up SPF
SPF authorizes Enudge's return-path domain and sending infrastructure. Because Enudge supports return-path alignment, I include it in the root domain's existing SPF record instead of publishing a second SPF record.
- Read the current record. Look for one TXT value beginning with v=spf1 at the root of the sending domain.
- Merge Enudge. Insert include:spf.enudge.com.au before the final all mechanism. Keep every other authorized sender in the same record.
- Use assigned IPs. For an Enterprise account, publish the IP mechanism supplied by Enudge instead of copying an address from an old example or another account.
- Publish one record. Save it as a TXT record at the root host, commonly entered as @. Remove any second v=spf1 TXT record after merging its valid mechanisms.
New SPF record for Enudge onlydns
v=spf1 include:spf.enudge.com.au -all
Merged SPF record exampledns
v=spf1 include:spf.protection.outlook.com include:spf.enudge.com.au -all
Publish the merged example as one continuous TXT value. If the DNS interface displays multiple quoted strings, confirm that it joins them into one record.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the SPF check against the visible From domain. A valid result needs one SPF record, valid syntax, and no more than ten DNS-triggering lookups across the evaluated path.
SPF passing alone does not guarantee DMARC alignment. In a test message, compare the return-path domain with the visible From domain. They must match exactly or share the same organizational domain when relaxed alignment applies.
Avoid duplicate SPF records
Two TXT records beginning with v=spf1 cause SPF PermError. Add Enudge to the existing record. Do not publish a second record beside it.
Set up DKIM
Enudge signs messages with a domain-specific DKIM key. The current selector is enudge, so the public key normally sits at enudge._domainkey.example.com. The exact key must come from Enudge.
- Get the certificate. Use the DKIM certificate supplied at signup, or request a replacement from support@enudge.com.au and state the sending domain.
- Create the TXT record. Set the host to enudge._domainkey and paste the entire public value from the certificate without wrapping it in manual line breaks.
- Check the host format. If the DNS provider automatically appends example.com, enter only enudge._domainkey. A duplicated domain suffix returns no key.
- Ask for verification. After DNS resolves publicly, tell Enudge support that the record is live so they can run their final signing test.
Enudge DKIM settings showing the enudge selector and TXT record
DKIM record shape onlydns
Host: enudge._domainkey Type: TXT Value: v=DKIM1; k=rsa; p=<public-key-from-Enudge>
That code block shows the record shape, not a usable key. Every domain gets its own public key value. A placeholder or a key copied from another domain will fail DKIM.
Publish only the public key
A DKIM TXT record contains the public key beginning with v=DKIM1. Never place a private key in DNS or send it outside the system that signs the message.
Set up DMARC
DMARC evaluates whether SPF or DKIM passes and aligns with the visible From domain. It also tells receiving systems where to send aggregate reports. Start with monitoring unless the domain already uses quarantine or reject.
- Check for DMARC. Look up _dmarc.example.com before changing DNS. Edit the existing TXT record when one exists.
- Choose the report inbox. Replace dmarc@example.com with a mailbox or reporting address that can receive aggregate XML reports.
- Publish the TXT record. Use host _dmarc and the exact monitoring value below. Keep only one DMARC record at that host.
- Preserve enforcement. If the existing policy is p=quarantine or p=reject, keep that policy. Do not downgrade it to p=none just to add Enudge.
Starting DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DMARC record generator creates the TXT value when you need a different report address or alignment mode. Keep p=none during discovery, but keep an existing quarantine or reject policy unchanged.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After publishing, use the DMARC checker to confirm that the record resolves at the correct host and parses without errors.
A valid DNS record does not prove that Enudge messages use the required matching domains. Send a real campaign test and inspect its Authentication-Results header before changing policy.
One aligned pass is enough
DMARC passes when aligned SPF or aligned DKIM passes. I still configure both for Enudge because DKIM survives forwarding better, while SPF gives a second valid path when the return-path is aligned.
Verify and troubleshoot
DNS syntax checks are necessary, but a received message gives the decisive result. I send an Enudge test to a mailbox I control, open the original headers, and confirm both authentication and domain alignment.
- Send a real test. Use Enudge's campaign test function with the same From address and sending configuration planned for production.
- Read the headers. Find Authentication-Results and note spf=, dkim=, dmarc=, smtp.mailfrom=, header.d=, and header.from=.
- Confirm DKIM alignment. Require dkim=pass and confirm that header.d shares the organizational domain used by header.from.
- Confirm SPF alignment. Require spf=pass and compare smtp.mailfrom with header.from. Enudge supports an aligned custom return-path, so fix a mismatch rather than accepting it as permanent.
- Verify DMARC. Require dmarc=pass. If it fails, use the failing aligned identifier to decide whether SPF, DKIM, or both need correction.
Enudge campaign test screen used to send an authentication test
|
|
|
|---|---|---|
SPF fail | Source not authorized | Fix record or IP |
SPF unaligned | Return-path differs | Set custom return-path |
DKIM fail | Key or signature fails | Check selector and key |
DMARC fail | No aligned pass | Repair one aligned path |
Map each received-header result to the next corrective action.
The email tester below gives the quickest full diagnosis. Send a fresh Enudge message to the generated test address, then review its SPF, DKIM, DMARC and header findings.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If DNS looks correct but the test still fails, wait for the previous TTL to expire and send a new message. Old messages retain their original signatures and results, so retesting the same copy proves nothing about the new DNS.
If SPF alignment remains wrong, confirm that Enudge has enabled the custom return-path for this exact sending domain. If DKIM passes and aligns, DMARC can still pass while that SPF work continues.
Do not chase every SPF error
Some sending sources cannot use a custom return-path. For those sources, SPF alignment errors are expected and acceptable when aligned DKIM passes reliably. Enudge supports return-path alignment, so this exception should not be the default Enudge setup.
Get alerted when it breaks
A passing test is a point-in-time result. DNS edits, key rotation, new sending sources and return-path changes can break alignment later. Suped is our best overall DMARC platform for turning aggregate reports into ongoing, actionable monitoring instead of leaving XML files in an inbox.
- Detect changes. Suped identifies new sources, falling authentication rates and configuration issues without waiting for a manual test.
- Receive alerts. Real-time alerts flag failure spikes so the team can investigate an Enudge change before it affects a full campaign.
- Follow fix steps. Automated issue detection turns source-level failures into specific steps for SPF, DKIM and DMARC correction.
- Monitor one place. The platform combines DMARC, SPF and DKIM monitoring with blocklist monitoring (blacklist monitoring) and deliverability signals.
For a single domain or a large client portfolio, DMARC monitoring should start while p=none is collecting data. Suped's free plan covers the core workflow, while its multi-tenant dashboard gives agencies and MSPs one view across client domains.
Route the DMARC rua address to the unique reporting destination provided for the domain. Keep notifications owned by a monitored team address so staff changes do not create a silent gap.
Alert on change, not only failure
A new source using the domain can pass SPF yet remain unauthorized. Treat unfamiliar sources and authentication-rate changes as review events before changing policy.
Secure your domain with p=reject
Move to p=reject only after DMARC data shows that Enudge and every other legitimate sender consistently pass through aligned SPF or DKIM. I use a staged rollout with a defined rollback record, named owners and enough reporting data to cover normal sending cycles.
- Inventory every source. Classify each source in DMARC reports as authorized, obsolete or unknown. Do not authorize a source solely because it sends high volume.
- Fix authorized mail. Require Enudge DKIM alignment and confirm the custom return-path. Fix every other business sender before enforcement.
- Stage quarantine. Use p=quarantine with a limited pct value when the domain has complex mail flows, then raise coverage while watching legitimate failures.
- Enforce rejection. Publish p=reject at full coverage after authorized traffic stays healthy through the review window.
- Keep monitoring. Continue source review and alerts after enforcement. A later DNS edit or vendor change can still interrupt valid mail.
Stay at p=none
- Unknown sources. Reports still contain legitimate traffic that nobody has classified.
- Unstable alignment. Enudge or another approved sender shows recurring DMARC failures.
- No rollback owner. Nobody can restore a safe record quickly if legitimate mail is affected.
Move to p=reject
- Sources classified. Normal traffic is mapped to an owner and approved sending purpose.
- Alignment stable. Authorized sources pass DMARC consistently across normal sending cycles.
- Alerts active. Owners will see a failure spike and can act before the next campaign.
DMARC enforcement gates
Use observed authentication data and operational readiness, not a calendar date, to advance policy.
Discover
p=none
Collect reports and map all legitimate sources.
Control
p=quarantine
Quarantine a measured share while fixing exceptions.
Enforce
p=reject
Reject unauthenticated use after authorized mail is stable.
Full enforcement recorddns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC gives most teams a practical policy-staging workflow without repeated manual DNS edits. It keeps monitoring, alerts, issue detection and policy changes in one operational process.
Keep the previous known-good record in the change ticket, record the DNS TTL, and schedule enforcement when the mail owner and DNS owner can both respond. Roll back only for confirmed legitimate impact, then fix the failed source before trying again.
