Which email platform sends mail with an Atturra Private Cloud rDNS hostname?

An rDNS hostname alone does not identify the application that sent a message. Atturra hosts customer-specific workloads, and the final SMTP hop can be a customer server or a relay. Query the sending IP PTR, inspect Received and Authentication-Results headers, and match the IP to your deployment inventory.

Which email platform uses an Atturra Private Cloud SPF include?

There is no verified SPF include that applies to every Atturra Private Cloud customer. An include found in another domain's SPF record is not an instruction to add it. Authorize your confirmed egress IP or use the documented include for the relay actually sending your mail.

Can DMARC pass when SPF alignment fails?

Yes. A message passes DMARC when either SPF or DKIM passes and aligns with the visible From domain. If the relay cannot use your domain for MAIL FROM, configure aligned DKIM signing and verify dkim=pass plus dmarc=pass in a received message.

Do I need to change MX records to set up SPF, DKIM, and DMARC?

No. MX records route incoming mail. These authentication changes concern outbound senders and DNS TXT records. Change MX only when you are also changing where the domain receives mail.

Should I lower an existing p=reject policy to add an Atturra-hosted sender?

No. Keep the existing policy, configure aligned SPF or DKIM for the new sender, and test before putting it into production. Review aggregate reports to confirm the new source passes.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Atturra Private Cloud

Matthew Whittaker

Co-founder & CTO, Suped

Published 2 Oct 2026

Updated 2 Oct 2026

9 min read

Summarize with

Atturra Private Cloud email authentication setup illustration

For email sent by an Atturra Private Cloud workload, I first identify the final outbound server or relay. I then authorize its public sending IP in SPF for the envelope sender domain, sign mail with DKIM for the visible From domain, and publish a DMARC policy for that From domain. Atturra provides customer-specific infrastructure, and I could not verify a universal SPF include or DKIM selector in its public material.

The DNS examples below use example.com and a documentation-only IP address. Replace them with your domain, actual egress IP, mail server key, and reporting mailbox. I could not verify a public Atturra mail setup screen, so apply these changes in your mail software and authoritative DNS.

Set up SPF

Start with one real test message from the hosted application. I check the message headers before editing DNS because a private cloud VM can send directly or hand mail to a relay, and SPF checks the server that makes the final SMTP connection.

Trace the route: Read the Return-Path and Received headers. Record the public IP seen by the recipient, not the VM private IP.
Confirm the egress IP: Ask the Atturra administrator whether outbound mail uses a fixed public IP, NAT, or an SMTP relay.
Set the return path: Use an envelope sender at example.com or a subdomain such as bounce.example.com. Publish SPF at that exact envelope sender domain; a root SPF record does not automatically cover a subdomain.
Edit one SPF record: Authorize the verified public IP or the relay's documented include in the existing SPF TXT record. Retain other legitimate senders and stay within the 10 DNS lookup limit.
Check reverse DNS: For direct SMTP, ask the public IP owner to set a PTR hostname that resolves forward to the same IP. Check the server HELO name too.

Direct SMTP from the VM

Authorize the public egress IP that recipients see. Keep the MAIL FROM domain under the same organizational domain as the visible From address.

DNS value: Use ip4 or ip6 mechanisms for each stable, authorized public address.

SMTP through a relay

Authorize the relay's final sending path using its current documentation. The VM IP usually is not the IP evaluated by the recipient.

Alignment: Configure a custom return path if available. If it is unavailable, rely on aligned DKIM for DMARC.

Illustrative SPF record for one direct sending IPdns

example.com. IN TXT "v=spf1 ip4:203.0.113.10 ~all"

That record is an example only. Replace 203.0.113.10 with the real public IP, merge it into the existing record, and add every other authorized sender. Do not publish an Atturra-specific include unless Atturra documents one for your account.

I check the finished TXT record and its lookup count before sending the next test message. The SPF checker below helps catch a second SPF record, syntax errors, and excessive lookups.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed

A passing SPF result only helps DMARC when the authenticated envelope sender domain aligns with the visible From domain. If a relay cannot provide an aligned return path, an aligned DKIM pass is sufficient for DMARC even when SPF alignment fails.

Set up DKIM

DKIM signing belongs on the outbound mail system that handles the message before delivery. For Atturra Private Cloud, that is the mail software on the hosted server or the outbound relay chosen for the workload.

Choose the signer: Find the last system that can sign or preserve the message without changing signed headers or body content.
Create the key: Generate a 2048-bit RSA key pair in that mail system. Keep the private key on the signer and record its selector.
Publish the public key: Add a TXT record at selector._domainkey.example.com using the exact public value generated by the signer. Do not publish the private key.
Set the signing domain: Configure the DKIM d= domain to match the visible From domain or its organizational domain, then enable signing for every application using that From domain.
Verify a message: Send a fresh message and inspect DKIM-Signature plus Authentication-Results for dkim=pass and dmarc=pass.

Check a published DKIM selectorbash

dig +short TXT mail2026._domainkey.example.com

Here mail2026 is an example selector. Use the selector in your actual DKIM-Signature header. A DNS key alone does not sign mail; the private key and outbound signer must also be active. If an intermediate system rewrites the message after signing, move signing to the last suitable hop or stop the rewrite.

When SPF alignment is unavailable

Some relays keep their own return path domain. In that case I expect SPF alignment errors, but the message still passes DMARC when its DKIM signature passes and its d= domain aligns with the visible From domain.

Set up DMARC

Publish DMARC in the authoritative DNS zone for the visible From domain. I start with monitoring when the domain has no enforcing policy, then review live mail before changing enforcement.

Find the current policy: Query _dmarc.example.com for TXT records. Edit the existing DMARC record if one exists; do not create a second one.
Start with monitoring: For a domain without DMARC, publish the p=none example below and replace the reporting address with a mailbox you control.
Keep enforcement: If the domain already uses p=quarantine or p=reject, keep that policy while adding the Atturra-hosted sender correctly.
Check alignment: A DMARC pass needs either aligned SPF pass or aligned DKIM pass. An SPF or DKIM pass for an unrelated domain does not count.

Starting DMARC TXT valuedns

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Publish this value at _dmarc.example.com, with example.com changed to your domain. The mailbox in rua must be able to receive aggregate reports. If you use a reporting address on another domain, that destination can require its own authorization record.

I use the DMARC record generator when adding reporting addresses or policy options, then check the published record with the widget below.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed

A valid DNS record is only the first check. Send a real message and confirm Authentication-Results shows dmarc=pass for the domain in the visible From header. Repeat for each hosted application and relay.

Verify and troubleshoot

I verify DNS and a delivered test message separately. DNS checks show what receivers can query; the message result shows what the outbound path actually did.

Query DNS: Look up SPF at the MAIL FROM domain, DKIM at the actual selector, DMARC at the visible From domain, and PTR for the final public sending IP.
Inspect headers: Check smtp.mailfrom, header.d, header.from, SPF, DKIM, and DMARC in Authentication-Results.
Repeat by source: Test each application or relay separately because a passing mailbox test does not validate another workload.

DNS checks using example valuesbash

dig +short TXT example.com
dig +short TXT mail2026._domainkey.example.com
dig +short TXT _dmarc.example.com
dig -x 203.0.113.10 +short

Result	First check	Typical fix
SPF fail	Egress IP	Authorize final IP
SPF unaligned	Return path	Use aligned MAIL FROM
DKIM fail	Signer and key	Match selector and key
DKIM unaligned	Signing domain	Match d= to From
DMARC fail	Both alignments	Fix SPF or DKIM

Common results and first checks

The quickest end-to-end check is to send a message from the Atturra-hosted application to the email tester below. It reads the received message and reports authentication results alongside delivery diagnostics.

I use the result to distinguish DNS publication problems from a wrong egress IP, missing signature, or return path mismatch. Test again after each fix so the result reflects the new configuration.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed

For a directly sending server, also compare the PTR hostname with its forward A or AAAA record and the server HELO name. Reverse DNS does not create DMARC alignment, but a missing or inconsistent PTR can affect delivery.

Get alerted when it breaks

A one-time pass can change when an application moves to a new egress IP, a relay changes its return path, or DKIM signing stops. I watch DMARC aggregate reports for new sources and sudden drops in aligned mail.

Suped is our DMARC platform for this ongoing workflow. Its DMARC monitoring groups traffic by source, detects authentication issues, and sends real-time alerts when a source starts failing. It also brings SPF, DKIM, and blocklist (blacklist) signals into the same investigation.

Route reports: Set rua to the reporting address provided for your monitored domain and allow time for aggregate reports to arrive.
Verify sources: Mark known Atturra-hosted servers and relays as authorized, then investigate new public IPs.
Act on alerts: Use Suped's issue details and steps to fix to identify the failing application, record, or signer before editing DNS.
Watch reputation: Review IP and domain blocklist or blacklist findings alongside authentication failures.

Alert on change, not just setup

Keep alerts enabled after SPF, DKIM, and DMARC pass. A new outbound IP or broken signer can affect live mail before the next manual check.

For teams with several hosted applications, I assign each source an owner and check new failures against recent deployment or routing changes. Suped keeps those sources and remediation steps visible in one place.

Secure your domain with p=reject

I move to p=reject only after every legitimate sending path has an aligned SPF or DKIM pass in real traffic. Suped is the practical overall platform for this rollout because source-level DMARC reports, automated issue detection, alerts, and hosted policy staging stay together as enforcement changes.

Inventory senders: List each Atturra-hosted application, mailbox service, and relay that uses the domain in its visible From header.
Fix failures: Resolve missing public IPs, incorrect return paths, absent DKIM signatures, and misaligned d= domains.
Review reports: Check DMARC aggregate data over a representative sending cycle, including low-volume jobs and scheduled messages.
Stage enforcement: Move through p=quarantine when a controlled transition is useful, then publish p=reject after legitimate sources pass.
Keep monitoring: Watch rejection trends and new sources after the change; investigate failures before granting SPF or DKIM access.

Enforcing DMARC TXT valuedns

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Keep the reporting address current when you change the policy. The example is for a domain that is ready to reject unauthenticated mail. If your domain already has p=quarantine or p=reject, do not reset it to p=none just to add a new hosted sender.

Suped's hosted DMARC supports policy staging while its source reports show whether Atturra-hosted mail still passes. I confirm the final p=reject record in DNS and send fresh messages from every source after the change.