For an existing PostageApp sending domain, open Domains > your domain > Domain Setup and Configuration > Show Details, obtain the provider-issued SPF and DKIM TXT instructions, publish them safely and confirm both statuses show Valid. Then test an actual application message: Valid confirms PostageApp's DNS check, not that the intended branded signature passed at the receiving service. Official setup procedure.
Scope and prerequisites
This guide covers the documented existing-domain TXT workflow for PostageApp's native application-email service. It does not invent initial domain creation, migrate an application, configure a Postfix relay, create API keys or change project permissions. You need an existing account and sending domain, permission to inspect its authentication instructions, and an authorized DNS administrator for the actual domain authority.
PostageApp's Quick Start separately requires ownership confirmation for sending addresses and directs users to the Senders tab. Its detailed authentication article uses Domains. These are different published navigation descriptions, not evidence that one has been renamed to the other. Confirm sender ownership through the instructions your account actually displays. If the existing-domain detail screen or record packet is unavailable, stop and obtain current PostageApp guidance rather than guessing an Add Domain flow. Quick Start.
The Quick Start describes projects with separate API keys and statistics. Record the project and application that will use this sender, but do not change keys or move traffic as part of DNS authentication. No universal role, paid-plan gate, regional SPF include, selector or envelope domain is established by these public instructions.
Before editing, save current DNS owners, values and TTLs, approved sending services, existing selectors, delegations and the direct/inherited DMARC policy. Identify the application owner and who can pause only its affected messages if a change fails. Keep staff-mail MX, website records and unrelated projects unchanged.
Obtain the exact PostageApp TXT packet
- Sign in through your approved account access method.
- On the dashboard, open Domains and choose the domain actually used for sending.
- Open Domain Setup and Configuration and choose Show Details.
- Copy the complete instruction in Domain SPF Configuration.
- Copy the bold owner name and full TXT value in DKIM Email Signing.
- Record which domain, account and project the packet belongs to before handing it to the DNS owner.
The official procedure specifies TXT for both SPF and DKIM. It does not publish a universal reusable selector or key. Do not replace the actual packet with a guessed PostageApp include, a copied screenshot key or an independently generated private key. API credentials authenticate application access; they are not DKIM public DNS material. PostageApp record issuance.
Use the actual authoritative DNS provider. The page's DNS locator can help identify it, but the registrar and DNS host are not always the same. If the provider gives an incomplete owner or a value that conflicts with your current policy, resolve the discrepancy before publication.
Publish SPF and DKIM without breaking another sender
For SPF, use the issued owner and authorization while preserving the complete existing policy as described below. A provider's standalone policy is not permission to overwrite staff-mail authorizations or change its final qualifier.
For an issued SPF owner example.com, use relative @ (or the DNS host’s documented apex input) in the example.com zone. For issued news.example.com, use relative news in the parent zone or @ in a separately delegated news.example.com zone. Publish at the actual authority; do not assume visible From identifies the SPF owner. For an apex-domain DKIM owner SELECTOR._domainkey.example.com, use SELECTOR._domainkey in the parent zone, or SELECTOR in an existing delegated _domainkey.example.com authority. Substitute the actual issued selector and preserve delegation. DNS owner names.
For DKIM, create the issued TXT owner and preserve the complete public-key value, including its tags and key data. Multiple quoted character strings within one TXT record may carry a long value; multiple separate competing TXT records are not equivalent. If the DNS editor rejects the key length, stop and use that host's supported long-TXT method or support assistance. Never truncate the key, remove required tags or downgrade its strength to fit a field. DKIM key lookup.
Translate the full issued owner for the actual authority. For illustrative SELECTOR._domainkey.news.example.com, enter relative SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey in delegated news.example.com, or SELECTOR in an existing delegated _domainkey.news.example.com zone. Replace SELECTOR and the domain with the real packet. Preserve NS delegation and other selectors; avoid an editor appending the domain twice. Relative names.
If this TXT owner already has a different key or a CNAME, identify the service dependency and coordinate a supported change. Do not delete it merely to make validation pass. This native TXT workflow has no new DKIM CNAME or HTTP-proxy setting to configure.
Confirm PostageApp validation
Return to the selected domain's configuration page. PostageApp documents Valid for both SPF and DKIM once the TXT records are in place. Its stated 20–60-minute propagation estimate is not a guarantee or a substitute for querying the actual authority and caches. The public procedure documents no additional signing-enable toggle; do not invent one. Validation status.
If status stays invalid, compare the exact owner, TXT content, authority and SPF policy first. If public answers match and the account still disagrees, provide the domain/selector and relevant non-secret evidence to PostageApp support through an approved channel. Do not expose API keys or private signing material, or relax DMARC to hide the symptom.
Preserve SPF and DMARC policy
SPF evaluates the actual SMTP MAIL FROM identity, not automatically the visible From address. A provider's domain-authorization instruction does not prove which envelope domain a delivered message uses. Inspect that identity separately; do not promise SPF alignment or invent a custom return path. EmailAuth's custom MAIL FROM and alignment guide explains why publication, routing and actual message identity are different checks.
Under strict aspf=s, the authenticated MAIL FROM domain must exactly equal the intended visible From domain. A child envelope such as bounce.example.com does not strictly align with From example.com, even though they share an Organizational Domain and can align in relaxed mode. PostageApp’s reviewed workflow does not establish a configurable envelope identity, so do not promise this result. SPF alignment.
Keep one v=spf1 TXT policy at each evaluated owner. Merge only the approved provider authorization into an existing policy before its terminal all; retain other legitimate senders and the approved qualifier. Count the ten evaluated DNS-dependent terms across includes and redirects, not merely ten top-level includes. If a policy uses redirect=, do not blindly add all: an all mechanism makes the redirect ignored. Review the complete resulting authorization instead. Do not freeze changing provider IPs into a static SPF record as a shortcut. SPF processing, redirect.
Look up the direct and applicable inherited DMARC policy for the intended visible From domain. Preserve its enforcement, alignment settings and approved report recipients. Do not replace a working policy with a provider's p=none example, duplicate DMARC, or create a child monitoring override that weakens inherited protection.
Only if no direct or applicable inherited policy exists and the domain owner approves a monitoring and review plan, an illustrative first record is TXT with value v=DMARC1; p=none. From example.com uses full owner _dmarc.example.com, relative _dmarc in its zone. From news.example.com uses _dmarc.news.example.com: relative _dmarc.news in the parent zone, but _dmarc at a separately delegated news.example.com authority. Preserve that delegation. This value requests no reports by itself. DMARC publication.
Add rua only for a provisioned, approved and monitored recipient. Compare the Organizational Domain of the report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily visible From. If they differ, the report-generating receiver must check external-report DNS authorization; a destination within the same Organizational Domain as the policy domain is excepted. A different hostname alone is not sufficient. This check does not replace the owner's approval to share report data. RFC 9990 section 4.
DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict adkim=s requires the signing domain to match the From domain exactly. Check the effective policy, not just a green dashboard. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around that obsolete tag. For domains publishing p=reject, retain the valid-DKIM requirement and consider indirect/list interoperability before changing policy. Alignment, indirect flows.
Prove publication and actual signing separately
Use read-only queries with the actual authority and account-issued names in place of these uppercase placeholders:
dig +short NS YOUR-ZONE
dig @AUTHORITATIVE-NS TXT YOUR-SPF-OWNER +noall +answer
dig @AUTHORITATIVE-NS TXT YOUR-DKIM-OWNER +noall +answer
dig @1.1.1.1 TXT YOUR-DKIM-OWNER +noall +answer
dig @1.1.1.1 TXT _dmarc.YOUR-FROM-DOMAIN +noall +answer
Resolve any discrepancy between authoritative and recursive answers before claiming completion. A successful DNS lookup is not a delivered-message test. Save the full owner, type, value, timestamp and provider status without publishing private credentials.
Have an authorized operator send new representative messages through the intended application or campaign path to controlled external recipients. Use synthetic records and approved harmless content, not real customer notifications. Capture the unchanged intended visible From, actual MAIL FROM/Return-Path, DKIM d= and s=, route and time.
Establish which Authentication-Results fields the actual receiving service generated inside its known processing boundary and how it removes, ignores or distinguishes externally supplied fields. Use documented receiver handling or an administrator-verified trace if unclear. Header position or a familiar authserv-id string alone is not proof. Ignore injected or otherwise untrusted results. Receiver trust boundary.
For branded-DKIM acceptance, match the intended provider's active issued d= and s= to the tested route. Require that signature to pass and align under effective adkim with the unchanged intended visible From, plus trusted receiver dmarc=pass. Another aligned signer, rewritten provider From or SPF-only DMARC pass does not complete this DKIM deployment.
Diagnose SPF separately at the actual smtp.mailfrom domain: fail or softfail calls for checking the connecting sender against approved authorization; temperror is a transient evaluation problem, often DNS; permerror calls for checking malformed or duplicate policies and the evaluated lookup budget. Aligned DKIM does not repair an SPF fault. Do not edit an unrelated apex policy to fix a provider-controlled envelope domain. SPF results.
Troubleshooting and safe recovery
- SPF remains invalid: Check the actual issued owner, duplicate policies, missing authorization and evaluated lookup budget. Preserve legitimate non-PostageApp senders.
- DKIM remains invalid: Check the complete owner, auto-appended suffix, truncated key, separate competing TXT records and authoritative DNS. A different project's key is not a replacement.
- Valid but no expected signature: Confirm the actual project/application route and sender identity. Collect a newly generated controlled message; old messages cannot prove the change.
- DKIM passes but DMARC fails: Compare the intended
d=and visible From under effective alignment policy. A root-domain key does not automatically provide strict alignment for a child From. - Authentication passes but delivery is poor: Investigate content, consent, complaints, reputation and application errors separately. Authentication never guarantees inbox placement.
Keep a before-and-after diff and the provider/receiver evidence. With the application and DNS owners' approval, pause only affected traffic or restore the prior approved records and transport configuration. Preserve selectors needed by queued mail; do not rotate keys or switch providers as an unapproved recovery shortcut. Retest the failed route and a known-good control after recovery.
Documentation and testing boundary
The complete official setup and Quick Start bodies were reviewed; neither provided decisive embedded setup screenshots. No customer account, DNS, application, API key or sending configuration was changed, and no message was sent. Account-specific activation and received-message checks remain the operator's acceptance work.