Does Cloudblast have a universal SPF include?

No published universal include applies to customer VPS mail. Authorize the exact public IP used by your Cloudblast server, merge it into the domain's single SPF record, and retest after any IP change.

Where do I get the Cloudblast DKIM record?

Generate DKIM in the mail server, signing daemon, or hosting control panel installed on the Cloudblast VPS. Publish the public key it gives you. Cloudblast does not supply one shared DKIM key for every VPS.

Which platform sends email with Cloudblast rDNS?

Cloudblast hosts the IP, but the customer controls its reverse DNS and the software that sends mail. There is no single fixed Cloudblast rDNS suffix that proves a message came from a managed email platform. Inspect the connecting IP, PTR hostname, forward DNS, and authenticated domains together.

Can DMARC pass when Cloudblast SPF fails?

Yes. DMARC passes when DKIM passes and the DKIM d= domain matches the visible From domain, even if SPF fails or its envelope domain does not match. On a self-managed Cloudblast server, configure both methods so one can cover a temporary failure in the other.

Should I publish p=reject immediately?

Start a new deployment with p=none, review aggregate data, fix every legitimate source, stage enforcement if needed, and then publish p=reject with full coverage. If the domain already uses quarantine or reject, keep the existing policy while fixing the Cloudblast sender.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Cloudblast

Matthew Whittaker

Co-founder & CTO, Suped

Published 12 Jul 2026

Updated 12 Jul 2026

10 min read

Summarize with

How to set up DMARC, DKIM, and SPF for Cloudblast

Cloudblast provides VPS infrastructure, so I configure email authentication in the mail server or control panel running on the Cloudblast instance. Cloudblast supplies the IP address and configurable reverse DNS. The mail stack supplies the envelope sender, DKIM key, hostname, and SMTP service. SPF authorizes the server IP, DKIM signs each message, and DMARC checks whether at least one passing method matches the visible From domain.

Confirm the sending architecture

Do not copy a generic Cloudblast include into SPF. There is no published universal Cloudblast SPF include or DKIM selector for customer VPS mail. Use the assigned server IP and the DKIM public key generated by your installed mail stack.

Cloudblast layer: VPS, public IP, firewall, and reverse DNS.
Mail layer: SMTP hostname, return path, DKIM signing, and message submission.

Add your domain

I first add example.com to the mail software installed on the Cloudblast VPS, then set mail.example.com as the SMTP hostname. Cloudblast itself does not publish a managed sending-domain verification flow, so the exact menu depends on the installed stack. The DNS plan stays the same across Postfix, a hosting control panel, or another SMTP application.

Create the sending domain: Add example.com in the installed mail stack and select it for the visible From address.
Choose the mail hostname: Use mail.example.com for SMTP greeting, forward DNS, and reverse DNS.
Set forward DNS: Publish an A record that points mail.example.com to the assigned Cloudblast IPv4 address. Add AAAA only if the server sends over IPv6.
Set reverse DNS: Change the IP's PTR value in Cloudblast to mail.example.com and confirm that forward and reverse lookups match.

Forward and reverse DNS planDNS

mail.example.com.  300  IN  A  203.0.113.25
203.0.113.25 PTR mail.example.com

Cloudblast server IP and reverse DNS settings

Domain verification depends on the mail stack

If the installed application gives you a TXT verification token, publish that token exactly and wait until the application marks the domain verified. That token proves control of the domain but does not replace SPF, DKIM, or DMARC.

Set up SPF

I authorize each Cloudblast IP that sends mail for the envelope-from domain. Return-path alignment is supported because the mail server is under your control. Set the return path to a subdomain such as bounce.example.com, or use example.com, and make sure it shares the organizational domain used in the visible From address.

Inventory all senders: List every IPv4 and IPv6 address that sends with this return-path domain.
Edit the existing record: Merge the Cloudblast IP into the current SPF record. Never publish a second SPF record at the same hostname.
Set the envelope sender: Configure the mail stack to use bounce.example.com so relaxed SPF alignment passes for From addresses at example.com.
Limit the scope: End with -all only after every legitimate sender has been added. Use ~all during a controlled migration if the inventory is incomplete.

SPF record for one Cloudblast IPv4 addressDNS

example.com.  300  IN  TXT  "v=spf1 ip4:203.0.113.25 -all"

Replace the documentation IP with the address assigned to your VPS. If the domain already authorizes another sender, keep its mechanism in the same record. SPF permits one TXT policy per hostname and has a ten-DNS-lookup limit for mechanisms that trigger lookups. Direct ip4 and ip6 mechanisms do not consume that lookup budget.

SPF checker

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

?/16tests passed

Run the check against the exact envelope-from domain, not only the visible From domain. A syntactically valid record still fails operationally when the message leaves through an unlisted IP.

Some external sending systems do not let you customize the return path. In that case SPF alignment errors are expected and acceptable when DKIM passes and its signing domain matches the visible From domain. That exception does not apply to a self-managed Cloudblast server because you control the envelope sender.

Set up DKIM

I generate the DKIM key inside the installed mail stack, publish its public half in DNS, and keep the private key on the server. Cloudblast does not publish a shared selector or public key. Use a short selector such as cb1 and prefer a 2048-bit RSA key when the DNS provider accepts the resulting TXT value.

Generate the key: Create a 2048-bit key pair for example.com in the MTA, signing daemon, or hosting panel.
Publish the public key: Add the TXT value at cb1._domainkey.example.com without quotes copied from a shell or line breaks inserted into the key.
Enable signing: Sign every outbound message with d=example.com and s=cb1.
Protect the private key: Restrict file access to the signing service and rotate the selector if the key is exposed.

DKIM public key record structureDNS

cb1._domainkey.example.com. 300 IN TXT (
  "v=DKIM1; k=rsa;"
  "p=PASTE_PUBLIC_KEY_WITHOUT_SPACES"
)

Passing DKIM

Selector lookup: The s= value points to a published TXT record.
Signature check: The body and signed headers verify without modification.

Passing DMARC with DKIM

Signing identity: The d= domain is example.com or its subdomain.
Visible identity: The From header uses example.com.

A published key is not enough

A DNS lookup can confirm that the public key exists, but only a received test message proves that the server signs mail with the matching private key and an appropriate d= domain.

Set up DMARC

I start a new deployment at p=none so authentication data arrives without asking receivers to quarantine or reject failing mail. If the domain already uses p=quarantine or p=reject, keep that policy and fix Cloudblast authentication without lowering protection.

Create the mailbox: Make dmarc@example.com able to receive aggregate XML reports, or use a reporting address that already exists.
Generate the policy: Use the DMARC record generator if you need a valid record with additional tags.
Publish one record: Add the TXT policy at _dmarc.example.com and remove any duplicate DMARC TXT record.
Keep relaxed matching: The defaults accept a matching organizational domain, which suits bounce.example.com and example.com.

Recommended monitoring policyDNS

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

Publish the value exactly once. DMARC passes when aligned SPF passes, aligned DKIM passes, or both pass. It fails only when neither passing method matches the visible From domain.

DMARC checker

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

?/7tests passed

Check the organizational domain used in the From header. A lookup against mail.example.com will not find a policy published at _dmarc.example.com unless the checker performs DMARC policy discovery.

Aggregate reports normally take a day or more to arrive. They identify receiver-observed source IPs and authentication results, which makes them useful for finding a missed Cloudblast IP or an unexpected sender before policy enforcement.

Verify and troubleshoot

I verify DNS first, then send a real message through the same application path used in production. Testing a record in isolation misses private-key errors, an incorrect envelope sender, SMTP rewriting, and outbound traffic leaving through a different IP.

Check DNS: Resolve the SPF TXT, DKIM selector TXT, DMARC TXT, A, and PTR records from a public resolver.
Send through production: Trigger the same application, SMTP credentials, port, and From address used by normal mail.
Read authentication results: Confirm spf=pass, dkim=pass, and dmarc=pass in the received headers.
Match identities: Compare header.from with smtp.mailfrom for SPF and header.d for DKIM.

Result	Likely cause	Action
SPF fail	Wrong IP	Add egress IP
DKIM none	Signing off	Enable signer
DKIM fail	Key mismatch	Republish key
DMARC fail	No match	Fix identity

Common Cloudblast mail authentication failures

The fastest end-to-end check is a live email test. It inspects the received message instead of assuming that a published record means the sender uses it.

Send the test through the application on the Cloudblast VPS. Do not send it from a desktop mailbox because that tests a different route and usually a different signing system.

Email tester

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

?/43tests passed

A clean result should show the Cloudblast IP as the connecting source, mail.example.com as the PTR and SMTP hostname, a passing SPF identity under your domain, and a passing DKIM signature under your domain.

If SPF passes but DMARC fails, inspect the return path. If DKIM passes but DMARC fails, inspect the d= value. A DMARC pass needs domain matching, not only a green authentication result.

Do not ignore rDNS and SMTP identity

PTR is not part of DMARC, but receiving systems use it during connection checks. The Cloudblast IP should resolve to mail.example.com, that hostname should resolve back to the same IP, and the server should present it in EHLO.

Get alerted when it breaks

DNS records and mail-server settings change after the initial launch. An IP replacement, expired process, selector rotation, overwritten TXT record, or new application path can break authentication without an obvious SMTP error.

Monitor DMARC results: Track Cloudblast source IP volume, SPF results, DKIM results, and domain matching over time.
Alert on regressions: Notify an owner when failure rates rise or a new unverified source starts using the domain.
Watch DNS health: Detect missing records, multiple SPF policies, lookup-limit problems, and DMARC policy changes.
Keep ownership clear: Route each alert to the team that controls the Cloudblast instance, mail stack, or DNS zone.

Suped is our best overall DMARC platform for this workflow. Its DMARC monitoring groups aggregate data by source, detects authentication issues, sends real-time alerts, and gives exact steps to fix them. The same workspace also tracks SPF, DKIM, blocklist status, and deliverability signals.

Notification settings page with DMARC alerts, weekly summary, toggles, and preview buttons

For a Cloudblast server, set alerts around the known sending IP and watch for any source that appears outside that inventory. Weekly summaries help confirm stable volume, while threshold alerts catch a sudden signer failure before enforcement blocks mail.

Useful alert conditions

Authentication drop: DMARC pass rate falls below the normal baseline.
Unexpected source: A new IP sends mail using example.com.
Record change: SPF, DKIM, or DMARC no longer resolves as expected.
Reputation event: The sending IP or domain appears on a blocklist (blacklist).

Secure your domain with p=reject

I move to p=reject only after every legitimate source is identified and consistently passes DMARC. A passing Cloudblast test message is necessary, but it does not prove that billing systems, support tools, and older application servers also pass.

Collect a representative window: Review enough DMARC data to include routine traffic and scheduled campaigns.
Classify every source: Mark each IP as authorized, obsolete, forwarded, or unauthorized.
Fix legitimate failures: Correct SPF identity, DKIM signing domain, selectors, and outbound IP coverage.
Stage enforcement: Use quarantine with a limited pct value if the organization needs a controlled transition, then raise coverage after clean reviews.
Publish reject: Set p=reject and pct=100 when legitimate traffic passes and owners have approved enforcement.
Continue monitoring: Keep alerts active after enforcement because infrastructure and sending sources still change.

DMARC enforcement gates

Use authentication evidence and source ownership to decide whether to advance the policy.

Monitor

p=none

Inventory incomplete or legitimate failures remain.

Stage

p=quarantine

Known mail passes, but rollout validation continues.

Enforce

p=reject

Authorized sources pass and unknown use should be blocked.

Full enforcement policyDNS

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

Suped is the practical control point for this progression. Automated issue detection separates verified and unverified sources, policy staging reduces accidental disruption, and alerts expose regressions after p=reject. Hosted DMARC also lets teams adjust policy without repeated direct edits to the long-lived DNS record.

Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options

Use Hosted DMARC when policy changes require review and controlled rollout. Keep the reporting address active and retain the Cloudblast IP, return path, DKIM selector, and service owner in the sender inventory.