Contents
Why alignment is the hard part
Authentication, SPF, DKIM, and DMARC, is a hard requirement for bulk senders in 2026, and the major receivers reject mail that does not meet it. Most operators get SPF and DKIM individually set up. The part that trips operators up, repeatedly, is DMARC alignment: the requirement that an authentication mechanism not just pass but pass in a way that ties to the From domain. A message can have a valid SPF result and a valid DKIM signature and still fail DMARC, and an operator who does not understand alignment will be baffled by it.
This guide exists to make alignment clear, alongside the SPF and reverse-DNS configuration that surround it. The structure of this guide: why alignment is the hard part, how DMARC builds on SPF and DKIM, what alignment actually means, the difference between SPF alignment and DKIM alignment and why DKIM alignment is the recommended path, the relaxed and strict alignment modes, configuring SPF to authorize the PowerMTA sending IPs, the PTR reverse DNS requirement, the DMARC policy levels and aggregate reports, and the diagnostic workflow when DMARC fails.
How DMARC builds on SPF and DKIM
DMARC does not replace SPF and DKIM; it builds on them. Understanding the layering is the foundation.
| Mechanism | What it authenticates |
|---|---|
| SPF | The envelope sender (Return-Path) against the sending IP |
| DKIM | The message, via a signature, tied to the signing (d=) domain |
| DMARC | Requires SPF or DKIM to pass AND align with the From domain |
SPF checks whether the sending IP is authorized, by the SPF DNS record, to send mail for the envelope sender's domain, the Return-Path domain.
DKIM checks whether the message carries a valid cryptographic signature, and the signature is tied to a signing domain, the d= value.
DMARC sits on top. It requires that SPF or DKIM passes, but with the additional condition of alignment, and it gives the domain owner a policy, published in DNS, telling receivers what to do with mail that fails DMARC.
The key insight is that SPF authenticates the Return-Path and DKIM authenticates the d= domain, and neither of those is necessarily the From header domain that the recipient sees. DMARC's job is to close that gap, and it does so through alignment.
What alignment means
Alignment means that an authentication mechanism passes in a way that ties to the domain in the message's From header.
The From header domain is the identity the recipient sees, and it is the identity DMARC is designed to protect. But SPF passes on the Return-Path domain, and DKIM passes on the d= domain, and those can be different from the From domain. Alignment is the requirement that closes this:
- SPF alignment means SPF passes AND the Return-Path domain aligns with the From domain.
- DKIM alignment means DKIM passes AND the signing d= domain aligns with the From domain.
For a message to pass DMARC, at least one of these must hold, SPF passing and aligned, or DKIM passing and aligned. Only one is needed, but at least one is required.
The single most common DMARC misunderstanding is treating a passing SPF result or a valid DKIM signature as sufficient for DMARC. It is not. A message can have SPF passing, DKIM verifying cleanly, and still fail DMARC, because neither passing mechanism aligns with the From domain. SPF can pass on a Return-Path domain that differs from the From domain; DKIM can verify with a d= domain that differs from the From domain. In both cases the mechanism passes and DMARC still fails, because DMARC requires alignment, not just a pass. When DMARC is failing while SPF or DKIM appears to pass, the thing to check is alignment: does the passing mechanism's domain match the From domain.
For a PowerMTA operator, getting DMARC right is fundamentally about ensuring that at least one of SPF or DKIM both passes and aligns for every message. And the recommended way to ensure that is DKIM alignment, covered next.
SPF alignment versus DKIM alignment
DMARC can be satisfied by either SPF alignment or DKIM alignment, but the two are not equally robust, and the practitioner recommendation is to rely on DKIM alignment.
| Aspect | SPF alignment | DKIM alignment |
|---|---|---|
| Depends on | The Return-Path domain | The signing d= domain |
| Survives forwarding | No, SPF breaks on forwarding | Yes, if body and signed headers unchanged |
| Robustness | Fragile in intermediary scenarios | More durable |
| Recommended as primary | No | Yes |
SPF alignment is fragile. SPF depends on the Return-Path, and SPF breaks when mail is forwarded: a forwarder relays the message from its own IP, which the original domain's SPF record does not authorize, so SPF fails for forwarded mail. SPF alignment also requires the Return-Path to be aligned with the From domain, which is not always the case, especially for mail sent through intermediaries that use their own Return-Path.
DKIM alignment is more durable. A DKIM signature travels with the message and survives forwarding, as long as the message body and the signed headers are not modified, so DKIM can still verify and align after a forward where SPF would have failed.
For these reasons, the recommendation is to make DKIM alignment the primary path to DMARC compliance. For a PowerMTA operator, this means configuring PowerMTA to DKIM-sign with the sender's own domain, so the d= value aligns with the From header. SPF should still be configured correctly, it is the second path and a requirement in its own right, but DKIM alignment should be the path the operator counts on, because it holds up under the forwarding and intermediary scenarios that break SPF.
Relaxed and strict alignment modes
DMARC alignment has two modes, relaxed and strict, controlled by the adkim and aspf tags in the DMARC record, for DKIM and SPF alignment respectively.
Relaxed alignment is the default. It requires the two domains, the authenticated domain and the From domain, to share the same organizational domain. A subdomain aligns with the parent organizational domain under relaxed mode. So mail.example.com aligns with example.com, a DKIM signature with d=mail.example.com aligns with a From of example.com.
Strict alignment requires an exact match of the two domains. A subdomain does not align with the parent under strict mode; the authenticated domain must be exactly the From domain.
| Mode | Requirement | When to use |
|---|---|---|
| Relaxed (default) | Same organizational domain; subdomains align | Most senders; flexible and practical |
| Strict | Exact domain match | Senders wanting the tightest control |
For most senders, relaxed alignment is the practical choice, and it is the default. It gives the flexibility to use subdomains, a marketing subdomain, a transactional subdomain, while still aligning to the organizational domain. Strict alignment is for senders who want the tightest possible control and have no need for subdomain flexibility.
The PowerMTA operator's task interacts with the mode: under relaxed alignment, PowerMTA's DKIM signing domain needs to share the organizational domain with the From; under strict, it must match exactly. Relaxed is the default and the usual choice, and it is what the rest of this guide assumes.
Configuring SPF for PowerMTA
SPF is a DNS record, not a PowerMTA setting, but it must be configured to authorize the PowerMTA sending IPs.
The SPF record is a TXT record on the sending domain that lists the IPs and includes authorized to send mail for the domain. For a PowerMTA deployment, the SPF record must cover all the IPs PowerMTA's VMTAs send from:
# Example SPF record concept for a domain
# v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.10 -allThe principles for SPF with PowerMTA:
- Cover every sending IP. Every IP a PowerMTA VMTA sends from must be authorized by the SPF record, directly with an ip4 (or ip6) mechanism, or via an include of a range.
- Update SPF when IPs change. Adding a new sending IP or VMTA range means the SPF record must be updated to include it. An IP not in the SPF record fails SPF.
- Mind the DNS lookup limit. SPF has a limit on the number of DNS lookups it can trigger; an SPF record with too many includes exceeds it and fails. If the record is complex, SPF flattening, replacing includes with the actual IPs, may be needed.
- Use an appropriate enforcement. The SPF record ends with an enforcement mechanism, typically -all (hard fail) or ~all (soft fail) for IPs not listed.
One of the most common authentication failures after a configuration change is a new sending IP that was added to PowerMTA but never added to the SPF record. PowerMTA starts sending from the new IP, the SPF record does not authorize it, SPF fails for that mail, and depending on the DMARC alignment situation the mail can fail DMARC and be rejected by the strict bulk-sender enforcement. Any change to the PowerMTA sending IPs must be matched immediately by an SPF record update. The SPF record and the actual sending IPs must always agree.
The PTR reverse DNS requirement
Every PowerMTA sending IP needs a PTR record, a reverse DNS entry, and the reverse DNS must be set up correctly as forward-confirmed reverse DNS.
The PTR record maps an IP address back to a hostname, the reverse of the normal hostname-to-IP lookup. Receiving mail servers check the reverse DNS of the connecting IP as a basic legitimacy signal.
The forward-confirmed reverse DNS that receivers expect:
- The sending IP has a PTR record pointing to a hostname.
- That hostname has a forward DNS record (an A record) pointing back to the same IP.
- The HELO hostname PowerMTA announces is consistent with this.
A properly configured legitimate mail server has all three. An IP that lacks a PTR record, or whose PTR points to a hostname that does not forward-resolve back, or whose HELO does not match, looks like a misconfigured or suspicious sender, and receivers treat such mail with suspicion, depressing deliverability.
The PTR record is set with the IP's provider, the hosting or cloud provider that allocated the IP, not in PowerMTA. The operator's tasks:
- For every PowerMTA sending IP, arrange the PTR record with the IP's provider, pointing to a chosen hostname.
- Ensure that hostname has a forward A record pointing back to the IP.
- Set PowerMTA's HELO hostname for that IP, in the VMTA's smtp-source-host directive, to match.
This forward-confirmed reverse DNS with a consistent HELO is foundational. It is not part of DMARC strictly speaking, but it is part of the same family of authentication and legitimacy signals, and a sender working on DMARC, SPF, and DKIM should ensure the PTR setup is correct for every sending IP at the same time.
The DMARC policy levels and reports
The DMARC record published in DNS carries a policy, telling receivers what to do with mail that fails DMARC, and it can request reports.
The policy levels, set by the p= tag:
| Policy | What receivers do with failing mail |
|---|---|
| p=none | Nothing; monitor only. Reports still sent. |
| p=quarantine | Treat failing mail as suspicious (spam folder) |
| p=reject | Reject failing mail outright |
p=none is monitoring mode: receivers do not act on DMARC failures, but DMARC reports are still generated. p=none is where a sender starts, to gather data without risk. The bulk sender requirements require at minimum p=none.
p=quarantine tells receivers to treat failing mail as suspicious. p=reject tells receivers to reject failing mail. The trajectory for a mature sender is to move from p=none toward p=reject as they gain confidence that all their legitimate mail passes DMARC, because p=reject gives the strongest protection against impersonation of the domain.
DMARC aggregate reports are the data source for this. With the rua tag in the DMARC record, the domain owner receives aggregate reports from receivers, summarizing the DMARC results, how much mail passed, how much failed, on which authentication mechanisms, from which sources. These aggregate reports are how an operator confirms their legitimate mail is passing DMARC before tightening the policy, and how they detect a DMARC problem. An operator should publish a rua address and review the aggregate reports.
The progression for a PowerMTA operator: publish a DMARC record at p=none with a rua address, ensure DKIM alignment and SPF are correct, watch the aggregate reports to confirm all legitimate mail passes DMARC, and then move the policy toward p=reject for the full protection.
When DMARC fails
When DMARC is failing for legitimate mail, the diagnostic workflow:
Step 1: read the DMARC aggregate reports. The aggregate reports show which mail is failing DMARC and on which mechanisms. This is the primary diagnostic source. They show, per sending source, the SPF and DKIM pass and alignment results.
Step 2: determine SPF and DKIM status. For the failing mail, is SPF passing? Is DKIM passing? Is either aligning? The aggregate reports break this down.
Step 3: for a DKIM alignment failure, check the d= domain. If DKIM verifies but does not align, the signing d= domain does not match the From domain. Confirm PowerMTA is DKIM-signing with the sender's own domain. This is the most common DMARC failure and the most important to fix, since DKIM alignment is the recommended path.
Step 4: for an SPF failure, check the SPF record. If SPF is failing, confirm the sending IPs are all in the SPF record. A new IP not added to SPF is a frequent cause.
Step 5: for an SPF alignment failure, check the Return-Path. If SPF passes but does not align, the Return-Path domain does not match the From domain. This is often expected for mail through intermediaries, and is the reason to rely on DKIM alignment instead.
Step 6: confirm at least one mechanism aligns. DMARC needs only one of SPF or DKIM to pass and align. The fix is to ensure at least one does, and DKIM alignment is the one to ensure first.
Step 7: verify with a test message. Send a test to an account that exposes the Authentication-Results header, and confirm SPF, DKIM, and DMARC, with alignment, all pass.
Step 8: re-check the aggregate reports. After a fix, the DMARC aggregate reports over the following days confirm the legitimate mail is now passing DMARC.
An operator we worked with had set up DMARC and published a record at p=none, intending to move toward p=reject once they confirmed their mail was passing. But their DMARC aggregate reports showed a troubling proportion of their own legitimate mail failing DMARC, and they could not move toward a stricter policy with that failure rate. They were confused, because they had SPF set up and they had DKIM set up, and both, they believed, were working. We went through the aggregate reports with them in detail. The reports broke the results down by mechanism, and the picture was specific. For the failing mail, SPF was passing, the sending IPs were in the SPF record, but SPF was not aligning. And DKIM, on that same mail, was not passing at all. So neither mechanism was both passing and aligning, which is exactly the condition for a DMARC failure. The SPF non-alignment had a clear cause: the mail in question was being sent with a Return-Path on a different domain, a bounce-handling subdomain that did not share the organizational domain with the From address in the way relaxed alignment needs, so SPF passed on the Return-Path domain but did not align with the From domain. And the DKIM failure had its own cause: for that particular sending stream, PowerMTA's DKIM signing had not been configured, the domain-key directive was missing on the VMTA that stream used, so that stream's mail was not being DKIM-signed at all. So the operator's belief that they had SPF and DKIM working was half right: SPF was working but not aligning for this stream, and DKIM was simply not happening for this stream. With neither mechanism passing-and-aligning, DMARC failed. The fix was to configure DKIM signing for that stream, adding the domain-key directive to the VMTA so the stream's mail was DKIM-signed with the sender's own domain, which gave it DKIM alignment. Once that stream was DKIM-signing with the correct domain, its mail had DKIM passing and aligned, DMARC passed, and the failure rate in the aggregate reports dropped to near zero, after which the operator could confidently move the policy toward p=reject. The lesson is the central point of this guide: DMARC requires a mechanism to both pass and align, and an operator who has SPF and DKIM individually present can still fail DMARC if neither aligns. The DMARC aggregate reports are the diagnostic tool that shows exactly which mechanism is failing and why, and the fix is to ensure DKIM alignment, the robust path, by confirming PowerMTA DKIM-signs every stream with the sender's own domain.
DMARC builds on SPF and DKIM but adds the requirement that is the hard part: alignment. For a message to pass DMARC, SPF or DKIM must not just pass but pass in a way that ties to the From domain, and a message with valid SPF and valid DKIM can still fail DMARC if neither aligns. The recommended path is DKIM alignment, because a DKIM signature survives forwarding where SPF breaks, so a PowerMTA operator should ensure PowerMTA DKIM-signs every stream with the sender's own domain. SPF must still be configured to authorize every sending IP, and updated whenever the IPs change. Every sending IP needs forward-confirmed reverse DNS, a PTR record pointing to a hostname that resolves back, with a matching HELO. The DMARC record carries a policy, from p=none monitoring toward p=reject, and the aggregate reports are the diagnostic and confirmation tool throughout. Operators who understand that DMARC needs a mechanism to pass and align, ensure DKIM alignment as the durable path, keep SPF and PTR correct, and watch the aggregate reports, get reliable DMARC compliance; operators who assume a passing SPF or a valid DKIM signature is enough discover, in the aggregate reports, that passing without aligning fails DMARC all the same.