PowerMTA SPF, DKIM & DMARC configuration

Since late 2025, Gmail, Yahoo and Microsoft reject unauthenticated bulk mail outright — it doesn't even reach spam. So authentication isn't an optimization; it's the entry ticket. The work splits in two: DNS records you publish (SPF, DMARC, PTR) and DKIM signing you configure inside PowerMTA. Here's each part — and the one concept, alignment, that ties them together and trips up most setups. Need the records fast? Use our free SPF/DKIM/DMARC generator (it even creates the DKIM key in your browser).

Alignment is the whole point

Before the individual records, grasp the idea that connects them, because it’s where most “everything passes but DMARC fails” confusion comes from. DMARC doesn’t just ask “did SPF or DKIM pass?” — it asks whether the domain that passed aligns with the visible From: domain your recipient sees. SPF aligns if the envelope MAIL FROM (Return-Path) domain matches the From domain; DKIM aligns if the signature’s d= domain matches it.

DMARC passes if either SPF-with-alignment or DKIM-with-alignment passes — it doesn’t need both. But you want both working, because each fails in situations the other survives: SPF breaks when mail is forwarded (the forwarder’s IP isn’t in your record), while DKIM survives forwarding as long as the body isn’t altered. The practical upshot is that SPF, DKIM and DMARC aren’t three independent checkboxes — they’re a system whose whole job is to prove the From domain is really yours, and alignment is the test that proves it.

SPF

A TXT record on your sending domain authorizing the IPs PowerMTA sends from. Use include: for any third parties, list your own ranges, and close with -all (hard fail) once you're confident, or ~all (soft fail) while testing.

# DNS TXT @ example.com
"v=spf1 ip4:203.0.113.0/24 -all"

A few rules keep SPF healthy. Publish one SPF record per domain (two records is itself a failure), and remember it authorises the envelope MAIL FROM domain, not the visible From — so the Return-Path has to align with From for SPF to help DMARC. Authorise every sending IP explicitly, including each vMTA’s address and an ip6: entry if you send over IPv6. Watch the 10-lookup limit: SPF allows at most ten DNS lookups (from include, a, mx and friends), and exceeding it is a PermError that fails the whole record. And prefer ~all (softfail) over -all once DMARC is enforcing — let DMARC make the reject decision rather than SPF hard-failing forwarded mail. If you hit the lookup ceiling, see SPF PermError.

DKIM (the domain-key directive)

Generate a key pair for a selector, keep the private key on the server, and tell PowerMTA to sign with it. Then publish the public key in DNS.

# /etc/pmta/config — sign outbound mail
domain-key s1,example.com,/etc/pmta/dkim/example.private

# DNS TXT @ s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSq...QAB"

The domain-key line above is the minimal form; in a fuller <domain> scope you turn signing on and can run multiple keys for multiple domains:

<domain *>
    dkim-sign yes
</domain>

# multiple domains, each with its own key
domain-key s1,example.com,/etc/pmta/dkim/example.private
domain-key s1,client.com,/etc/pmta/dkim/client.private

Generate keys at 2048-bit (1024 is weak, and a 2048-bit public key may need splitting across multiple quoted strings in the TXT record). Because DKIM is what survives forwarding, it’s the mechanism that carries DMARC through the messy real world — prioritise getting it aligned over SPF. Rotate the keys on a schedule, covered in DKIM key rotation, and if a signature ever fails verification, DKIM body-hash failures walks the causes.

DMARC

A policy record telling receivers what to do when SPF/DKIM don't align, plus where to send reports. Start permissive and watch the reports:

# DNS TXT @ _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

The record carries more than a policy. adkim and aspf set alignment mode — r for relaxed (a subdomain match counts) or s for strict (exact match only); relaxed is the safe default. rua is where aggregate reports go (the single most important tag during rollout), and sp sets a separate policy for subdomains — omit it and subdomains inherit p, which isn’t always what you want. The rollout itself is the careful part, and the staged path plus how to read the reports is covered in DMARC p=reject blocking mail.

Reverse DNS and verification

Set a PTR for every sending IP that resolves to the hostname used in its virtual MTA HELO, and make that hostname forward-resolve back to the IP. Then send one authenticated test to a seed inbox and read the raw headers — you want spf=pass, dkim=pass and dmarc=pass before any real volume.

Why all three, and how they combine

Each protocol does one job, and they only add up to spoofing protection together. SPF says which IPs may send for your domain — useful, but it validates the envelope sender, not the From header a human reads, and it breaks on forwarding. DKIM cryptographically proves a message came from your domain unaltered, and it survives forwarding — but on its own it doesn’t tell a receiver what to do if it’s missing. DMARC closes the gap: it requires that a passing SPF or DKIM result aligns with the visible From domain, tells receivers how to treat failures, and reports back what’s happening.

That division is why “just SPF” or “just DKIM” isn’t enough for spoofing protection, and why DMARC needs at least one of them aligned to act. Run all three, keep both SPF and DKIM aligned so you’re covered whether or not a message is forwarded, and let DMARC tie them to your From domain and enforce. Skipped or half-configured, the set has holes; complete and aligned, it’s what lets a receiver trust that mail claiming to be from you actually is.

The third-party alignment trap

The most common way a careful setup still fails DMARC: sending through a third-party platform that signs and sends under its domains rather than yours. Your From address looks correct, SPF and DKIM technically pass for the platform’s domains — but neither aligns with your From domain, so DMARC fails and the mail goes to spam despite everything appearing green.

The fix is to make the third party sign as you. Every reputable platform supports custom DKIM, usually via CNAME records you publish so the signature’s d= is your domain, and an SPF include or a subdomain that keeps the Return-Path aligned. Once the platform’s mail is DKIM-aligned to your domain, DMARC passes. If you send only through your own PowerMTA or KumoMTA this rarely bites — you control the signing domain directly — but the moment a CRM, help-desk or marketing tool sends “as you,” check its alignment explicitly rather than assuming a green SPF/DKIM means DMARC is satisfied.

The 2026 requirements

Authentication moved from best practice to hard requirement. Since February 2024, Gmail and Yahoo require all senders to have SPF or DKIM, and bulk senders — more than 5,000 messages a day to their users — to have SPF, DKIM and a DMARC record, plus one-click unsubscribe on marketing mail and a spam-complaint rate kept low. Microsoft enforced the equivalent for Outlook, Hotmail and Live from May 2025.

The teeth are what changed. Non-compliant bulk mail is now rejected at the SMTP level — a hard bounce such as Microsoft’s 550 5.7.515 — not quietly filed in spam where you might notice it later. The 5,000-a-day threshold also catches more senders than expected once order confirmations, password resets and newsletters are added up. The practical reading: treat all three as mandatory for any real sending program, get them aligned, and don’t assume a low volume exempts you — the floor of “SPF or DKIM for everyone” applies regardless.

Per-domain and multi-tenant signing

PowerMTA supports per-domain authentication, which matters once you send for more than one domain. Multiple domain-key lines let each domain sign with its own key, and signing can be scoped per <domain> or per vMTA, so a multi-tenant setup keeps each tenant’s authentication independent. Each domain publishes its own SPF, its own DKIM public key, and its own DMARC record; PowerMTA just signs each message with the right key for its domain.

One operational rule matters across all of them: authentication consistency during warm-up. A new IP or domain that signs inconsistently — some mail aligned, some not — sends mixed signals exactly when receivers are forming their first impression. Get SPF, DKIM and DMARC right before you start warming, and keep them stable throughout, so the only variable a receiver sees as you ramp is volume, not a shifting authentication posture. Review authentication after any DNS, domain or infrastructure change, since those are where silent failures creep in.

The wider picture: MTA-STS, BIMI, FBL

SPF, DKIM and DMARC are the core, but a few related records build on them. MTA-STS secures the transport rather than the identity — it requires that mail to your domain arrive over valid TLS, closing the STARTTLS downgrade gap — and it complements authentication rather than replacing it. BIMI, which displays your brand logo in supporting clients, requires DMARC already enforcing at quarantine or reject (plus a Verified Mark Certificate for Gmail), so it’s a reward for getting DMARC right, not a separate track.

Feedback loops lean on authentication too — Yahoo’s complaint loop is keyed to your DKIM-signed domain, so DKIM is a prerequisite for receiving those complaints at all. The throughline: get SPF, DKIM and DMARC aligned first, and the rest of the modern sender stack — transport security, brand display, complaint feedback — builds naturally on top. Skip the foundation and none of the upper layers work.

KumoMTA signing

The DNS side — SPF, DMARC, PTR — is identical regardless of engine, since those are records you publish, not settings in the MTA. Only DKIM signing differs in where it’s configured. KumoMTA signs in Lua: you load the signing key and apply it in a message hook, naming the selector and signing domain, rather than writing a domain-key directive. The concepts — selector, signing domain, private key on the server, public key in DNS, alignment with From — are exactly the same.

So whichever engine you run, the work is the same shape: publish SPF and DMARC and PTR in DNS, sign DKIM in the engine with a key whose public half you’ve published, and make sure the signing domain aligns with your From. The Auto PMTA Configurator wires DKIM signing for either engine and publishes the matching records, so the alignment is correct from the first send.

Verifying and monitoring

Don’t trust a setup you haven’t verified. Send an authenticated test to a seed inbox and read the raw headers: you want spf=pass, dkim=pass and dmarc=pass, and you want the DKIM d= and the SPF domain to match your From — a pass that doesn’t align still fails DMARC. Confirm this on the protocol you actually send over, including IPv6 if you’re dual-stack, since a record can pass on one path and fail on another.

Then keep watching through your DMARC rua reports, which show real-world alignment across every source sending as your domain — the early-warning system that catches a new sender slipping out of alignment before it becomes a deliverability problem. Re-verify after any DNS, key or infrastructure change. Authentication isn’t a one-time setup; it’s a state you confirm and then monitor, because the cost of a silent failure is mail that simply stops arriving.

Common authentication mistakes

The recurring failures cluster in a few places. Passing but not aligning — usually the third-party trap — is the subtlest, since everything looks green while DMARC fails. Two SPF records or more than ten SPF lookups both break SPF outright. Jumping DMARC to reject before sources are aligned drops your own mail. And missing or mismatched reverse DNS undercuts trust no matter how clean the three records are.

The rest are maintenance lapses: a DKIM key never rotated, an SPF record that drifts out of date as IPs change, a new third-party tool added without aligned signing. Each is caught by the same habits — verify alignment on a real test, watch the DMARC reports, and re-check after any change. None is hard to avoid; all are easy to leave unnoticed until mail stops being delivered.

A complete authentication checklist

Pulling it together, here is the order to work through — each step builds on the last, and skipping ahead is how setups end up passing-but-not-aligned:

1. Publish one SPF record on the sending domain, authorising every IP (and ip6: if applicable), under ten lookups, ending in ~all.
2. Confirm the Return-Path aligns with your visible From domain so SPF can support DMARC.
3. Generate a 2048-bit DKIM key, sign in PowerMTA with domain-key/dkim-sign, and publish the public key at selector._domainkey.
4. Confirm the DKIM d= domain aligns with From.
5. Publish a DMARC record at p=none with an rua you monitor; set adkim/aspf and sp as needed.
6. Set reverse DNS (PTR) on every sending IP, forward-confirmed and matching the HELO host.
7. Verify spf=pass, dkim=pass, dmarc=pass — aligned — on a real test.
8. Tighten DMARC to quarantine then reject only once reports show all legitimate mail aligning.

Work it in that order and the three protocols come up as a coherent whole rather than a pile of records that individually pass but don’t together prove your From domain. The steps that people skip — the two alignment checks and the real-test verification — are exactly the ones that separate a setup that looks done from one that actually delivers.

The bottom line

Authentication is part DNS, part engine, and entirely about alignment. Publish one clean SPF record authorising your sending IPs (~all, under ten lookups), sign DKIM at 2048-bit with a key whose public half is in DNS, and publish a DMARC record — starting at p=none with an rua you read, tightening to quarantine then reject as reports show your mail aligning. Set reverse DNS on every sending IP, and verify spf=pass, dkim=pass, dmarc=pass — aligned — before you scale.

In 2026 this isn’t optional: unauthenticated bulk mail is rejected outright, so treat all three as the entry ticket, keep both SPF and DKIM aligned so forwarding can’t break you, and watch for the third-party alignment trap. KumoMTA does the same with Lua-based signing. If you’d rather not hand-publish records and wire signing, the installer generates SPF, DKIM and DMARC across your DNS, configures signing, and verifies all three pass, and the Auto PMTA Configurator keeps them aligned as you add domains and IPs. Get these three right, aligned, and verified, and you have the foundation every other deliverability lever depends on — reputation, warm-up, pools, transport security all assume authentication is already solid underneath them. Get them wrong and nothing above works, because in 2026 the receiver never even opens the message to find out. For legitimate, opt-in sending, this is the first thing to build and the last thing to let drift — the one part of the stack where a quiet, unnoticed change can take your sending from fully delivered to fully rejected without a single visible error on your side until someone notices the replies stopped coming and traces it back to a record that quietly fell out of alignment.