How to set up DMARC/DKIM/SPF for UltraCamp
Published 14 Aug 2026
Updated 22 Oct 2026
11 min read
Summarize with
Updated on 22 Oct 2026: We corrected UltraCamp sender verification and refreshed the DMARC enforcement steps for RFC 9989.
UltraCamp can send with your organization's address once you authorize its sending infrastructure in DNS, publish both DKIM CNAME records, set a DMARC record, and choose the authenticated address inside UltraCamp. UltraCamp documents the SPF include sender.ultracamp.com and the selectors ultracamp1 and ultracamp2.
SPF contributes to DMARC only when the authenticated Return-Path domain matches the visible From domain under the domain's DMARC comparison rules. UltraCamp's public DNS instructions do not specify a custom Return-Path setup, so confirm the actual domain in a received message. A passing DKIM signature with a matching signing domain gives you an independent DMARC pass path.
Records you will publish
- SPF. Add include:sender.ultracamp.com to the domain's single SPF record.
- DKIM. Publish the ultracamp1 and ultracamp2 CNAME selectors.
- DMARC. Start a new deployment at p=none with aggregate reporting enabled.
- UltraCamp. Select the authenticated sender address and verify it with a test message.
Check your UltraCamp sending route
These UltraCamp DNS records apply when UltraCamp sends through its own servers. An Email Sending Scheme instead routes messages through your SMTP server, whose SPF authorization and DKIM configuration must be checked separately. Adding the UltraCamp records does not configure that server.
Check Settings, System/Management, Email Sending Schemes before troubleshooting. If a scheme is active, verify its connection settings and use Send Test Message, then test the production workflow. Account sending limits and changed credentials can interrupt this route. UltraCamp's sending instructions explain both options.
Add your sender address in UltraCamp
UltraCamp's public DNS setup does not show a separate domain-verification wizard or a mandatory support activation step. Confirm custom sending by checking that DNS is published, the custom sender address is saved in UltraCamp, and a received test message uses that address and passes DMARC.
- Open settings. In UltraCamp Classic, go to Settings, expand System/Management, and select My Settings.
- Set the sender. Expand The Basics, open Basic Information, and enter an address on the domain you control in Primary Email.
- Save the account. Click Complete, then Exit Wizard. Update each administrative user's email under My Settings, Users if that user sends direct communications.
- Publish DNS. Complete the SPF, DKIM, and DMARC records below at the authoritative DNS provider. The UltraCamp DNS guide confirms the UltraCamp-specific values.
- Verify custom sending. Select the intended From address when composing a message, send a test, and contact UltraCamp support if the generic sender remains after DNS and account settings are correct.
UltraCamp Classic Primary Email field in My Settings
Do not stop after changing the From address
A visible From address is not proof of authorization. If UltraCamp still sends as notices@ultracamp.com, confirm the DNS records and selected sender, allow cached DNS answers to expire, and ask UltraCamp support to investigate if the issue persists.
Set up SPF
- Find the record. Query TXT records for the sender domain you are authorizing. For example.com, the Host field is usually @ in that DNS zone.
- Merge UltraCamp. Add include:sender.ultracamp.com before the final all mechanism in the existing SPF record.
- Keep one policy. Edit the existing TXT record. A second v=spf1 record causes SPF PermError.
- Count lookups. Keep evaluated DNS-lookup mechanisms and modifiers within the SPF limit of ten, including nested includes.
UltraCamp documents include:sender.ultracamp.com for custom-domain sending. Publish it on the domain you use with UltraCamp, then inspect a test message's Return-Path (the SMTP MAIL FROM or envelope sender) to see which domain SPF actually checks.
If no SPF record exists, publish the first example. If one already exists, merge the UltraCamp include into it as shown in the second example and preserve every legitimate sender already present. Replace mail.example.com with an existing sender's documented include; it is a placeholder, not a working authorization.
SPF record for UltraCamp onlydns
v=spf1 include:sender.ultracamp.com ~all
Merged SPF record exampledns
v=spf1 include:mail.example.com include:sender.ultracamp.com ~all
Run the checker against the domain whose SPF record you edited. It should return one SPF policy and resolve the UltraCamp include within the lookup limit. A live email test is still required to confirm the actual Return-Path domain and SPF result.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
An SPF pass contributes to DMARC only when the authenticated Return-Path domain matches the visible From domain. Relaxed comparison requires the same organizational domain, while aspf=s requires an exact domain match. If UltraCamp uses an UltraCamp-owned Return-Path, a passing DKIM signature with a matching signing domain must satisfy DMARC.
Set up DKIM
- Create selector one. Add a CNAME at ultracamp1._domainkey that points to ultracamp1._domainkey.ultracamp.com.
- Create selector two. Add a CNAME at ultracamp2._domainkey that points to ultracamp2._domainkey.ultracamp.com.
- Use DNS only. Disable HTTP proxying for both CNAME records. Check ownership and use before replacing any conflicting record at either selector.
- Publish both. UltraCamp rotates between two keys, so both selectors must resolve before testing custom sending.
UltraCamp DKIM CNAME recordsdns
ultracamp1._domainkey.example.com CNAME ultracamp1._domainkey.ultracamp.com ultracamp2._domainkey.example.com CNAME ultracamp2._domainkey.ultracamp.com
Most DNS consoles automatically append your zone name. Enter ultracamp1._domainkey and ultracamp2._domainkey in the Host field unless the console explicitly requests a fully qualified name. Enter each UltraCamp target exactly, with no quotes.
UltraCamp DNS guide showing both DKIM CNAME mappings
A CNAME cannot share its name
Delete an old TXT record at the same selector only after confirming it is unused. DNS does not permit a CNAME to coexist with other data at that exact hostname.
Verify both DKIM selectors and public keysbash
dig CNAME ultracamp1._domainkey.example.com +short dig CNAME ultracamp2._domainkey.example.com +short dig TXT ultracamp1._domainkey.example.com +short dig TXT ultracamp2._domainkey.example.com +short
Set up DMARC
- Choose reporting. Use a mailbox or reporting address that accepts aggregate XML reports. Replace dmarc@example.com before publishing.
- Create the host. Publish one TXT record at _dmarc on the domain shown in the visible From address. For campoffice@example.com, the full name is _dmarc.example.com.
- Start in monitoring. For a new deployment, use p=none until every legitimate sending source has a passing domain match.
- Preserve enforcement. If the domain already uses p=quarantine or p=reject and legitimate mail passes, keep that stronger policy.
UltraCamp recommends p=quarantine. For a brand-new DMARC deployment, start with p=none while you check all legitimate senders. Monitoring mode does not request blocking, although receivers still apply their own spam filters. An established quarantine or reject policy should not be weakened just to add UltraCamp.
Use the DMARC record generator if you need to change the reporting address or add optional tags. Keep the initial record small so troubleshooting stays clear.
Initial DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
|
|
|
|---|---|---|
SPF | Return-Path (SMTP MAIL FROM) | SPF passes and domains match |
DKIM | Signing domain | Signature passes and domains match |
Either authenticated path can satisfy DMARC when its domain matches From.
Check the exact domain after @ in the visible From address, including any subdomain. The checker should identify the applicable DMARC record, parse your intended policy, and confirm that the rua URI is valid. If the From domain is a subdomain, also review the organizational domain's policy and any inherited subdomain policy.
A syntactically valid record does not prove that UltraCamp passes. Finish the DNS check, then send a real registration confirmation or test communication and inspect its authentication results.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If the checker finds multiple DMARC TXT records at the same hostname, combine the required tags into one record and remove the duplicate. Receivers discard duplicate policies at that hostname rather than choosing one.
Aggregate reports generally arrive daily after participating receivers process your mail and include passes as well as failures. If reports are missing, check traffic volume, the rua mailbox, and the record hostname. For an external reporting destination, confirm the receiving service has authorized reports for your domain as required by RFC 9990.
Verify and troubleshoot
- Check DNS propagation. Confirm the authoritative nameservers return the new records, then allow cached or negative answers at recursive resolvers to expire before retesting.
- Send through UltraCamp. Generate a real confirmation, reminder, receipt, or direct communication using the new sender address.
- Inspect headers. Check the receiving server's Authentication-Results for spf=pass, dkim=pass, and dmarc=pass, then compare Return-Path, header From, and the DKIM d= domain. DMARC needs at least one passing domain match.
- Test replies. Reply to the message and confirm the response reaches a monitored camp mailbox. Check Reply-To when present, because it can differ from From and does not determine DMARC.
Use a message generated by the same UltraCamp workflow that will run in production. Test registration confirmations and direct communications separately if they use different sender addresses or sending routes.
The email tester below gives you a destination address. Send an UltraCamp message to it, then review the SPF, DKIM, DMARC, headers, and message-content diagnosis together.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A healthy UltraCamp test uses your selected From address instead of notices@ultracamp.com. At least one authenticated domain must match that From domain, though publishing and passing both SPF and DKIM gives you safer redundancy.
If the From address is correct but DKIM is absent, recheck both CNAME targets and ask UltraCamp support whether custom sending is active. If DKIM passes with an UltraCamp-owned d= domain, the signature does not contribute to DMARC for your From domain.
Healthy result
- SPF pass. The Return-Path domain authorizes the sending IP; SPF contributes to DMARC only if that domain matches From.
- DKIM pass. An UltraCamp selector validates and its d= domain matches From.
- DMARC pass. The receiver reports at least one passing matching path.
- Reply works. Replies reach the monitored camp mailbox.
Common failures
- SPF PermError. Multiple policies or too many DNS lookups exist.
- DKIM missing or failing. Check for a missing public key, an incorrect selector, or an invalid signature.
- DMARC fail. Neither SPF nor DKIM passed with a domain matching From.
- Wrong sender. UltraCamp still uses notices@ultracamp.com.
UltraCamp From field using a custom camp email address
Monitor UltraCamp authentication changes
- Monitor daily. Track UltraCamp volume, SPF results, DKIM results, domain matching, and new source IPs.
- Alert on change. Trigger notifications when UltraCamp's pass rate drops, a selector disappears, or a new unverified source uses the domain.
- Keep ownership clear. Route each issue to the person who controls DNS, UltraCamp settings, or sender approval.
- Watch reputation. Review blocklist (blacklist) status and delivery signals beside authentication failures.
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring turns aggregate XML reports into source-level results so you can review UltraCamp traffic, investigate authentication failures, and route issues to the person responsible.
Aggregate reports usually arrive daily, so report-based DMARC alerts depend on when receivers send their data. Use DNS monitoring alongside those alerts to detect a deleted DKIM selector or SPF record change.
A practical UltraCamp alert policy
- Source change. Investigate a new sending IP attributed to UltraCamp before approving it.
- Failure spike. Notify when DMARC failures rise above the source's normal baseline.
- DNS regression. Notify when either DKIM selector or the SPF include stops resolving.
- Policy drift. Notify when the published DMARC policy differs from the approved stage.
Confirm an UltraCamp source against a test message's sending IP and DKIM d= and s= values before classifying matching traffic in aggregate reports. Do not rely on rDNS alone; aggregate reports do not list the SPF include that authorized an IP.
Secure your domain with p=reject
- Inventory senders. Classify every source in aggregate reports as approved, obsolete, forwarded, or unauthorized.
- Fix legitimate mail. Require every approved source to pass SPF or DKIM with a domain that matches From. Aim for both when the platform supports both.
- Observe a full cycle. Include registration peaks, scheduled reminders, receipts, staff messages, and low-frequency seasonal sends.
- Stage enforcement. Move to p=quarantine, review another representative sending cycle, and resolve legitimate failures before continuing.
- Finish at reject. Use p=reject after assessing legitimate streams, including forwarding and mailing-list traffic, and understanding the remaining failures.
Suped's issue detection helps investigate verified senders such as UltraCamp and unknown traffic. Its hosted DMARC lets you manage policy changes after the initial DNS delegation. Review reports and approve each enforcement stage before applying the stronger policy.
Full quarantinedns
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Final reject policydns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Do not rely on percentage-based enforcement
RFC 9989 removed pct and marks it historic. Receivers implementing the current standard ignore that tag, so pct=25 does not provide a dependable partial rollout. Stage enforcement with policy changes and representative testing; use a separately tested sending subdomain if you need to limit the initial scope.
Keep the UltraCamp selectors and SPF include monitored after reject is active. A later DNS cleanup, provider change, or key rotation can turn a previously healthy source into rejected mail without any change inside the UltraCamp message workflow.
UltraCamp authentication FAQ
These checks cover the UltraCamp identifiers that commonly appear in DNS and received-message headers. Always confirm a source with the full header because one identifier alone can be reused or changed.
UltraCamp documents sender.ultracamp.com as its SPF include domain. An rDNS label alone does not authenticate a message. Check the receiving server's authentication results and compare the sending IP, DKIM signing domain and selector, Return-Path, and visible From address.
UltraCamp's DNS instructions specify include:sender.ultracamp.com for custom-domain sending. Add it to the existing SPF policy rather than creating a second v=spf1 record. Confirm your organization uses UltraCamp before authorizing its infrastructure.
Yes. Publish ultracamp1._domainkey and ultracamp2._domainkey. UltraCamp uses two selectors so it can rotate keys without requiring another DNS change. Both CNAME targets and their public keys should resolve before testing the sender.
Use p=none for a new deployment while you verify all legitimate sources. UltraCamp's current support note recommends quarantine, but moving straight to enforcement can affect an undiscovered sender. If the domain already uses quarantine or reject and valid mail passes, keep the stronger policy.
UltraCamp uses this generic sender when custom-domain DNS authentication is not configured. Check DNS propagation, SPF and both DKIM CNAMEs, and the selected From address. Confirm Primary Email and any user-specific sender address, then contact UltraCamp support if the generic sender persists.
Yes. DMARC passes when either SPF or DKIM passes with a domain that matches the visible From domain. A passing DKIM signature with a matching signing domain independently satisfies DMARC. Check the actual Return-Path in a received test message rather than assuming UltraCamp provides a matching custom Return-Path.
