Automate SPF, DKIM, and DMARC with HostStack DNS

Every team that ships transactional email has the same friction at the start. You generate SPF, DKIM, and DMARC records in your email provider's dashboard, paste them into your DNS provider, hit "verify," and wait. Sometimes it works. Sometimes you typo a semicolon in the DKIM key, the DNS provider quotes the TXT differently than the email provider expects, and you spend an afternoon debugging. The cycle repeats for every new sending subdomain you add.

This post is about how to skip that loop entirely when your DNS is on HostStack and your email goes through PostStack — the integration publishes every required record into your zone the moment you add a sending domain, and verifies it on the same request.

What needs to exist in DNS, exactly

Before automating anything, it helps to be honest about what the records actually are. There are four that matter for outbound sending and one optional fifth:

1. SPF — a TXT at the apex (or sending subdomain) that lists the IPs and includes authorised to send as you. One record per domain. More than one and resolvers fail open in different ways depending on vendor.
2. DKIM — a TXT at <selector>._domainkey.<domain> holding the public key your provider signs with. PostStack uses a per-domain rotated selector, so the selector name is part of the integration's job, not a thing you guess.
3. DMARC — a TXT at _dmarc.<domain>with the policy and the address that should receive aggregate reports. PostStack ingests its own reports automatically; the integration writes the ingest mailbox into the record.
4. Return-Path / MAIL FROM — a CNAME (or MX/TXT pair, depending on provider) on a subdomain like bounce.<domain> that delegates bounce handling to PostStack's MTA. Without it, your bounces go to the wrong place and aligned DMARC fails on the SPF axis.
5. MTA-STS + TLS-RPT (optional but recommended) — policy records that enforce TLS on inbound and ask receivers to report TLS failures. Both are TXT records plus, for MTA-STS, a small HTTPS policy file.

That's four to five records per domain, every domain. Multiply by the number of subdomains a real product uses — mail., notify., billing., support. — and the copy-paste workflow stops scaling somewhere around the third domain.

Why most providers don't automate this

They can't. Resend, Postmark, SendGrid, and Mailgun don't run a DNS service, so they can't push records into your zone — they can only show you the records they need you to add. SES has a half-automation if your domain is on Route 53, but only because Amazon owns both products. Everyone else gives you a "copy this record" screen and assumes you'll figure it out.

This is fine if you have one domain. It is not fine if you operate a multi-tenant product where every customer adds their own sending domain, or if you're a team that adds a new subdomain every time you launch a workflow product line. Each new domain becomes a ticket someone has to work.

How the integration works

The contract is intentionally boring. You generate a HostStack API key, paste it into PostStack's dashboard once, and then every POST /domains request against PostStack's API does the following automatically:

1. Calls HostStack's API to confirm the zone exists in your account and that the API key has write access to it.
2. Computes the SPF, DKIM, DMARC, and return-path records PostStack needs for that specific domain (DKIM key is generated server-side, stored encrypted, and never leaves PostStack's MTA).
3. Calls HostStack's API to upsert each record. Existing SPF entries are merged, not overwritten — if you already have include: lines for other vendors, they stay.
4. Triggers a DNS-side verification poll on PostStack's MTA, which queries your authoritative nameservers (not its own cache) until propagation completes. Typical end-to-end time: 8-30 seconds, because HostStack uses NOTIFY-driven propagation, not zone-file polling.
5. Marks the domain as verified and starts accepting sends. If you have the webhook configured, your application gets a domain.verified event and can flip the domain into production in your own UI.

The whole sequence is one API call from your side. No screen with records to copy-paste, no manual verify button, no five-minute wait while DNS caches expire.

What you still have to decide

The integration handles records. It does not make policy decisions for you, because those are domain decisions you should own:

• DMARC enforcement level. The integration writes p=none by default — observe-only, no rejection. Moving to p=quarantine or p=reject is a deliberate step you take once you've watched aggregate reports for a few weeks and confirmed nothing legitimate is failing. PostStack's deliverability dashboard surfaces those reports parsed and charted.
• SPF strictness. We default to ~all (soft-fail) because -all is unrecoverable for any send that slips through a forwarder. Flip to -all only once you're sure no legitimate sends originate outside PostStack.
• Subdomain strategy. Whether to send from mail.acme.com or directly from acme.com is a reputation question, not a DNS one. The integration is fine either way — it just publishes wherever you ask.

If your DNS isn't on HostStack

The manual workflow still works. PostStack's domain detail page shows every record with copy-to-clipboard and a verify button that polls in 10s intervals. The DNS provider hint detection (Cloudflare, Hetzner DNS, Vercel DNS, GoDaddy, Namecheap, and twenty more) deep-links you into the right add-record screen so the friction is a click rather than a search.

But if you're already evaluating DNS providers, or running infrastructure where every other piece of the stack is automated and DNS is the manual exception, the HostStack integration is the only end-to-end automated path I know of for the EU market. Cloudflare's API can do the same for non-EU stacks, but with the parent- company exposure to US legal process that's covered in the GDPR buyer's guide.

Disconnecting and rolling back

This is a question I get often enough to answer up front. Disconnecting the integration does not delete your DNS records. The records stay in your zone exactly as they were when last synced — you keep sending, you just stop getting automatic updates if PostStack rotates a DKIM key or adds a new bounce subdomain. To remove the records, you delete them from HostStack directly or from PostStack's domain page (which calls HostStack's API one last time before disconnecting).

No vendor lock-in beyond "your records live in your DNS provider, where they belong." That is the whole point.