Why SPF, DKIM and DMARC decide whether self-hosted email gets delivered
Deliverability depends on authentication, DNS, TLS and sender reputation working together, and the mail server is only one part of that chain. For a regulated or sovereignty-driven team moving mail off a hosted provider, the risk is concrete: messages to Gmail and Outlook recipients land in spam or get rejected, and nobody notices until a client, regulator or patient asks why a notice never arrived. Stalwart, mailcow and OX App Suite each handle sending, but the choice among them matters less than the sending path around them: the DNS records published for your domains, the signing keys, the IP address the server leaves from, and the relay, if any, that carries the traffic out.
Start with the rules the largest mailbox providers enforce. Google's email sender guidelines require every sender to Gmail to set up SPF or DKIM, maintain valid forward and reverse DNS, use TLS and keep the spam rate in Postmaster Tools below 0.3%. Senders above 5,000 messages a day must also publish DMARC and align the From domain with SPF or DKIM. Confirm the current wording with the provider before you design around it, because these requirements change. Then map each control to an owner: who publishes the TXT records, who rotates the DKIM selector, who owns the PTR record with the ISP or hosting company, and who reads the DMARC aggregate reports each week.
Monitoring is what keeps this working after go-live. Enroll your sending domains in Postmaster Tools, start DMARC in monitoring mode, and review aggregate reports for unknown senders before tightening the policy. If you plan to relay through a smarthost, decide early whether it is a regulated decision or a technical one, because it changes which IP reputation your mail carries and who can see message flow. Ask any implementation partner to show the sending path, the records already live for each domain, and a test that proves alignment for real messages.
Which sender requirements apply to self-hosted mail and what each means for the build
This table maps Google's sender rules and the regulatory retention and transmission rules to the configuration tasks they create for a self-hosted mail server. Read each row as a build item to configure and confirm, since the thresholds and wording of Google's requirements can change. The main takeaway is that regulation shapes routing and logging, while authentication and reputation remain sender requirements that apply to every mail flow.
| Requirement | What it asks for | What to configure |
|---|---|---|
| SPF or DKIM for all senders | Every sender to Gmail publishes at least one of SPF or DKIM | Publish SPF for each sending domain and sign outbound mail with DKIM keys on the server |
| Forward and reverse DNS | Sending IP addresses have valid forward and reverse DNS records | Set the PTR record with the hosting provider to match the mail host name and confirm forward resolution |
| TLS on delivery | Mail is transmitted with TLS | Enforce STARTTLS on inbound and outbound SMTP and use valid certificates that match the host name |
| Spam rate in Postmaster Tools | Reported spam rate stays below 0.3 percent | Connect the domain to Postmaster Tools and track spam rate per sending domain |
| DMARC above 5,000 messages a day | Senders above this volume set up SPF, DKIM and DMARC and align the From domain with SPF or DKIM | Publish a DMARC policy, check alignment on every outbound stream and review aggregate reports |
| One-click unsubscribe | Marketing and subscribed messages support one-click unsubscribe | Confirm whether any bulk or newsletter flows run through the server and add the List-Unsubscribe headers where they apply |
| HIPAA transmission protection (45 CFR 164.312(e)(1)) | Guard ePHI sent over electronic networks against unauthorized access | Route external mail with enforced encryption and document the relay path; authentication still applies to every flow |
| SEC 17a-4 retention (17 CFR 240.17a-4) | Preserve originals of received and copies of sent business communications for at least three years | Journal outbound and inbound mail to a separate archive so the sending path produces a complete copy; confirm with counsel |
| Confirm current requirements | Google and regulators update rules and thresholds | Check Google's sender guidelines and your own mail flows, including forms, scanners and applications that send mail |
Which mail platforms fit a deliverability-first build and why
Three self-hosted mail platforms fit different operating models, but none of them fixes deliverability on its own. The DNS records, sending IP address, reverse DNS and relay choice shape inbox placement in every case, so the platform decision is best made alongside the sending design.
Stalwart as an all-in-one server
Stalwart is an all-in-one mail and collaboration server licensed under AGPL-3.0 that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV. Its README lists DMARC, DKIM, SPF and ARC support, along with clustering and multi-tenancy, so authentication checks and signing sit inside the server rather than in a separate package. Confirm the current DKIM signing, ARC and DMARC reporting behavior against the project documentation before you design around it, and check whether an Enterprise License changes the feature set you need.
mailcow as a packaged Docker stack
mailcow-dockerized is a GPL-3.0 project that packages a full mail stack as Docker containers, which suits teams that want a single, documented deployment on one host. Its release cadence is visible in the repository, so plan for regular upgrades and a tested update window. Confirm how DKIM keys are generated and rotated, which reporting tools are bundled, and how the stack handles outbound relay before you commit to it for a sending domain.
OX App Suite v8 on Kubernetes
OX App Suite v8 is designed to run on Kubernetes and is delivered as Helm charts that reference container images, with Helm 3.17.0 or newer required. It requires Istio, with a basic ingress-nginx option where Istio cannot be used, and it uses MariaDB as its primary store and Redis 7.4.x for caching and sessions. Plan for a platform team to run this stack. v8.47 is the current LTS, so schedule upgrades around the support window.
Relay and IP choices apply to all
Gmail's sender rules require valid forward and reverse DNS, SPF or DKIM, and TLS, and none of these three platforms can supply a clean sending reputation for you. Whether you send from your own address block or relay through a provider changes how much of the reputation you inherit. Ask each vendor or partner how they handle outbound relay, IP warm-up and blocklist monitoring, because those decisions carry more weight for inbox placement than the choice of server software.
Matching the platform to your team
Choose Stalwart when you want one server with built-in authentication and clustering, mailcow when a single host and a documented Docker stack fit your operating model, and OX App Suite when you need a groupware suite on Kubernetes with a supported LTS line. Illustrative example: a team with no Kubernetes practice may find a Docker stack easier to run than a Helm-based suite, even when the suite offers more features. Weigh platform skills, not feature lists alone.
Verifying authentication before cutover
Whichever platform you pick, test SPF, DKIM and DMARC alignment against real sends to Gmail and Outlook before moving production mail. Check that the From domain aligns with the authenticated domain, that DKIM keys match the published DNS records and that reports arrive at the DMARC mailbox. Keep a rollback plan for DNS changes, because a misconfigured policy can block legitimate mail from the first day.
How the sending path decides whether Gmail trusts your domain
Gmail does not judge a message on one record. It checks a chain of facts that must agree: the sending IP address and its reverse DNS (PTR) record, the forward DNS name the mail host claims, TLS on both submission and delivery, the SPF record that lists which servers may send for the domain, the DKIM signature and its selector, and the DMARC policy that ties the visible From domain to SPF or DKIM. Google's email sender guidelines require every sender to have SPF or DKIM, valid forward and reverse DNS, and TLS, so a gap anywhere in this chain is a gap Gmail can see. Before go-live, confirm that the PTR name resolves forward to the same host name your server announces in its SMTP banner, that the SPF record lists your outbound addresses and nothing else with a broad include, and that each sending domain has a DKIM key published under a selector your mail server actually signs with.
The failure that catches most self-hosted operators is alignment, not authentication. Consider an illustrative case: your Stalwart or mailcow server relays outbound mail through a smarthost, the smarthost's SPF record passes for its own envelope domain, and the DKIM signature is made by the smarthost's key for a different domain. The message reaches Gmail with a From address of billing@yourdomain.example, SPF passes for the relay, and DMARC fails because neither the SPF domain nor the DKIM domain matches the From domain. The reader's rule is simple: when you relay, either sign with a DKIM key for your own domain at the relay, or set the envelope sender so it sits on your domain and is authorized by your SPF record. Check the result in a test message's headers before you send live customer mail.
Once the chain is correct, the DMARC policy decides what happens to failures, and Postmaster Tools shows whether Gmail trusts the result. Start DMARC with a monitoring policy and read the aggregate reports for every service that sends as your domain, including invoicing, ticketing and marketing platforms that most teams forget. Google's guidelines add stricter requirements for bulk senders above 5,000 messages a day, including one-click unsubscribe for marketing and subscribed mail, so confirm your volume and message types early. Register each sending domain in Postmaster Tools and keep the reported spam rate under the 0.3% threshold in Google's guidelines. Assign one named owner for DNS changes and report review, because a silent SPF or DKIM change is the most common cause of a sudden drop in inbox placement.
Rollout phases for a deliverability-ready mail cutover
This sequence moves sending traffic from an unmanaged state to a documented, authenticated and monitored mail platform, so that each change to DNS, keys and routing is verified before the next one starts. Each phase ends with a written output that the client signs off.
Inventory every sending source
Start by listing every system that sends mail under your domains: the mail server, marketing platforms, ticketing and CRM tools, network scanners, line-of-business applications, and SaaS notifications such as billing, HR and password reset emails. The partner and your application owners confirm each source, its sending IP addresses or relay path, and the From domain it uses. The output is a sender register that names an owner for every source. The step is done when no known system sends mail without an entry in that register.
Audit DNS and reverse DNS records
Review the forward and reverse DNS for each outbound IP address, check that the PTR record resolves to a hostname that resolves back to the same address, and confirm that the TLS certificate presented on submission and delivery is valid and current. Compare the current SPF, DKIM and DMARC records against the sender register. The output is an audit report with each defect, its owner and the change needed. The step closes when the audit has no unresolved item for a sending source.
Generate DKIM keys and plan rotation
Generate a signing key pair for each sending domain and selector, store the private key where only the mail server can read it, and publish the public key in DNS under a named selector. Agree a rotation procedure with the partner that covers when old selectors are retired and who approves the change. The output is a key inventory with selector names, key sizes, storage locations and a rotation schedule owned by a named person. The step is done when test messages from each source pass DKIM verification at a receiving server.
Consolidate SPF within lookup limits
Merge the authorized senders into a single SPF record for each domain and check the number of DNS lookups it causes, because the SPF standard limits how many lookups a record may trigger during evaluation. Where a third-party service needs its own include, confirm the mechanism with that vendor and remove stale entries. The output is one reviewed SPF record per domain, with a note on each include and who maintains it. The step is done when the record evaluates without errors in a test tool and every source in the register is covered.
Run DMARC in monitoring mode
Publish DMARC records with the policy set to none so that no legitimate mail is rejected while you learn what is sending. Configure aggregate report addresses, then collect and parse the XML reports to see which sources pass SPF or DKIM and whether their From domain aligns with the authenticated domain. The output is a list of unaligned or unknown senders, each either fixed or confirmed as illegitimate. Keep this phase running until the reports show that all approved sources align. The partner should state in writing how long this monitoring period will last.
Stage DMARC enforcement
Move the policy from none to a stricter setting in controlled steps, starting with a subset of traffic if the DMARC standard allows it for your record, and watching the reports after each change. Keep rollback steps documented so the policy can return to monitoring if a legitimate sender breaks. The output is a dated enforcement record showing each policy change, the report review behind it, and the outcome. The step is done when the target policy is in place and the reports show no approved source failing alignment.
Decide on a smarthost and warm the sending IP
Decide whether outbound mail leaves directly from your own address or through a smarthost, a relay provider that sends on your behalf. Weigh the reputation of a new IP address, the control you keep over message content and logs, and the cost of managing a clean block of addresses. If you send directly, increase volume gradually so receiving providers can build trust in the address. The output is a documented routing decision with the relay contract or IP ownership record and a volume ramp plan. Ask the partner which option it recommends and why, in writing.
Monitor reputation with Postmaster Tools
Enroll each sending domain in Google Postmaster Tools, verify ownership, and review spam rate, authentication, encryption and delivery error data on a fixed schedule owned by a named operator. Combine that view with the DMARC aggregate reports and the mail server logs so that a drop in reputation is traced to a source. Google's sender guidelines set a spam rate threshold of 0.3 percent as reported in Postmaster Tools, so track the figure against it. The output is a recurring monitoring report and an escalation path for blocklistings and spam rate increases.
When to send directly and when to relay through a smarthost
Direct delivery means your mail server connects straight to the recipient's mail servers from an address you own. You control the sending IP, the reverse DNS record, the TLS configuration and the logs, so the whole delivery path stays inside your infrastructure. The trade-off is that reputation starts from zero and every blocklisting lands on your team. Gmail's sender guidelines expect valid forward and reverse DNS, TLS, SPF or DKIM, and spam rates in Postmaster Tools below 0.3%, so a direct sender must meet all of them from day one.
- IP block history: Check the address against major DNS blocklists and confirm with the ISP or cloud provider that it was not previously used for bulk or spam traffic.
- Reverse DNS: The PTR record must resolve to a hostname that forward-resolves back to the same address and matches the HELO name.
- Provider policy: Confirm that the cloud or ISP allows outbound port 25 and whether it applies rate limits or abuse reviews to new addresses.
- Log retention: Your own logs are the evidence, so set retention for SMTP transaction logs to match your archiving policy.
- Data location: Message content only transits the recipient's network, but confirm where the server and its logs are hosted.
Before go-live, confirm the address history and PTR record in writing with your provider, and test delivery to major mailboxes.
A smarthost is an intermediate server that accepts your outbound mail and delivers it on your behalf, usually from an IP address with an established reputation. The relay provider controls that IP, its blocklist response and often part of the delivery pipeline, so you gain reputation at the cost of visibility and some control. Your SPF record must authorize the relay, and DKIM signing usually stays on your server so the From domain still aligns with DMARC.
- Who controls the IP: The provider owns the sending address and handles delisting requests, so ask for its process and response times in writing.
- Logging and retention: Ask what the provider logs, how long it keeps message metadata and whether it keeps message content at all.
- Data location: Confirm the countries where the relay processes and stores mail, and whether sub-processors are involved.
- TLS on the hop: Require enforced TLS between your server and the relay, and confirm the relay's certificate handling.
- Archiving: Keep the journal or archive copy on your side, because the relay's copy is not your retention record.
For regulated mail, the relay becomes part of the transmission chain, so include it in the risk assessment and the processor agreement.
Hybrid routing sends some traffic directly and some through a relay, based on the recipient domain, the sending domain or the message class, such as marketing, system notices or regulated correspondence. It lets you keep sensitive or archived traffic on your own path while using a relay for high-volume or low-trust streams. The cost is complexity: two reputations, two SPF policies and two sets of logs that must be reconciled during an incident.
- Routing rules: Define routes in the MTA configuration by sender domain, recipient domain or header, and test each rule with sample messages.
- Separate sending domains: Use a dedicated subdomain for bulk or notification mail so a relay problem does not affect person-to-person mail.
- Policy consistency: Keep DMARC alignment and DKIM signing identical on both paths so recipients see the same authentication result.
- Archive coverage: Confirm that every route, including the relay path, passes through the journaling step if retention rules apply.
- Failover: Decide what happens if the relay is unavailable, and whether mail queues or falls back to direct delivery.
Run a test for each route and confirm that the archive received a copy of each message class.
Evidence to keep for DMARC, DNS and sender-rule reviews
This table lists each record a sender-rule or DMARC review will ask for, the component that produces it, and whether it maps to SEC Rule 17a-4 or HIPAA 164.312(b) audit expectations. Read the last column as a signal of where a retention or audit reviewer is likely to look, not as a compliance finding. DeployOpen prepares this evidence, but auditors and assessors decide whether it is sufficient.
| Evidence | Produced by | Retention or audit fit | What to confirm |
|---|---|---|---|
| DNS zone records for SPF, DKIM selectors and DMARC policy, with change history | DNS provider and version-controlled zone files | Supports 17a-4 and 164.312(b) if changes are dated and attributed to a named operator | Whether your DNS provider keeps a full audit log and how long it retains it |
| DMARC aggregate reports (rua) and forensic reports (ruf), parsed and archived | DMARC report processor receiving mail at the rua and ruf addresses | Supports review of alignment failures; forensic reports may contain message content, so confirm handling rules | Whether forensic reports are requested at all, and how personal data in them is minimized |
| Postmaster Tools spam-rate and domain reputation exports | Google Postmaster Tools, exported on a fixed schedule | Shows the spam-rate trend that Gmail sender guidelines reference; a periodic export is useful evidence | That the account is verified for each sending domain and that exports are stored outside the mail server |
| PTR (reverse DNS) and forward DNS records for each sending IP | DNS provider, checked by a scheduled script | Supports sender-rule review; not an audit control by itself | That PTR records match the mail hostname and that the owner of the IP address block controls the PTR |
| TLS configuration records for inbound and outbound SMTP | Mail server configuration and TLS scan results | Supports 164.312(e)(1) transmission security evidence where ePHI is in scope | Which TLS versions and cipher settings are enforced and whether opportunistic TLS is allowed for any partner |
| DKIM key rotation log with selector names and key creation dates | Mail server DKIM signing configuration and a change ticket | Supports change control evidence under 164.312(b) and general record integrity expectations | Who approves a rotation and how the retired public key is kept in DNS until old mail has aged out |
| Blocklist check history for sending IPs and domains | Scheduled blocklist lookup job writing dated results to a log store | Useful for showing when a listing was detected and how it was handled | Which lists your partner checks, how often, and who is alerted when a listing appears |
| Mail server delivery and authentication logs (SPF, DKIM, DMARC results) | Mail server logs forwarded to a central log platform | Supports 164.312(b) audit controls when logs are protected and retained; 17a-4 concerns the messages themselves, not logs | Log retention period, tamper protection and whether logs are kept separate from the mailbox server |
How to monitor deliverability with Postmaster Tools and DMARC reports
Deliverability monitoring means watching four signals and knowing which one triggers which action. The first is the spam rate that Google Postmaster Tools reports for your sending domain. Google's sender guidelines expect this rate to stay below 0.3%, so treat that figure as the threshold for action, not a target to approach. The second is domain and IP reputation, which Postmaster Tools also shows for your domain and any sending IP addresses it sees. The third is authentication success, meaning how often mail from your domain passes SPF and DKIM and aligns with the From domain. The fourth is blocklist status, which you check against the DNS blocklists your outbound IP addresses appear on. Confirm in the current Postmaster Tools documentation which of these views your domain shows, because the data depends on enough Gmail volume to report.
DMARC aggregate reports answer a different question: which servers are sending mail as your domain. Each receiving mailbox provider sends a daily XML report to the address in your rua tag. Assign ownership of that address to a named mail administrator or a shared security mailbox, and run the reports through a parser so the raw XML does not go unread. Look first for sources you do not recognize, such as an old marketing tool or a web form relay, and for legitimate senders that fail alignment. Unknown sources either need a DNS record, an SPF include, or a DKIM signing change, or they need to be blocked by moving the policy toward p=reject. Reports only describe the traffic your domain actually produced and that reached a participating receiver, so a quiet report does not prove that every system is compliant.
Questions buyers ask before hiring help with self-hosted email deliverability
What drives the cost of self-hosted email deliverability work?
The cost is driven by the amount of hands-on work in four areas: a DNS and header audit, sender reputation and IP work, any outbound relay service, and the ongoing time to read reports and fix failures. The DNS audit and DMARC setup are one-time effort. Relay fees and clean IP addresses recur, and whoever owns the mail server pays for them, whether that is your organization or a provider. Monitoring is recurring staff time, and it grows with the number of domains and sending systems. When you request a quote, ask for each area as a separate line item, state who pays the relay or IP provider, and confirm whether monitoring is included or sold as a retainer. Any fixed-scope quote from DeployOpen follows from a written scope, and DeployOpen does not publish a price list.
How long does DMARC deployment take for a self-hosted mail server?
The timeline depends mostly on the DMARC monitoring period, not on the configuration itself. You begin with a policy of none so that aggregate reports show which systems send mail as your domain. Those reports need time to collect from receivers, and every legitimate sender you find must be authenticated before you move to quarantine or reject. Skipping this step is the most common cause of legitimate mail being rejected. Ask any provider to state the monitoring period they recommend for your domains, what criteria move you to the next policy, and who approves each change. Because no researched duration is available for this work, confirm the schedule against your own sender inventory before committing to a date.
What must our team provide before deliverability work can start?
Three inputs decide how quickly the work can move. First, DNS administrator access for every domain that will send mail, including the ability to publish TXT and reverse DNS records. Second, a sender inventory: every application, marketing platform, ticketing tool, printer, and third-party service that sends mail as your domain. Third, named mailbox owners who can confirm which senders are legitimate and who receives DMARC reports. Gaps in the inventory usually surface later as false positives in reports and blocked business messages. Ask for a written list of required access and named owners before the engagement starts, and confirm which accounts or credentials will be used and how they are revoked at the end.
Can our internal team set up SPF, DKIM and DMARC without outside help?
Yes, a capable internal team can publish the records, generate DKIM keys, and read DMARC aggregate reports. The harder work is sustained: checking alignment for each sending system, confirming reverse DNS and TLS on the mail server, watching spam rates in Google Postmaster Tools, and responding when a sender breaks alignment. Google's sender guidelines require all senders to Gmail to set up SPF or DKIM, have valid forward and reverse DNS, use TLS, and keep reported spam rates below 0.3%. Internal teams often underestimate the ongoing review. Before deciding, check whether your team has someone who can own that review every week, not only during launch.
Does a smarthost remove our responsibility for sender reputation?
No. A smarthost relays your outbound mail through another provider, which can help with IP reputation, but your domain still carries the reputation. Receivers evaluate the From domain, SPF and DKIM alignment, and your complaint rate, so a relay cannot fix a misaligned DKIM key or a spoofed sender inventory. A smarthost also adds a recurring provider cost, a dependency on that provider's policies, and a new point of failure for outages. Ask the relay provider which authentication it requires you to publish, how it handles complaints, and what happens to your mail if its IP addresses are listed. Your team still owns the DNS records and the DMARC policy in every case.
What happens after our mail server is placed on a blocklist?
The response starts with identifying which list is involved and why. Look at the listing provider's reason, your Postmaster Tools data, DMARC reports showing unauthorized senders, and recent changes to your DNS, relay, or mail server. Common causes include an unexpected spike in outbound volume, a compromised mailbox sending spam, an open relay, or a misconfigured reverse DNS record. Remove the cause first, then request delisting through the list's own process, since most lists will not remove an address until the problem is fixed. Ask any provider for a written incident procedure covering who responds, how customers are told, and how mail is handled during the listing. Outage and delisting timelines vary by list, so confirm them with the list operator.
Does DeployOpen issue a certification for our email deliverability setup?
No. DeployOpen does not issue audit reports, attestations, or certifications. DeployOpen prepares systems, controls, and evidence, such as DNS records, DMARC reports, configuration records, and monitoring logs, so that an independent auditor or certification body can assess them. If a compliance framework requires a specific assessment, ask the auditor which evidence they expect and agree on it in the written scope before work starts. DeployOpen can also run security testing on the mail platform as part of the engagement, which is reported separately from any certification.
Which parts of email deliverability need ongoing support after launch?
Several tasks recur after launch. DMARC reports arrive continuously and need review. New sending systems, such as a marketing tool or a line-of-business application, must be added to SPF and DKIM before they send. Postmaster Tools spam rates, reverse DNS, and TLS settings need periodic checks, and mail server and DKIM key rotation require planned changes. These tasks can be handled by your staff, by a retainer for ongoing support and upgrades, or by a mix of both. Ask for a written list of recurring tasks, their owners, and how changes are approved and documented.
What to ask an implementation partner before they touch your DNS
Ask the partner to produce a written inventory of every system that sends mail for your domains before any record changes. That list should cover the mailboxes, the application and scanner relays, marketing platforms, ticketing and billing tools, and any SaaS that sends on your behalf. Ask how each source authenticates, which From addresses it uses, and who owns it. A partner who starts by editing SPF without this inventory is guessing, and an SPF record that exceeds the ten DNS lookup limit defined in the SPF standard will fail for every sender at once. Ask how they count lookups, how they flatten or split includes, and who re-checks the count when a new vendor is added.
Ask how DKIM keys are generated, stored and rotated, and where the private keys live after handover. Ask for the selector naming scheme, the rotation interval they recommend, and the procedure for publishing the new public key before the old one is retired. For DMARC, ask them to start with a p=none policy, explain how aggregate reports will be collected and who reads them each week, and set the criteria for moving to p=quarantine or p=reject. Ask what they do when Gmail or Outlook starts routing your mail to spam: which signals they check first (Postmaster Tools spam rate, blocklist status, TLS and reverse DNS), who can change the sending IP, and how they communicate with you during the incident.
Require a written statement of who holds the Google Postmaster Tools account, the DMARC report mailbox and the DNS zone after handover. Shared accounts owned by the partner are a common way to lose visibility when a contract ends. Ask how the smarthost or relay decision is recorded, including which IP addresses are used, who controls their reputation, and what happens if the relay provider changes. Finally, ask for the proposed acceptance criteria in the scope document, such as authentication passing for each sending source in a test window, and how they test in a staged way before enforcement. A partner that cannot name these tests or commit them in writing has not planned the work.
How DeployOpen scopes and supports mail deliverability work
The sequence below turns a deliverability goal into a written scope, configured DNS and mail services, verified authentication, and monitoring that your own team can run after handover. Each step names the output that tells you it is finished.
Confirm the sending domains and mail flows
DeployOpen starts by listing every domain and subdomain that sends mail, including applications, marketing tools, ticketing systems and scanners that relay through the mail server. Your team provides the current DNS zones, the existing mail provider if any, and the names of the people who approve DNS changes. The output is a sender inventory that shows which systems send as which domain, and which ones need authentication before cutover. The step is complete when your team has signed off on that inventory.
Agree the fixed-scope written statement of work
DeployOpen writes the scope in a document that covers DNS records for SPF, DKIM and DMARC, mail server configuration, reverse DNS and TLS checks, monitoring setup, documentation and handover. The document names deliverables, responsibilities on both sides, and the conditions that must be met before work starts. DeployOpen does not publish prices, so the quote follows from this written scope. The step is complete when both parties have signed the scope and its assumptions are recorded.
Audit the current DNS and mail server posture
Before changing anything, DeployOpen reviews existing SPF records, DNS lookup counts, forward and reverse DNS for the mail host, certificate validity, and any DMARC policy already in place. The work runs inside your infrastructure and DNS accounts, using access your team grants for the duration of the audit. The output is a findings register that lists each gap, its risk, and the proposed change. The step is complete when your team has reviewed and accepted the findings.
Configure DKIM keys and mail server authentication
DeployOpen configures the self-hosted mail platform, such as Stalwart or mailcow, to sign outbound messages with DKIM keys, and sets key rotation and storage in line with your key management rules. Where the platform supports ARC for forwarded mail, that is configured and tested as well. Private keys stay in your environment and are never shared outside it. The step is complete when test messages to external accounts show a passing DKIM signature in the headers.
Publish SPF and DMARC with aligned domains
DeployOpen prepares the SPF and DMARC records, starting with a monitoring policy and aligned From domains, then moves toward stricter enforcement only after reports show legitimate senders pass. Your DNS owners publish the records through your normal change process. The output is a DNS change record that shows each published value and the test that confirms it. The step is complete when external checks show SPF and DKIM alignment for the From domain and DMARC reports begin arriving at the address you chose.
Set up relay and outbound routing decisions
DeployOpen documents whether outbound mail leaves directly from your own address space or through a smarthost or relay that you select and contract for yourself. This decision affects reverse DNS, IP reputation and who answers blocklist requests, so it is written into the scope before configuration. If a relay is used, DeployOpen configures the authentication and TLS settings it requires. The step is complete when your team has recorded the chosen route and a test message flows through it.
Build monitoring for Postmaster Tools and DMARC reports
DeployOpen connects Google Postmaster Tools for the sending domains, parses DMARC aggregate reports, and sets alerts for authentication failures and rising complaint signals. Your team gets report access in its own tooling, and the alert routes are documented. The output is a monitoring runbook that names who reviews each signal and what action follows. The step is complete when test alerts reach the named owners.
Hand over documentation and offer ongoing support
DeployOpen delivers the DNS record register, configuration notes, key rotation steps, monitoring runbook and a list of open items to your team, then walks through them in a handover session. Ongoing monitoring, upgrades and changes to sending sources can be covered by an optional retainer agreed in writing. The output is a signed handover record that shows what was delivered and who owns each part. The step is complete when your team confirms it can operate the records and reports without DeployOpen.
