Networking & DNS / Security

Configure and validate SPF, DKIM, and DMARC for a mail domain

Inventory every sender, publish a bounded SPF policy, deploy rotating DKIM selectors, begin DMARC reporting, analyze alignment, and progress enforcement safely.

90 min8 stepsChanges system stateRevision 2

Save or explore

#email #dns #spf #dkim #dmarc #deliverability

0 of 8 steps completed

Goal

Make domain authorization and message alignment observable before moving to quarantine or reject.

Supported environments

DNS SPF RFC 7208, DKIM RFC 6376, DMARC RFC 9989

Prerequisites

Authoritative DNS and stable identity Control forward and reverse DNS, choose the canonical mail hostname and domains, and verify the host is not behind an outbound SMTP-blocking network.hostname -f; getent ahosts $(hostname -f); dig +short -x {{publicIp}}
Recovery and queue safety Keep console access, back up active configuration, and record queue state before changing routing, authentication, filters, or mailbox delivery.
Abuse and deliverability plan Define relay boundaries, account owners, rate limits, bounce handling, postmaster address, monitoring, and how compromised credentials will be revoked.

Operating boundary

OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.

Full guide

What you will build

System

A production Postfix implementation of “Configure and validate SPF, DKIM, and DMARC for a mail domain” with explicit SMTP/IMAP boundaries, identity, durable state and observable delivery evidence.
A read-only baseline, staged candidate and end-to-end canary covering DNS, TLS, authentication, recipient or route policy, queue/mailbox state and logs.
A security and rollback procedure that avoids open relay, backscatter, plaintext credentials, world-readable keys/mail and unreviewed bulk queue actions.

Observable outcome

Make domain authorization and message alignment observable before moving to quarantine or reject. The intended success path is visible in native status, protocol transcript, headers or mailbox evidence.
Expected unauthorized relay, unknown-recipient, wrong-sender, invalid-authentication or wrong-certificate tests fail at the declared boundary without harming unrelated mail.

Architecture

How the parts fit together

Authoritative DNS publishes address/MX identity, reverse DNS is delegated by the address owner, SPF describes permitted senders, DKIM selectors publish verification keys and DMARC states alignment/reporting policy. These records do not replace correct MTA behavior; they let receivers authenticate and apply domain policy. Changes are staged with TTL-aware observation, controlled signed messages and aggregate-report review before enforcement is increased.

Forward and reverse identityAlign mail hostname, address, MX and PTR.

SPFLists authorized envelope-sender infrastructure.

DKIMAuthenticates signed content and signing-domain identity.

DMARCEvaluates alignment, publishes receiver policy and requests aggregate reports.

Inventory hostname/DNS, listeners, certificates, identities, recipient/relay maps, queue/mailbox state, logs and a recoverable configuration/data baseline.
Prepare the dns policy candidate with official Postfix syntax, protected secrets and one explicit service/data boundary at a time.
Run native configuration validation and immediate read-only checkpoint before reload or acceptance of new messages.
Use controlled local and external canaries plus an expected-denial test, preserve message identifiers/headers, and retain the prior configuration for rollback.

Assumptions

The public mail hostname, forward/reverse DNS ownership, supported package version and responsibility for ports 25/587/993 are known.
A maintenance or canary window, console recovery and current protected backup of configuration, keys, identity mappings and relevant mailbox/queue data exist.
Test sender and recipient addresses are owned by the operator; no unsolicited or third-party traffic is generated during verification.
Secrets and private keys are delivered outside shell history and have narrowly defined service ownership and rotation plans.

Key concepts

envelope identity: SMTP sender and recipient used for routing, delivery status and SPF; it is distinct from visible message headers.
open relay: An MTA that accepts unauthorized third-party sender-to-recipient forwarding, enabling abuse and reputation damage.
backscatter: A later non-delivery report sent to a forged sender because an invalid recipient was accepted instead of rejected during SMTP.
alignment: DMARC relationship between visible From domain and authenticated SPF or DKIM domain.
Maildir: A mailbox format storing messages as individual files in cur/new/tmp directories with strict ownership.

Before you copy

Values used in this guide

{{authoritativeNs}}

Operator-reviewed value used by this tutorial for authoritativeNs; derive it from the target environment and never from untrusted request data.

Example: ns1.example.net

{{dmarcReviewCsv}}

Operator-reviewed value used by this tutorial for dmarcReviewCsv; derive it from the target environment and never from untrusted request data.

Example: /srv/mail-reports/dmarc-summary.csv

{{domain}}

Fully qualified public or internal hostname served by this configuration.

Example: example.com

{{knownSelectors}}

Operator-reviewed value used by this tutorial for knownSelectors; derive it from the target environment and never from untrusted request data.

Example: mail2026 mail2025

{{receivedMessage}}

Operator-reviewed value used by this tutorial for receivedMessage; derive it from the target environment and never from untrusted request data.

Example: /srv/mail-fixtures/received-message.eml

{{selector}}

Operator-reviewed value used by this tutorial for selector; derive it from the target environment and never from untrusted request data.

Example: mail2026

Security and production boundaries

Never weaken relay/recipient checks, publish private DKIM/TLS keys, enable plaintext authentication, or expose web/IMAP administration broadly to make a test pass.
Mail content, credentials, queues, logs and backups contain personal or confidential data; restrict, encrypt, minimize and retain them under an explicit policy.
Use dedicated service identities and root-readable credential maps; verify logs and configuration output are redacted before sharing.

Stop before continuing if

Stop if a test permits unauthorized relay, accepts unknown recipients for later bounce, sends credentials without verified TLS, or exposes private keys/mailbox files.
Do not continue when hostname/PTR ownership, package/config version, recipient map, route, queue, mailbox ownership or rollback backup is ambiguous.
Immediately quarantine the candidate when unrelated mail is rerouted, deleted, multiply delivered, signed by the wrong domain, or inaccessible after reload.

instruction

Inventory every legitimate sending source

read-only

List direct MTAs, relays, SaaS senders, subdomains, return-path domains, DKIM domains/selectors, volume, owner, and decommission date.

Why this step matters

Inventory every legitimate sending source is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

List direct MTAs, relays, SaaS senders, subdomains, return-path domains, DKIM domains/selectors, volume, owner, and decommission date. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.

Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Inventory every legitimate sending source”. The scope must remain limited to the selected application and supported host.

Syntax explained

dig: Invokes the principal tool or configuration operation for “Inventory every legitimate sending source”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Domain{{domain}}Fully qualified public or internal hostname served by this configuration.Known Selectors{{knownSelectors}}Operator-reviewed value used by this tutorial for knownSelectors; derive it from the target environment and never from untrusted request data.

dig +short MX {{domain}}; dig +short TXT {{domain}}; for s in {{knownSelectors}}; do dig +short TXT "$s._domainkey.{{domain}}"; done

Example output / evidence

Every sender has an owner and alignment path.

Checkpoint: Checkpoint: Inventory every legitimate sending source

Continue whenEvery sender has an owner and alignment path. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

Stop whenStop before the next step when dig reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.

If this step fails

The command for “Inventory every legitimate sending source” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v dig 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

instruction

Design one bounded SPF record

read-only

Authorize only current sending mechanisms, avoid duplicate records, keep DNS lookup count within protocol limits, and end with ~all during observation or -all after proof.

Why this step matters

Design one bounded SPF record is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

Authorize only current sending mechanisms, avoid duplicate records, keep DNS lookup count within protocol limits, and end with ~all during observation or -all after proof. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Design one bounded SPF record”. The scope must remain limited to the selected application and supported host.

Syntax explained

dig: Invokes the principal tool or configuration operation for “Design one bounded SPF record”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
|: Passes standard output to the next read-only inspection stage; review each stage separately if the combined result is surprising.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Domain{{domain}}Fully qualified public or internal hostname served by this configuration.

dig +short TXT {{domain}} | grep 'v=spf1' || true

Example output / evidence

There is at most one planned SPF policy with documented mechanisms.

Checkpoint: Checkpoint: Design one bounded SPF record

Continue whenThere is at most one planned SPF policy with documented mechanisms. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

If this step fails

The command for “Design one bounded SPF record” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v dig 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

config

Publish and validate SPF

caution

Add the TXT record at the envelope-from domain, wait for authoritative propagation, and test direct plus relayed sources.

Why this step matters

Publish and validate SPF is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

Add the TXT record at the envelope-from domain, wait for authoritative propagation, and test direct plus relayed sources. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Publish and validate SPF”. The scope must remain limited to the selected application and supported host.

Syntax explained

dig: Invokes the principal tool or configuration operation for “Publish and validate SPF”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
configuration file: Is the persistent configuration boundary changed by this step. Keep an attributable backup and validate the consumer before reload.

Configuration

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Domain{{domain}}Fully qualified public or internal hostname served by this configuration.Authoritative Ns{{authoritativeNs}}Operator-reviewed value used by this tutorial for authoritativeNs; derive it from the target environment and never from untrusted request data.

dig +short TXT {{domain}} @{{authoritativeNs}}; dig +short TXT {{domain}} @1.1.1.1

Example output / evidence

Authoritative and recursive resolvers return the same single SPF record.

Checkpoint: Checkpoint: Publish and validate SPF

Continue whenAuthoritative and recursive resolvers return the same single SPF record. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

If this step fails

The command for “Publish and validate SPF” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v dig 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

command

Generate protected DKIM keys and selector records

caution

Create date-based selectors per signing system, protect private keys on signers, and publish public keys at selector._domainkey.

Why this step matters

Generate protected DKIM keys and selector records is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

Create date-based selectors per signing system, protect private keys on signers, and publish public keys at selector._domainkey. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Generate protected DKIM keys and selector records”. The scope must remain limited to the selected application and supported host.

Syntax explained

openssl: Invokes the principal tool or configuration operation for “Generate protected DKIM keys and selector records”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Selector{{selector}}Operator-reviewed value used by this tutorial for selector; derive it from the target environment and never from untrusted request data.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out {{selector}}.key; chmod 0600 {{selector}}.key; openssl pkey -in {{selector}}.key -pubout

Example output / evidence

Private and public key material are created with protected private permissions.

Checkpoint: Checkpoint: Generate protected DKIM keys and selector records

Continue whenPrivate and public key material are created with protected private permissions. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

Stop whenStop before the next step when openssl reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.

If this step fails

The command for “Generate protected DKIM keys and selector records” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v openssl 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

verification

Enable signing and verify alignment

read-only

Send canaries through every authorized path and confirm d= aligns with visible From, selector is current, body/header canonicalization survives transit, and verifier returns pass.

Why this step matters

Enable signing and verify alignment is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

Send canaries through every authorized path and confirm d= aligns with visible From, selector is current, body/header canonicalization survives transit, and verifier returns pass. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Enable signing and verify alignment”. The scope must remain limited to the selected application and supported host.

Syntax explained

dig: Invokes the principal tool or configuration operation for “Enable signing and verify alignment”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
|: Passes standard output to the next read-only inspection stage; review each stage separately if the combined result is surprising.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Selector{{selector}}Operator-reviewed value used by this tutorial for selector; derive it from the target environment and never from untrusted request data.Domain{{domain}}Fully qualified public or internal hostname served by this configuration.Received Message{{receivedMessage}}Operator-reviewed value used by this tutorial for receivedMessage; derive it from the target environment and never from untrusted request data.

dig +short TXT {{selector}}._domainkey.{{domain}}; grep -iE '^(DKIM-Signature|Authentication-Results):' {{receivedMessage}}

Example output / evidence

Every sender path records dkim=pass with expected aligned domain.

Checkpoint: Checkpoint: Enable signing and verify alignment

Continue whenEvery sender path records dkim=pass with expected aligned domain. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

If this step fails

The command for “Enable signing and verify alignment” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v dig 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

config

Publish DMARC in monitoring mode

caution

Begin with p=none, a dedicated aggregate-report mailbox, alignment choices, percentage, and subdomain policy; protect the report-processing mailbox.

Why this step matters

Publish DMARC in monitoring mode is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

Begin with p=none, a dedicated aggregate-report mailbox, alignment choices, percentage, and subdomain policy; protect the report-processing mailbox. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Publish DMARC in monitoring mode”. The scope must remain limited to the selected application and supported host.

Syntax explained

dig: Invokes the principal tool or configuration operation for “Publish DMARC in monitoring mode”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
configuration file: Is the persistent configuration boundary changed by this step. Keep an attributable backup and validate the consumer before reload.

Configuration

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

dig +short TXT _dmarc.{{domain}} @{{authoritativeNs}}

Example output / evidence

A single valid DMARC record with p=none and reporting destination is authoritative.

Checkpoint: Checkpoint: Publish DMARC in monitoring mode

Continue whenA single valid DMARC record with p=none and reporting destination is authoritative. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

If this step fails

The command for “Publish DMARC in monitoring mode” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v dig 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

instruction

Analyze aggregate reports and remediate sources

read-only

For at least one representative sending cycle, group reports by source, SPF/DKIM result, alignment, volume, and owner; remove unknown senders or fix them.

Why this step matters

Analyze aggregate reports and remediate sources is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

For at least one representative sending cycle, group reports by source, SPF/DKIM result, alignment, volume, and owner; remove unknown senders or fix them. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Analyze aggregate reports and remediate sources”. The scope must remain limited to the selected application and supported host.

Syntax explained

printf: Invokes the principal tool or configuration operation for “Analyze aggregate reports and remediate sources”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Dmarc Review Csv{{dmarcReviewCsv}}Operator-reviewed value used by this tutorial for dmarcReviewCsv; derive it from the target environment and never from untrusted request data.

printf '%s\n' 'source,volume,spf,dkim,alignment,owner,action' > {{dmarcReviewCsv}}

Example output / evidence

All material mail streams pass at least one aligned identifier or have a remediation owner.

Checkpoint: Checkpoint: Analyze aggregate reports and remediate sources

Continue whenAll material mail streams pass at least one aligned identifier or have a remediation owner. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

Stop whenStop before the next step when printf reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.

If this step fails

The command for “Analyze aggregate reports and remediate sources” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v printf 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

config

Progress to quarantine and reject with staged percentages

caution

Increase enforcement only after report evidence, test subdomains and forwarded mail, maintain an emergency rollback, and record the next review.

Why this step matters

Progress to quarantine and reject with staged percentages is a separate checkpoint because it establishes one auditable part of make domain authorization and message alignment observable before moving to quarantine or reject. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.

What to understand

Increase enforcement only after report evidence, test subdomains and forwarded mail, maintain an emergency rollback, and record the next review. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.

System changes

This step may affect the files, packages, identities, services, or runtime policy named in “Progress to quarantine and reject with staged percentages”. The scope must remain limited to the selected application and supported host.

Syntax explained

dig: Invokes the principal tool or configuration operation for “Progress to quarantine and reject with staged percentages”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}: Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
configuration file: Is the persistent configuration boundary changed by this step. Keep an attributable backup and validate the consumer before reload.

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Domain{{domain}}Fully qualified public or internal hostname served by this configuration.

dig +short TXT _dmarc.{{domain}} @1.1.1.1

Example output / evidence

The staged policy, pct, subdomain policy, and rollback owner are documented.

Checkpoint: Checkpoint: Progress to quarantine and reject with staged percentages

Continue whenThe staged policy, pct, subdomain policy, and rollback owner are documented. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.

If this step fails

The command for “Progress to quarantine and reject with staged percentages” fails, produces no useful evidence, or the expected service/configuration state is absent.

Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.

Safe checks

command -v dig 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
journalctl -p warning -n 50 --no-pager 2>/dev/null || true

Security notes

Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.

Alternatives

When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.

Stop conditions

Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.

Finish line

Verification checklist

DNS uniqueness and visibilitydig +short TXT {{domain}}; dig +short TXT _dmarc.{{domain}}; dig +short TXT {{selector}}._domainkey.{{domain}}Exactly one SPF and DMARC policy plus the active DKIM selector are visible.

Real-message alignmentgrep -iE 'Authentication-Results:.*(spf=pass|dkim=pass|dmarc=pass)' {{receivedMessage}}The representative external message passes DMARC through an aligned SPF or DKIM identifier.

Recovery guidance

Common problems and safe checks

A message remains queued or the remote server returns a temporary 4xx response.

Likely causeDNS/MX resolution, routing, network reachability, TLS negotiation, remote greylisting/rate limits, reputation or recipient policy prevents delivery.

Safe checks

exim -bp 2>/dev/null || postqueue -p
dig +short MX example.net
journalctl -u exim4 -u postfix --since '-30 min' --no-pager

ResolutionInspect one message's recorded diagnostic and route first, fix the evidenced dependency, then retry only that message; do not force an undiagnosed bulk queue.

SMTP accepts a recipient, but the mailbox is absent, unreadable or never visible over IMAP.

Likely causeRecipient maps, LMTP/LDA route, virtual UID/GID, Maildir path, quota, Dovecot namespace or filesystem permissions disagree.

Safe checks

doveconf -n
doveadm user user@example.com
doveadm mailbox list -u user@example.com

ResolutionTrace the exact address through recipient validation, delivery socket and resolved mailbox path; correct the narrow mapping/ownership mismatch before accepting more mail.

Authentication or TLS fails despite apparently correct credentials and certificate files.

Likely causeThe listener uses another configuration, hostname/SAN does not match, chain/key permissions are wrong, authentication is attempted without TLS, or the identity backend maps another username.

Safe checks

openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com </dev/null
openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null
journalctl -u dovecot -u postfix -u exim4 -p warning -n 100 --no-pager

ResolutionVerify the advertised hostname, chain, listener and mapped user independently; never disable certificate verification or enable plaintext authentication to bypass the failure.

After the procedure

Alternatives and next steps

Consider these alternatives

Use a reputable managed mail transport or mailbox provider when staffing, deliverability, abuse response, DNS reputation and 24/7 queue operations cannot be sustained.
Separate inbound, outbound, submission and mailbox roles across hosts only when TLS identity, routing, backups and observability remain end-to-end testable.

Operate it safely

Alert on queue age/depth, delivery deferrals, authentication failures, TLS/certificate expiry, disk/quota pressure, DKIM/DMARC failures and backup restore age.
Review relay/recipient maps, dormant users, supported versions, DNS policy and key/certificate rotation at least every 90 days.
Practice one-message queue diagnosis and an isolated mailbox/config restore so incident steps are proven before a real outage.

Reference

Frequently asked questions

Why is one successful test email insufficient?

It may bypass the actual external DNS, authentication, recipient, DKIM, queue retry or IMAP path. Test each boundary and preserve protocol/header evidence.

Can TLS be tested by checking that encryption is present?

No. Verify the chain and hostname and ensure authentication is unavailable before STARTTLS; encryption to an unverified endpoint is not server authentication.

Should a stuck queue be forced immediately?

No. Read one message's diagnostic and fix the dependency first. Bulk retries can amplify rate limits, duplicates or reputation damage.

Recovery

Rollback

Revert DMARC enforcement to monitoring and switch signing back to a still-published selector; do not publish multiple SPF records.

Change DMARC p to none or lower pct using normal DNS change control while preserving reporting.
Restore the prior DKIM selector on signers and keep both public keys during overlap.
Revert SPF by editing the single record, not by adding a second one.

Evidence

Sources and review

Verified 2026-07-25Review due 2026-10-23

RFC 7208: Sender Policy Frameworkofficial RFC 6376: DomainKeys Identified Mailofficial RFC 9989: Domain-based Message Authentication, Reporting, and Conformanceofficial